Difference between speech and audio
mcj...@my-dejanews.com
bought a Ascend Pipeline 15 TA and I have an option to set the pots port to
speech or audio. Will one give me better quality audio over the other? Which
is better to use with a v.90 modem?
I tried the two and the "Audio" seems to give me a better throughput. This
could be just a figment of my imagination.
Thanks,
Martin
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Time to Post
: Can someone tell me the difference between speech and audio WRT ISDN. I just
: bought a Ascend Pipeline 15 TA and I have an option to set the pots port to
: speech or audio. Will one give me better quality audio over the other? Which
: is better to use with a v.90 modem?
: I tried the two and the "Audio" seems to give me a better throughput. This
: could be just a figment of my imagination.
Different equipment (shouldn't matter), but with the Courier-I modem,
per the manual it states (Pg 6-5, Part 6 Analog Device Channel Call Type):
Higher quality audio: 3.1kHz audio or speech (Analog modem or fax)
Lower quality audio: Speech
You appear to have a good imagination... :)
--
This address is for outgoing posts only. Please do not reply to this
address via email as it will never be seen. If you have something to
share please post it here for everyone to see.
Hank Karl
> mcj...@my-dejanews.com wrote:
> : Can someone tell me the difference between speech and audio WRT ISDN. I just
> : bought a Ascend Pipeline 15 TA and I have an option to set the pots port to
> : speech or audio. Will one give me better quality audio over the other? Which
> : is better to use with a v.90 modem?
> : I tried the two and the "Audio" seems to give me a better throughput. This
> : could be just a figment of my imagination.
>
> Different equipment (shouldn't matter), but with the Courier-I modem,
> per the manual it states (Pg 6-5, Part 6 Analog Device Channel Call Type):
>
> Higher quality audio: 3.1kHz audio or speech (Analog modem or fax)
> Lower quality audio: Speech
>
The network may compress or otherwise modify "Speech". The network
should not modify 3.1 kHz audio (it was intended for modem or fax). I
believe that they are generally the same on a local connection. There
may be some differences on IXCs.
Does anyone know if echo cancelling, TrueVoice, etc is turned off on
3.1 kHz calls?
-----------------------------------
Hank Karl
Opinions mine, not my company's
to reply, remove the "imnothere" from my address
Jeffrey Rhodes
>
> On 15 Sep 1998 03:34:07 GMT, Time to Post <zu...@kray.com> wrote:
>
> > mcj...@my-dejanews.com wrote:
> > : Can someone tell me the difference between speech and audio WRT ISDN. I just
> > : bought a Ascend Pipeline 15 TA and I have an option to set the pots port to
> > : speech or audio. Will one give me better quality audio over the other? Which
> > : is better to use with a v.90 modem?
> > : I tried the two and the "Audio" seems to give me a better throughput. This
> > : could be just a figment of my imagination.
I would think that significantly more than 3.1KHz bandwidth is needed to
obtain V.90 connect speeds.
> >
> > Different equipment (shouldn't matter), but with the Courier-I modem,
> > per the manual it states (Pg 6-5, Part 6 Analog Device Channel Call Type):
> >
> > Higher quality audio: 3.1kHz audio or speech (Analog modem or fax)
> > Lower quality audio: Speech
> >
> The network may compress or otherwise modify "Speech". The network
> should not modify 3.1 kHz audio (it was intended for modem or fax). I
> believe that they are generally the same on a local connection. There
> may be some differences on IXCs.
This can also be interpreted to mean that the route path of the call in
the network has already compressed "Speech". Further compression by an
IXC that completes the route path of the call may result in an
ineffective answered voice call, generating less revenue for the IXC.
> Does anyone know if echo cancelling, TrueVoice, etc is turned off on
> 3.1 kHz calls?
Only when it needs to be turned off. "3.1KHz" is modified by IXCs the
same as "Speech" bearer requests, since either can be an analog modem or
fax, which will only be discernible after the call is routed and
answered. There is no way for a caller's network to indicate to an IXCs'
network that further *modifications* will only degrade a voice signal
that has already been compressed, e.g. the wireless portion of a
wireless call to a switch or the IP portion of an IP telephony call to a
POTS line. So if an IXC wants to compress this type of call, BC=3.1KHz
Audio won't stop it, provided of course, that the compression algorithm
is able to pass the bandwidth between 400 to 3500 Hz signals.
Once a voice signal has been degraded by compression, it makes sense to
route the call to the next switch with an indication to the network that
any further compression or enhancement will only degrade the overall
end-to-end voice performance. I propose that BC=Speech be used as an
indication to the network that low-grade voice MUST NOT be further
compressed. Rather than an invitation to the network to compress,
BC=Speech can be a demand: DONT TOUCH THIS SIGNAL!
It doesn't make sense for a caller's network to request routing to an
IXC, as for example: "my customer is making a low grade voice call
(BC=Speech), so go ahead and save your company some expense by
compressing the voice signal at my customer's expense". More likely,
even when the call IS low grade voice, the caller's network will convert
an ISDN bearer request from BC=Speech to BC=3.1KHz, in a futile attempt
to supposedly "improve" their customer's long distance call quality per
Bellcore recommendations. ROTFL.
regards, jcr
Hank Karl
<jeffrey...@attws.com> wrote:
> Hank Karl wrote:
> >
> > On 15 Sep 1998 03:34:07 GMT, Time to Post <zu...@kray.com> wrote:
> > >
> > > Different equipment (shouldn't matter), but with the Courier-I modem,
> > > per the manual it states (Pg 6-5, Part 6 Analog Device Channel Call Type):
> > >
> > > Higher quality audio: 3.1kHz audio or speech (Analog modem or fax)
> > > Lower quality audio: Speech
> > >
> > The network may compress or otherwise modify "Speech". The network
> > should not modify 3.1 kHz audio (it was intended for modem or fax). I
> > believe that they are generally the same on a local connection. There
> > may be some differences on IXCs.
>
> This can also be interpreted to mean that the route path of the call in
> the network has already compressed "Speech". Further compression by an
> IXC that completes the route path of the call may result in an
> ineffective answered voice call, generating less revenue for the IXC.
The route path of the call in the network has nothing to do with this.
With the speech BC, The endpoint says "I will supply a speech signal,
commanded by u-law (or A-law) and you (the network) are responsible
for supplying a recognizable signal to the other endpoint. What you
do with it in the middle is not important, so long as speech is
recognizable at the other end".
With the 3.1 KHz audio BC, the endpoint is saying "I need the full 64K
PCM because this signal needs to be higher quality."
Jeffrey Rhodes
A network can give a signal the full bandwidth of 3.1KHz audio, without
committing to full 64K PCM. The network is not obliged to treat 3.1KHz
Audio bearer request any different than speech, but, as I point out, an
IXC may generate more revenue when BC=Speech is NOT compressed. I'm
pretty sure that IP telephony's 56K ends up being the same bandwidth as
BC=3.1KHz Audio in the non-IP circuit-switched PCM telephone network.
So, if anything, BC=Speech indicates to the next switch that completes
the route path of a call that the full 64K PCM is requested thru that
switch, in order to avoid any confounding, deleterious effects of
another layer of compression. A digital wireless switch would do well to
avoid compression in the network since the air interface has already
imposed an almost perceptible delay overhead.
regards, jcr
Laurence V. Marks
>So, if anything, BC=Speech indicates to the next switch that completes
>the route path of a call that the full 64K PCM is requested thru that
>switch, in order to avoid any confounding, deleterious effects of
>another layer of compression. A digital wireless switch would do well to
>avoid compression in the network since the air interface has already
>imposed an almost perceptible delay overhead.
>
definitions in Q.931. A Bearer Capability of 3.1 KHz means that the call
may be routed to an analog destination, but should NOT be subjected to
lossy compression. A Bearer Capability of Speech means that the call may
be routed to an analog destination and may be processed by lossy
algorithms, with the knowledge that the content is speech so such
algorithms can take advantage of known characteristics in speech. (This,
of course, meant ADPCM, although there are lots of other techniques now.)
The meanings for the BCs, and all the routing rules, including routing of
calls which have lost their BC due to transit through a non-SS7 region
(remember ISDN islands) and BC-reassignment thereafter, were all hashed out
in the standards bodies, and in some United States Telephone Association
(USTA) agreements years ago. I don't think anyone's anxious to reopen the
subject.
I was going to write that the question is mostly moot, since there's no
domestic compression, and an overseas call is likely to undergo only one
compression, when it occurred to me that Voice Over IP changes all the
rules, and suddenly this all is relevant.
Laurence V. Marks
IBM Corp. - Research Triangle Park, NC
Rhodes
You seem to believe that all vendors have to do is build to standards and
the world will be standardized? I've done alot of work with standards
implementation, for major carriers, and I know how untrue that statement is.
The SPEECH vs. AUDIO argument comes from the knowledge of how carriers
implement routing within the circuit switch network. It is more than
compression vs. the full 64K within a switch, it is satelite route vs. fiber
route, route index for data billing vs. route index for voice billing,
things like that.
In terms of business, a (C)LEC receives a long distance call attempt and
must route that call to a long distance carrier. Since no (C)LEC can know at
this point that the caller is an analog modem/fax, or just plain speech,
EVERY (C)LEC is going to seek the best possible circuits from their
competitor the long distance company to please their customer at the expense
of the long distance company. That means the (C)LEC can deliberately change
an ISDN caller's request for SPEECH into a request for 3.1KHz Audio !!! Long
distance carriers know this, and do not give any special routing treatment
for either type of call !!! Hence, today, there is no way to indicate that a
call must not suffer any further *enhancements*. I have proposed the
convention within AT&T's network to convert all other network's requests for
SPEECH, so that AT&T Wireless digital callers can request SPEECH within
AT&T's network, in order to bypass *enhancements* such as TrueVoice, to
improve call quality with respect to non-AT&T (C)LECs callers. I haven't
worked on it very hard, but I know the right people in AWS are aware of the
issue. Today wireless digital to wireless digital is only about 5% of AWS
calls, when it becomes 50%, this may become an issue, since there is a small
incremental gain to be had.
So if you want to stand by your standards, go ahead. Just remember that
people like me actually use the implementations of the standards and people
like me are the ones that have to get vendors to compromise their designs
when most vendor's implementation of the same standard won't work with
another vendor! I find it hard to believe that this attitude is not part of
your world, too.
Voice Over IP is different. We need a bearer request for the VoIP call to
ISDN that says "don't touch this signal, further voice processing
enhancements are NOT desired". Bellcore and the ISDN standards do NOT have
this, even though there are two bearer requests for voice. You could argue
that bearer request for 3.1KHz Audio requires the full 64K within the switch
fabric. I could then argue that the full 64K within the switch is able to
deliver "8KHz Integrity", so a request for 3.1KHz integrity does not require
the full 64K.
Regards, Jeffrey
Laurence V. Marks wrote in message
<6ujvd6$1r2u$5...@rtpnews.raleigh.ibm.com>...
Thor Lancelot Simon
I don't have chapter and verse handy, but somewhere buried in the Bellcore
LSSGR (Local Switching Systems Generic Requirements) you'll find the
text (pretty much exactly, I believe; this stuck in my mind):
"The 3.1KHz audio bearer capability implies that the integrity of the
underlying bitstream is crucial."
No, it's not a capital-R Requirement. No, it doesn't say "Must" or "Should".
Yes, the people who wrote those requirements intended 3.1K to mean "if you're
all-digital, don't fuck with the bits" and "speech" to mean "do what you
want to, leave it as comprehensible speech, please".
In an end-to-end SS7 call path (excepting oddities like switches trunked
together with PRI, the only kind of path in the PSTN which will even be
able to tell the far end switch about the bearer capability anyway!) there
are *already* bits in the ISUP messages that set up the call to indicate
whether a call's been compressed or sent over a satellite hop. You don't
need to pervert the bearer capability for this.
--
Thor Lancelot Simon t...@rek.tjls.com
"And where do all these highways go, now that we are free?"
Jeffrey Rhodes
...
>
> In an end-to-end SS7 call path (excepting oddities like switches trunked
> together with PRI, the only kind of path in the PSTN which will even be
> able to tell the far end switch about the bearer capability anyway!) there
> are *already* bits in the ISUP messages that set up the call to indicate
> whether a call's been compressed or sent over a satellite hop. You don't
> need to pervert the bearer capability for this.
>
Yeah, we do. The two existing voice bearers are not given any special
consideration within the ISDN. BTW, is lossless compression permitted
for 3.1KHz Audio bearer requests, afterall, Bellcore says an analog
trunk is OK, that will affect the full 64K, 8KHz Integrity, and Bellcore
only specifies lossy compression must be avoided for 3.1KHZ Audio bearer
request.
The *already* SS7 bits will *probably* only have an effect on routing
decisions at an international gateway, other switches are *probably*
clueless to their use, and do not set up any special translations for
such. Now I expect all the new CLECs to repeat this phenonmenom.
Laurence seems to think all this bearer routing was worked out many
years ago. Seems that Robert was under the impression that a data bearer
request for the full 64K clear channel was OK to route on unclear,
interswitch, 56K-only circuits that "leave ISDN". "Telco experienced
people said 'do the best effort to complete the call, then let the users
decide if the quality of service is acceptable' ", or words to that
effect. Seems Al and Arnette at Lucent, are still working on this
routing peculiarity in ANSI 706 or something.
IP telephony compresses voice, just like wireless digital compresses
voice, and WE NEED a NEW voice bearer capability that absolutely means:
don't touch this signal, nor convert to analog, within the network !!!
regards, jcr
Thor Lancelot Simon
Jeffrey Rhodes <jeffrey...@attws.com> wrote:
>Thor Lancelot Simon wrote:
>...
>>
>> In an end-to-end SS7 call path (excepting oddities like switches trunked
>> together with PRI, the only kind of path in the PSTN which will even be
>> able to tell the far end switch about the bearer capability anyway!) there
>> are *already* bits in the ISUP messages that set up the call to indicate
>> whether a call's been compressed or sent over a satellite hop. You don't
>> need to pervert the bearer capability for this.
>>
>
>Yeah, we do. The two existing voice bearers are not given any special
>consideration within the ISDN. BTW, is lossless compression permitted
>for 3.1KHz Audio bearer requests, afterall, Bellcore says an analog
>trunk is OK, that will affect the full 64K, 8KHz Integrity, and Bellcore
>only specifies lossy compression must be avoided for 3.1KHZ Audio bearer
>request.
>
>The *already* SS7 bits will *probably* only have an effect on routing
>decisions at an international gateway, other switches are *probably*
>clueless to their use, and do not set up any special translations for
>such. Now I expect all the new CLECs to repeat this phenonmenom.
The LSSGR requires otherwise. If you have access to it -- look it up! Since
I work on SS7 routing these days, not trunk signaling -- and I never have
worked on trunk signaling as part of my job -- the completel LSSGR is *not*
among the N * $1000 documents I've been able to justify having on my
bookshelf; I just get to cadge from it when I'm at a client site or in a
class. But there is *explicitly* space in the IAM message for these
purposes, and the LSSGR requires that switches used by the BCC LEC's, at
least, use the values which are in there.
>Laurence seems to think all this bearer routing was worked out many
>years ago. Seems that Robert was under the impression that a data bearer
>request for the full 64K clear channel was OK to route on unclear,
>interswitch, 56K-only circuits that "leave ISDN". "Telco experienced
>people said 'do the best effort to complete the call, then let the users
>decide if the quality of service is acceptable' ", or words to that
>effect. Seems Al and Arnette at Lucent, are still working on this
>routing peculiarity in ANSI 706 or something.
Well, the telco people who said that were wrong. What else is there to say?
If it's really, really, really important to you, and you can't or won't do it
yourself, I will use up a favor or two and get you the chapter and verse from
the appropriate Bellcore GR documents. You can't push 64K data through a 56K
pipe, so you fail the call. You *can* push 3.1KHz audio through a 56K pipe,
so you don't fail the call.
It seems like what you want is a bearer capability which means "don't touch
these bits, but it's okay if the path is only 56k". That's what people use
the 3.1K Audio bearer capability *for*, since there just aren't many analog
paths left in the network any more, and Bellcore specifies that "the integrity
of the underlying bitstream is critical", but unfortunately you are still
free to D/A it and push it down a 3.1K analog path, then A/D it again. If
what you're saying is "that sucks, and we need a bearer capability just like
3.1K audio but where you can't do that" I agree with you; let's call it
"56KB/sec data" or, I know, even better: "64KB/sec restricted data". Oh,
wait. Maybe we agree on more of this than I thought we did...
In practice, it's trivial to probe to see if your call went across an analog
path -- your link layer protocol won't sync up at all! -- and it's similarly
trivial to probe to see if you actually got a 56k or 64k path with a 3.1K
audio BC. I wish ISDN equipment vendors would *do* this.
>
>IP telephony compresses voice, just like wireless digital compresses
>voice, and WE NEED a NEW voice bearer capability that absolutely means:
>don't touch this signal, nor convert to analog, within the network !!!
That's "data". What's so hard about that concept?
Jeffrey Rhodes
> >
> >IP telephony compresses voice, just like wireless digital compresses
> >voice, and WE NEED a NEW voice bearer capability that absolutely means:
> >don't touch this signal, nor convert to analog, within the network !!!
>
> That's "data". What's so hard about that concept?
>
Well, nowadays, there is a multiplicity of "data" and "voice". Let's say
I am an SS7 IP gateway between the circuit switched ISDN world and the
packet switched Internet telephony world. Let's say I get a bearer
request for 3.1KHz Audio from ISDN. Let's say I know this call to be a
fax. I can save some of the planet's Internet bandwidth if I intercept
this fax call, convert the 64 kbit/s "signal" to the mere 9600 bits/s
that the fax digital information _really_ is (performing lossless
compression in the process) and deliver this to the IP telephony fax
destination. Great, the bearer request gave me a clue and I took
advantage of it. That was really a "data" call, right?
Now let's say the next call from ISDN is a "voice" call with bearer
request for Speech. Unfortunately, this call started as an IP telephony
caller to an ISDN destination that was forwarded to an IP telephony
destination that was forwarded back to an ISDN destination that was
forwarded to me. I decide to use my vocoder to setup the call to the IP
destination. Unfortunately, the delivered "voice" information content to
the IP telephony answerer is unintelligible so they hang up.
It would be best if there were a way for the ISDN callers to indicate
that I need to bypass my vocoder because any further enhancements may
degrade the quality of a speech call. This would allow me to deliver the
entire 64 kbit/s PCM traffic to the IP telephony destination so that
there is no delay for vocoders, etc. For some reason you suggest that
the bearer request for 3.1KHz audio was required with a little R by
Bellcore to mean what I want but for some reason I don't think the
SS7/IP gateways are going to do that. Maybe I could charge the ISDN fax
caller who insists on using up 64 kbit/s thru the Internet more for that
bearer request.
Wireless Digital callers have already suffered a vocoder's compression,
when they call into the SS7/IP gateway, or vice-versa, the resulting
speech path may be delay-prone. I don't think SS7 has this covered.
Also, many SS7 switches do not have the data translations that are able
to select routing per the specialized bits of SS7.
Anyway, don't do me any favors, but I would really like to see where
Bellcore uses the f-word in print ;-)
Regards, Jeffrey
Robert Blackshaw
>
> Thor Lancelot Simon wrote:
> ...
> >
> > In an end-to-end SS7 call path (excepting oddities like switches trunked
> > together with PRI, the only kind of path in the PSTN which will even be
> > able to tell the far end switch about the bearer capability anyway!) there
> > are *already* bits in the ISUP messages that set up the call to indicate
> > whether a call's been compressed or sent over a satellite hop. You don't
> > need to pervert the bearer capability for this.
> >
>
> Yeah, we do. The two existing voice bearers are not given any special
> consideration within the ISDN. BTW, is lossless compression permitted
> for 3.1KHz Audio bearer requests, afterall, Bellcore says an analog
> trunk is OK, that will affect the full 64K, 8KHz Integrity, and Bellcore
> only specifies lossy compression must be avoided for 3.1KHZ Audio bearer
> request.
>
> The *already* SS7 bits will *probably* only have an effect on routing
> decisions at an international gateway, other switches are *probably*
> clueless to their use, and do not set up any special translations for
> such. Now I expect all the new CLECs to repeat this phenonmenom.
>
> years ago. Seems that Robert was under the impression that a data bearer
> request for the full 64K clear channel was OK to route on unclear,
> interswitch, 56K-only circuits that "leave ISDN". "Telco experienced
> people said 'do the best effort to complete the call, then let the users
> decide if the quality of service is acceptable' ", or words to that
> effect. Seems Al and Arnette at Lucent, are still working on this
> routing peculiarity in ANSI 706 or something.
>
> voice, and WE NEED a NEW voice bearer capability that absolutely means:
> don't touch this signal, nor convert to analog, within the network !!!
>
"voice" and "3.1 kHz Audio" was not simply because it was a slow day.
3.1 kHz was (and still is) intended for cases of analog modem traffic
over an ISDN in cases of, a) interworking with a PSTN, and b) cases
where a PTT or RPOA has not totally converted to digital trunking
or uses 32kbit/s ADPCM. Excessive conversions can really screw up
analog modems, try getting full speed through a SLC for example, it
just does not happen. Modems are neither as intelligent nor as
forgiving as the human ear.
Bob
--
"Since when was genius found respectable?"
E. B. Browning
Robert Blackshaw
> >Thor Lancelot Simon wrote:
> >...
> >>
> >> In an end-to-end SS7 call path (excepting oddities like switches trunked
> >> together with PRI, the only kind of path in the PSTN which will even be
> >> able to tell the far end switch about the bearer capability anyway!) there
> >> are *already* bits in the ISUP messages that set up the call to indicate
> >> whether a call's been compressed or sent over a satellite hop. You don't
> >> need to pervert the bearer capability for this.
> >>
> >
> >Yeah, we do. The two existing voice bearers are not given any special
> >consideration within the ISDN. BTW, is lossless compression permitted
> >for 3.1KHz Audio bearer requests, afterall, Bellcore says an analog
> >trunk is OK, that will affect the full 64K, 8KHz Integrity, and Bellcore
> >only specifies lossy compression must be avoided for 3.1KHZ Audio bearer
> >request.
> >
> >The *already* SS7 bits will *probably* only have an effect on routing
> >decisions at an international gateway, other switches are *probably*
> >clueless to their use, and do not set up any special translations for
> >such. Now I expect all the new CLECs to repeat this phenonmenom.
>
> I work on SS7 routing these days, not trunk signaling -- and I never have
> worked on trunk signaling as part of my job -- the completel LSSGR is *not*
> among the N * $1000 documents I've been able to justify having on my
> bookshelf; I just get to cadge from it when I'm at a client site or in a
> class. But there is *explicitly* space in the IAM message for these
> purposes, and the LSSGR requires that switches used by the BCC LEC's, at
> least, use the values which are in there.
>
> >years ago. Seems that Robert was under the impression that a data bearer
> >request for the full 64K clear channel was OK to route on unclear,
> >interswitch, 56K-only circuits that "leave ISDN". "Telco experienced
> >people said 'do the best effort to complete the call, then let the users
> >decide if the quality of service is acceptable' ", or words to that
> >effect.
IIRC we were discussing DOV use of ISDN. So, you say to the switch
give me a "voice" call with "8kHz integrity" (which is about all
you can specify), yes, the carrier should try and complete the call
and let the end (human) user decide. Scenario, I'm in some godforsaken
place and absolutely need to talk to someone remote. The carrier
cannot meet the "specs" but can complete the call. Persistent
refusal in such a situation would be criminal. Telephones and
networks are more tha $#@% engineering specs. Or are you guys
trying to teach your grandfathers to suck eggs?
> Well, the telco people who said that were wrong. What else is there to say?
> If it's really, really, really important to you, and you can't or won't do it
> yourself, I will use up a favor or two and get you the chapter and verse from
> the appropriate Bellcore GR documents. You can't push 64K data through a 56K
> pipe, so you fail the call. You *can* push 3.1KHz audio through a 56K pipe,
> so you don't fail the call.
>
> It seems like what you want is a bearer capability which means "don't touch
> these bits, but it's okay if the path is only 56k". That's what people use
> the 3.1K Audio bearer capability *for*, since there just aren't many analog
> paths left in the network any more, and Bellcore specifies that "the integrity
> of the underlying bitstream is critical", but unfortunately you are still
> free to D/A it and push it down a 3.1K analog path, then A/D it again. If
> what you're saying is "that sucks, and we need a bearer capability just like
> 3.1K audio but where you can't do that" I agree with you; let's call it
> "56KB/sec data" or, I know, even better: "64KB/sec restricted data". Oh,
> wait. Maybe we agree on more of this than I thought we did...
>
What some people are looking for is a way around tarrifs. Now admittedly
the tarrifs suck pond water, but that is a sad excuse for screwing
about with the standards.
> In practice, it's trivial to probe to see if your call went across an analog
> path -- your link layer protocol won't sync up at all! -- and it's similarly
> trivial to probe to see if you actually got a 56k or 64k path with a 3.1K
> audio BC. I wish ISDN equipment vendors would *do* this.
>
> >
> >IP telephony compresses voice, just like wireless digital compresses
> >voice, and WE NEED a NEW voice bearer capability that absolutely means:
> >don't touch this signal, nor convert to analog, within the network !!!
>
> That's "data". What's so hard about that concept?
>
> See notes on tarrifs above. Actually the problem needs to be taken
to his state PUC, not ANSI or the ITU. :-)
Jeffrey Rhodes
>
> IIRC we were discussing DOV use of ISDN. So, you say to the switch
> give me a "voice" call with "8kHz integrity" (which is about all
> you can specify), yes, the carrier should try and complete the call
> and let the end (human) user decide. Scenario, I'm in some godforsaken
> place and absolutely need to talk to someone remote. The carrier
> cannot meet the "specs" but can complete the call. Persistent
> refusal in such a situation would be criminal. Telephones and
> networks are more tha $#@% engineering specs. Or are you guys
> trying to teach your grandfathers to suck eggs?
Does IIRC stand for If I Re Call? Hey, Bob, given what you have just
said, is there any SS7 routing tips you would pass onto SS7 routing
engineers to differientiate between speech and audio? Since they can
both use every kind of digital interswitch circuit that there is, it is
hard to imagine that they would ever be routed to separate facilities
based solely on the bearer request, right?
Another rhetorical question: If an analog modem is set to only accept a
28.8 connection, yet the bearer request was routed over some hodgepodge
of non-SS7 circuits, so that the connection is unable to attain 28.8, is
it criminal to charge for the repeated, yet unsuccessful, answered call
attempts that an unattended analog modem may insist on performing? Maybe
this modem is your home security system notification calling some
lumnuts, misconfigured modem. It should keep trying, but what you are
saying, is that it doesn't matter which bearer request these calls
actually present to the SS7 ISDN network that may ultimately provide the
switched circuits of the call's route path thru the ISDN, which, as you
point out, sometimes is augmented as a last resort, by the antiquated
PSTN, right?
> > Well, the telco people who said that were wrong. What else is there to say?
> > If it's really, really, really important to you, and you can't or won't do it
> > yourself, I will use up a favor or two and get you the chapter and verse from
> > the appropriate Bellcore GR documents. You can't push 64K data through a 56K
> > pipe, so you fail the call. You *can* push 3.1KHz audio through a 56K pipe,
> > so you don't fail the call.
> >
> > It seems like what you want is a bearer capability which means "don't touch
> > these bits, but it's okay if the path is only 56k". That's what people use
> > the 3.1K Audio bearer capability *for*, since there just aren't many analog
> > paths left in the network any more, and Bellcore specifies that "the integrity
> > of the underlying bitstream is critical", but unfortunately you are still
> > free to D/A it and push it down a 3.1K analog path, then A/D it again. If
> > what you're saying is "that sucks, and we need a bearer capability just like
> > 3.1K audio but where you can't do that" I agree with you; let's call it
> > "56KB/sec data" or, I know, even better: "64KB/sec restricted data". Oh,
> > wait. Maybe we agree on more of this than I thought we did...
> >
> What some people are looking for is a way around tarrifs. Now admittedly
> the tarrifs suck pond water, but that is a sad excuse for screwing
> about with the standards.
That's why I say the standards need a new, explicit, voice bearer to
indicate that 8KHz Integrity is absolutely required, no lossless
conversion of an analog fax 3.1KHz Audio signal to its 9600 bit/s
equivalent is desired, what we want from the SS7 routing translations is
the full 64 kbit/s digital information content delivered, as is, every
bit the same in both directions. Tariffs will probably be higher for
this "luxury" voice bearer, but I am sure your desperate callers will
pay for this premium in an emergency, or perhaps only as an option, when
the end-to-end "voice" connection that existing voice bearers produce is
undesirable.
> > In practice, it's trivial to probe to see if your call went across an analog
> > path -- your link layer protocol won't sync up at all! -- and it's similarly
> > trivial to probe to see if you actually got a 56k or 64k path with a 3.1K
> > audio BC. I wish ISDN equipment vendors would *do* this.
I would not be surprised at all if SS7/IP voice gateways interlope on
"voice" bearer requests, in order to divert an analog modem or fax
caller to a DSP that can provide lossless compression of the digital
information whilst it is transported across the Internet. Other
"bidirectionan digital probes(C)" may be necessary since data networks
can give false indications of allocated bandwidth and this can otherwise
be exploited with no extra cost to the exploiter ;-)
>
> Bob
>
> --
> "Since when was genius found respectable?"
> E. B. Browning
If he were so smart, how come he never got rich?
regards, jcr
Robert Blackshaw
specifies is that whatever the sender gives the net as a byte (8 bits)
will be delivered as a byte. Whether one bit of that byte was robbed
for signaling is irrelevant.
The "luxury" service is what 3.1kHz audio is all about. Supposedly
to guarantee that there would be no superfluous "conversions" that
would screw up a modem.
> > > In practice, it's trivial to probe to see if your call went across an analog
> > > path -- your link layer protocol won't sync up at all! -- and it's similarly
> > > trivial to probe to see if you actually got a 56k or 64k path with a 3.1K
> > > audio BC. I wish ISDN equipment vendors would *do* this.
>
> I would not be surprised at all if SS7/IP voice gateways interlope on
> "voice" bearer requests, in order to divert an analog modem or fax
> caller to a DSP that can provide lossless compression of the digital
> information whilst it is transported across the Internet. Other
> "bidirectionan digital probes(C)" may be necessary since data networks
> can give false indications of allocated bandwidth and this can otherwise
> be exploited with no extra cost to the exploiter ;-)
>
I recall once that we (the Telco) were asked by the gummint if
we could block all cross border data transfers - had something
to do with all the credit data on us being held in US databases.
After we stopped laughing, we very politely suggested that if
they could tell us how to distinguish a data bit from a voice
bit we would look into the problem.
> >
> > --
> > "Since when was genius found respectable?"
> > E. B. Browning
>
> If he were so smart, how come he never got rich?
Elizabeth Barret Browning was a lady so far as I know,
and she was rich in many things.
Me, I'm not rich, but if getting there means playing some
of the dirty tricks most wealthy people have forget it.
But I'm rich in lots of other things than money.
>
> regards, jcr
Aaron Leonard
~ That's why I say the standards need a new, explicit, voice bearer to
~ indicate that 8KHz Integrity is absolutely required, no lossless
~ conversion of an analog fax 3.1KHz Audio signal to its 9600 bit/s
~ equivalent is desired, what we want from the SS7 routing translations is
~ the full 64 kbit/s digital information content delivered, as is, every
~ bit the same in both directions.
I don't see why you need a special 64Kbps "voice" bearercap.
If your "voice" application requires 64Kbps, then ask for 64Kbps.
Bearercap 0x8890. Go for it.
Information Transfer Capability:
Unrestricted digital information
Transfer Mode:
Circuit Mode
Information Transfer Rate:
64 Kbps
Aaron
Jeffrey Rhodes
Aaron,
Need I state the obvious? When a "voice" bearer is converted to a "data"
bearer, there's no going back. The answering device will not "ring" a
phone for someone to talk to, the answering device will divert the 64
kbit/s information content to a preconfigured data device, if the
answering device is inclined to answer at all! Of course, when the
"intended" answering device is an analog phone and the "line" has no
"data" provisioning, well, then, the network would reasonably be
expected to reject that call's bearer outright.
An H.323 server will receive Q.931 voice bearer SETUP messages from an
H.323 client. Are you suggesting that these callers are only able to
request data bearercaps since the IP telephone is Internet-based? If so,
the IP telephone would not be able to "talk" to a POTS line, or for that
matter, an ISDN line.
HTH, Jeffrey
Amanda Walker
>IP telephony compresses voice, just like wireless digital compresses
>voice, and WE NEED a NEW voice bearer capability that absolutely means:
>don't touch this signal, nor convert to analog, within the network !!!
We do. It's called "data bearer capability."
Data means "the bits are important."
3.1KHz Audio means "the sound is important, and don't assume it's speech."
Speech means "the sound is important, and it's probably speech."
There's a lot of stuff in various standard that elaborates on it, but this
is basically what it boils down to. If you need to get bits from point A
to point B, it's called "data."
DOVBS in the end, addresses two issues: (a) tariffs and billing, and
(b) trunks that are digital but are not using ISDN signaling (channelized
T1s, for example, which in some areas are easier/cheaper to get than PRIs).
But that's pretty much it. What you are calling "voice with 8KHz integrity"
is just another name for "data", because any other treatment of it screws
up the bit stream. If the bit stream is what you're trying to get across
the
network, say so--that's what data BC is for. If the audio waveform is
what you're trying to get across the network, that's what audio BC is for.
If intelligible speech is what you're trying to get across the network,
that's what speech BC is for.
Saying "I want to call my bits 'voice' because voice is cheaper than data"
is fine, but it's not a protocol problem. It's a tariff problem.
Saying "I want to call my bits 'voice' because all I can get from my telco
are channelized T1s," is fine too. That's not a protocol problem either;
it's a vendor problem.
Amanda Walker
Senior Software Engineer
Ascend Communications, Inc.
[personal opinion, not an official statement from Ascend]
Hank Karl
<jeffrey...@attws.com> wrote:
>
> That's why I say the standards need a new, explicit, voice bearer to
> indicate that 8KHz Integrity is absolutely required, no lossless
> conversion of an analog fax 3.1KHz Audio signal to its 9600 bit/s
> equivalent is desired, what we want from the SS7 routing translations is
> the full 64 kbit/s digital information content delivered, as is, every
> bit the same in both directions. Tariffs will probably be higher for
> this "luxury" voice bearer, but I am sure your desperate callers will
> pay for this premium in an emergency, or perhaps only as an option, when
> the end-to-end "voice" connection that existing voice bearers produce is
> undesirable.
Hi Jeff,
According to my copy of Q.931, BC = speech has 8 kHz integrity. All
the circuit modes have 8 kHz integrity. The only mode without 8 kHz
integrity is the Packet, Unrestricted Data mode. But my copy is a bit
old. Perhaps there have been some changes so that ISDN circuit
switched voice no longer operates at an 8 kHz sample rate?
Jeffrey Rhodes
>
> Jeffrey Rhodes <jeffrey...@attws.com> wrote:
> >IP telephony compresses voice, just like wireless digital compresses
> >voice, and WE NEED a NEW voice bearer capability that absolutely means:
> >don't touch this signal, nor convert to analog, within the network !!!
>
> We do. It's called "data bearer capability."
Need I state the obvious?
> Data means "the bits are important."
Also, "please answer the call with a data device", OK?
> 3.1KHz Audio means "the sound is important, and don't assume it's speech."
So that means it is OK to "provide lossless digital compression to 9600
bit/s when possible", right"
That's OK as in Oh-kay, not as in zero K.
> Speech means "the sound is important, and it's probably speech."
And elaborate, consecutive, accumulated *enhancements* may make the
resulting, answered connection immutable ;-)
>
> Amanda Walker
> Senior Software Engineer
> Ascend Communications, Inc.
> [personal opinion, not an official statement from Ascend]
Amanda, your comments about DOVBS are well done, but I don't care about
no stinking tariffs. A (C)LEC needs to be competitive, playing by the
rules, within true sportsmanlike competition, like Ameritech ISDN in
Chicago ...
regards, jcr
Jeffrey Rhodes
Hello, Henry ;-)
The request is for 8 kHz integrity, as you know, what you get is what
you get once the circuit switch mode call is answered and the route path
for the "voice signal" is transported end-to-end. It's all that stuff in
between that "data" calls are able to avoid, that I promote to be
bypassable via a NEW voice bearer, since it is not a capability that we
all seek with our ISDN calls, it is a request that we make.
Unfortunately, once a "voice" call is promoted to a "data" call, the
routing network that establishes the circuit switch mode route path is
unable to demote back to "ring" an analog phone.
This NEW voice bearer will make IP telephony crossover, between the
packet switched world of IP telephony and the circuit switched world of
ISDN/PSTN, able to avoid unnecessairy *enhancements* that can be
selected by switch translations provisioning, along the route request
control signaling path(s) that provide call setup! BTW, you aren't
suggesting that the Q.931 component of IP telephony use bearer requests
for "Packet, Unrestricted Data mode", are you? I suppose that is
possible, but I would convert such a request at the SS7/IP gateway
boundary, no?
Eric Smith
> 3.1KHz Audio means "the sound is important, and don't assume it's speech."
Jeffrey Rhodes <jeffrey...@attws.com> writes:
> So that means it is OK to "provide lossless digital compression to 9600
> bit/s when possible", right"
It is always acceptable for the carrier to apply lossless digital compression,
since by definition the customer(s) can't tell the difference.
Since there is no way to do lossless compression of 3.1 KHz audio at 8-bit
quantization and 8 KHz sampling down to 9600 bps, your statement is
meaningless anyhow.
Jeffrey Rhodes
Au contraire. A fax caller onboard a commercial aircraft can use an ISDN
voice bearer to indicate that a fax assisted, digital lossless
compression of the fax information content is requested onboard, so that
only the mere bits that are needed to recreate the visualized
end-product, in a store and forward operation with the ground, are
delivered error-free by the air transport link between ground and
aircraft, to be reconstructed into an "audio signal" with the called
*line*. I've read here in comp.dcom.isdn that international voice
gateways do a similar lossless, digital compression of fax with DSPs,
for "voice" calls from/to Japan, for example.
So there, what do you know? It IS possible to provide lossless digital
compression for BC=3.1KHz Audio bearercaps, if that is what the network
provider that receives that bearercap request, wants to do. There is no
need to use 8 KHz sampling, either. To prevent this interception, a
voice bearercap request for "no screwing around with the bits, in either
direction" is needed, since a data bearercap is able to request such
service, but a data bearercap cannot compell an analog cellphone, or any
other analog "line", to make the sounds of *ringing*, so that someone
can talk on the answered circuit switch connection, especially when the
caller is an analog modem or fax.
HTH, jcr
Hank Karl
<jeffrey...@attws.com> wrote:
> On Fri, 02 Oct 1998 11:00:46 -0700, Jeffrey Rhodes
> <jeffrey...@attws.com> wrote:
>
> >
> > That's why I say the standards need a new, explicit, voice bearer to
> > indicate that 8KHz Integrity is absolutely required, no lossless
> > conversion of an analog fax 3.1KHz Audio signal to its 9600 bit/s
> > equivalent is desired, what we want from the SS7 routing translations is
> > the full 64 kbit/s digital information content delivered, as is, every
> > bit the same in both directions. Tariffs will probably be higher for
> > this "luxury" voice bearer, but I am sure your desperate callers will
> > pay for this premium in an emergency, or perhaps only as an option, when
> > the end-to-end "voice" connection that existing voice bearers produce is
> > undesirable.
What sort of end-user device do you have in mind?
>
> The request is for 8 kHz integrity, as you know, what you get is what
> you get once the circuit switch mode call is answered and the route path
> for the "voice signal" is transported end-to-end. It's all that stuff in
> between that "data" calls are able to avoid, that I promote to be
> bypassable via a NEW voice bearer, since it is not a capability that we
> all seek with our ISDN calls, it is a request that we make.
> Unfortunately, once a "voice" call is promoted to a "data" call, the
> routing network that establishes the circuit switch mode route path is
> unable to demote back to "ring" an analog phone.
I'll assume that you are talking about fax here. Speech is a
non-issue, and is already handled. Fax does not need 64K, it works
fine on existing voice type lines at 56K, provided you turn off
"enhancements". That's what 3.1 kHz audio is for.
The 8 kHz integrity (as I understand it) only means that you will get
a sample rate of 8 kHz. It does not mean that the value of each
sample will be unaffected. The amplitude of the sample may be changed
(eg the signal may be run through a digital filter.)
> This NEW voice bearer will make IP telephony crossover, between the
> packet switched world of IP telephony and the circuit switched world of
> ISDN/PSTN, able to avoid unnecessairy *enhancements* that can be
> selected by switch translations provisioning, along the route request
> control signaling path(s) that provide call setup!
If you are sending IP packetized, compressed voice to some special
telephone like device (ie a PC with speaker and mic) then the device
should be able to accept an ISDN data call.
> BTW, you aren't
> suggesting that the Q.931 component of IP telephony use bearer requests
> for "Packet, Unrestricted Data mode", are you? I suppose that is
> possible, but I would convert such a request at the SS7/IP gateway
> boundary, no?
I thought the component of IP telephony (H.323) was H.225. I'm not
familiar with this spec, so I don't know what the BCs are. But at the
IP/SS7 or IP/ISDN gateway, the call should go out as a speech or 3.1
kHz audio call. If you need a special BC to turn off the echo
cancelers, etc, use the 3.1 kHz audio.
Hank Karl
<jeffrey...@attws.com> wrote:
> Amanda Walker wrote:
> >
> > Jeffrey Rhodes <jeffrey...@attws.com> wrote:
> > >IP telephony compresses voice, just like wireless digital compresses
> > >voice, and WE NEED a NEW voice bearer capability that absolutely means:
> > >don't touch this signal, nor convert to analog, within the network !!!
> >
> > We do. It's called "data bearer capability."
>
> Need I state the obvious?
>
> > Data means "the bits are important."
>
> Also, "please answer the call with a data device", OK?
Jeff, a PC running some internet telephony program is a data device.
So is a phone that can accept VoIP packets.
>
> > 3.1KHz Audio means "the sound is important, and don't assume it's speech."
>
> So that means it is OK to "provide lossless digital compression to 9600
> bit/s when possible", right"
yes, if it is truly lossless. Thats lossless as in "you can exactly
reconstruct the input signal from the compressed data", not lossless
as in "some lossy voice compression algorithm. An example of a lossy
compression algorithm is u-Law. Another one is ADPCM. A lossless
compression algorithm is used by the program "pkzip".
>
Basically, if you send a 64 k-bit/sec stream into a system, the system
uses lossless compression internally, and the system gives you exactly
the same bits back, how do you know the data was compressed? Or if it
was compressed?
> That's OK as in Oh-kay, not as in zero K.
>
> > Speech means "the sound is important, and it's probably speech."
>
> And elaborate, consecutive, accumulated *enhancements* may make the
> resulting, answered connection immutable ;-)
Yes, but
1. How many "enhancements" does one carrier do to the data?
2. How many carriers will you send the data through?
3. With Internet Telephony, wouldn't you go to a local POP, send
compressed packets over the internet (which may lose packets, but
doesn't "enhance" them) then to some POP local to the other user?
> Amanda, your comments about DOVBS are well done, but I don't care about
> no stinking tariffs. A (C)LEC needs to be competitive, playing by the
> rules, within true sportsmanlike competition, like Ameritech ISDN in
> Chicago ...
Jeff, what rules are you talking about? Market dynamics? The
tarriffs the ILECs wrote?
Many of us who are in an area where DOVBS works do care about the
tarriffs. But if you don't, I can only assume you have lots of extra
money. If you want to throw it away, how about tossing some in my
direction?
Hank Karl
> Someone wrote:
> > 3.1KHz Audio means "the sound is important, and don't assume it's speech."
>
> Jeffrey Rhodes <jeffrey...@attws.com> writes:
> > So that means it is OK to "provide lossless digital compression to 9600
> > bit/s when possible", right"
>
> It is always acceptable for the carrier to apply lossless digital compression,
> since by definition the customer(s) can't tell the difference.
Provided there is no significant delay introduced.
>
> Since there is no way to do lossless compression of 3.1 KHz audio at 8-bit
> quantization and 8 KHz sampling down to 9600 bps, your statement is
> meaningless anyhow.
-----------------------------------
Hank Karl
<jeffrey...@attws.com> wrote:
> Eric Smith wrote:
> >
> > Someone wrote:
> > > 3.1KHz Audio means "the sound is important, and don't assume it's speech."
> >
> > Jeffrey Rhodes <jeffrey...@attws.com> writes:
> > > So that means it is OK to "provide lossless digital compression to 9600
> > > bit/s when possible", right"
> >
> > It is always acceptable for the carrier to apply lossless digital compression,
> > since by definition the customer(s) can't tell the difference.
> >
> > Since there is no way to do lossless compression of 3.1 KHz audio at 8-bit
> > quantization and 8 KHz sampling down to 9600 bps, your statement is
> > meaningless anyhow.
>
> Au contraire. A fax caller onboard a commercial aircraft can use an ISDN
> voice bearer to indicate that a fax assisted, digital lossless
> compression of the fax information content is requested onboard, so that
> only the mere bits that are needed to recreate the visualized
> end-product, in a store and forward operation with the ground, are
> delivered error-free by the air transport link between ground and
> aircraft, to be reconstructed into an "audio signal" with the called
> *line*. I've read here in comp.dcom.isdn that international voice
> gateways do a similar lossless, digital compression of fax with DSPs,
> for "voice" calls from/to Japan, for example.
And they also do another for modems. Whether this is compression is
arguable. What is really done is that the signal is demodulated into
a digital stream. Its more like the gateway has a fax/modem that
connects to the device on the analog line, sends the 9600 bit/sec
signal over some network, and a corresponding gateway on the other end
has another fax/modem that connects to the far-end device and
re-modulates the signal.
>
> So there, what do you know? It IS possible to provide lossless digital
> compression for BC=3.1KHz Audio bearercaps, if that is what the network
> provider that receives that bearercap request, wants to do. There is no
> need to use 8 KHz sampling, either. To prevent this interception, a
> voice bearercap request for "no screwing around with the bits, in either
> direction" is needed, since a data bearercap is able to request such
> service, but a data bearercap cannot compell an analog cellphone, or any
> other analog "line", to make the sounds of *ringing*, so that someone
> can talk on the answered circuit switch connection, especially when the
> caller is an analog modem or fax.
what's wrong with 3.1 kHz?
Eric Smith
> Since there is no way to do lossless compression of 3.1 KHz audio at 8-bit
> quantization and 8 KHz sampling down to 9600 bps, your statement is
> meaningless anyhow.
Jeffrey Rhodes <jeffrey...@attws.com> writes:
> Au contraire. A fax caller onboard a commercial aircraft can use an ISDN
> voice bearer to indicate that a fax assisted, digital lossless
> compression of the fax information content is requested onboard, so that
Yes. That is lossless fax compression. It is most decidedly not lossless
audio compression. The audio coming out the end may be measurably different
than the audio at the near end; it just won't be different in any way that
will matter to a V.29 modem.
But just because I use a bearer capability of 3.1 KHz audio doesn't tell
the phone company that I am doing fax. Therefore, in the general case,
they can't demodulate it to use a lower bit rate.
> So there, what do you know? It IS possible to provide lossless digital
> compression for BC=3.1KHz Audio bearercaps, if that is what the network
> provider that receives that bearercap request, wants to do.
No, it is NOT.
> There is no need to use 8 KHz sampling, either.
For lossless compression of 3.1 KHz audio, a minimum sample rate of 6.2 KHz
is theoretically required. For 8-bit quantization, this still would require
49.6 Kbps, a far cry from your claimed 9600 bps.
Eric
Jeffrey Rhodes
thanks.
More comments, to your comments, below, jcr.
Hank Karl wrote:
>
> On Tue, 06 Oct 1998 12:33:56 -0700, Jeffrey Rhodes
> <jeffrey...@attws.com> wrote:
>
> > On Fri, 02 Oct 1998 11:00:46 -0700, Jeffrey Rhodes
> > <jeffrey...@attws.com> wrote:
> >
> > >
> > > That's why I say the standards need a new, explicit, voice bearer to
> > > indicate that 8KHz Integrity is absolutely required, no lossless
> > > conversion of an analog fax 3.1KHz Audio signal to its 9600 bit/s
> > > equivalent is desired, what we want from the SS7 routing translations is
> > > the full 64 kbit/s digital information content delivered, as is, every
> > > bit the same in both directions. Tariffs will probably be higher for
> > > this "luxury" voice bearer, but I am sure your desperate callers will
> > > pay for this premium in an emergency, or perhaps only as an option, when
> > > the end-to-end "voice" connection that existing voice bearers produce is
> > > undesirable.
> What sort of end-user device do you have in mind?
Well, you know, the kind of devices that permits two humans to talk to
each other via the path created by a call setup. That could be an analog
phone, a cellphone, an "Internet Telephone" (which could be a mic and
speaker hooked up to the sound card of a PC, I suppose). What I am
getting at, is that humans may be able to talk on the hodgepodge talk
paths that provide "speech", but SOMETIMES a digital cellphone to
digital cellphone talk path can be improved, with less *enhancements*,
such as AT&T's True Voice. I predict the same is true for a cellphone
caller to an IP telephony "Internet Telephone" answerer, when such a
call must crossover on an SS7/IP gateway's vocoders.
> > The request is for 8 kHz integrity, as you know, what you get is what
> > you get once the circuit switch mode call is answered and the route path
> > for the "voice signal" is transported end-to-end. It's all that stuff in
> > between that "data" calls are able to avoid, that I promote to be
> > bypassable via a NEW voice bearer, since it is not a capability that we
> > all seek with our ISDN calls, it is a request that we make.
> > Unfortunately, once a "voice" call is promoted to a "data" call, the
> > routing network that establishes the circuit switch mode route path is
> > unable to demote back to "ring" an analog phone.
> I'll assume that you are talking about fax here. Speech is a
> non-issue, and is already handled. Fax does not need 64K, it works
> fine on existing voice type lines at 56K, provided you turn off
> "enhancements". That's what 3.1 kHz audio is for.
Where do I lose you? 3.1kHz audio bearercap has NO influence on the
route path of switched circuits in the ISDN/PSTN. It is totally
ineffective for avoiding *enhancements* such as AT&T's True Voice. As
far as SS7 routing goes, while it is possible to route specially, based
on separate voice bearercaps, the practise is non-existent! As Thor
points out, other bits are embedded within the initial setup message to
indicate that compression is enabled, that echo cancelling is already
active, that the call's rearward route path has already traversed a
satellite, etc. Unfortunately, there is no way for a "voice" caller from
the ISDN/PSTN to indicate to the SS7/IP gateway that the full 64K is
needed for transport within the Internet BECAUSE MAYBE THAT WILL SOUND
BETTER to the caller. Instead, any voice bearercap for a crossover
PSTN/ISDN caller to the Internet Telephone answerer will be given to the
SS7/IP gateway and be subject to the *enhancement* provided by a
G-whatever vocoder !!! (I don't claim to know IP telephony standards
citations all that well, either ;-)
> The 8 kHz integrity (as I understand it) only means that you will get
> a sample rate of 8 kHz. It does not mean that the value of each
> sample will be unaffected. The amplitude of the sample may be changed
> (eg the signal may be run through a digital filter.)
>
> > This NEW voice bearer will make IP telephony crossover, between the
> > packet switched world of IP telephony and the circuit switched world of
> > ISDN/PSTN, able to avoid unnecessairy *enhancements* that can be
> > selected by switch translations provisioning, along the route request
> > control signaling path(s) that provide call setup!
> If you are sending IP packetized, compressed voice to some special
> telephone like device (ie a PC with speaker and mic) then the device
> should be able to accept an ISDN data call.
Egads, given you last sentence, then how can a *real data* crossover
(ISDN-to-IP) call be established with the PC? If ISDN *data* bearercaps
and *voice* bearercaps are converted to *packetized data* bearercaps at
the SS7/IP gateway, then how is the PC supposed to know which answering
device to use for an incoming call? These crossover calls are either a
PPP connection for *real data* appropriately answered at the PC's COM
port (for example), or *real voice* appropriately answered by the
Internet Telephone at the PC's sound card, or the crossover call may be
*data voice* (analog modem/fax) that really needs to "talk" to an analog
modem/fax at the PC's COM port (for example) ...
> > BTW, you aren't
> > suggesting that the Q.931 component of IP telephony use bearer requests
> > for "Packet, Unrestricted Data mode", are you? I suppose that is
> > possible, but I would convert such a request at the SS7/IP gateway
> > boundary, no?
> I thought the component of IP telephony (H.323) was H.225. I'm not
> familiar with this spec, so I don't know what the BCs are. But at the
> IP/SS7 or IP/ISDN gateway, the call should go out as a speech or 3.1
> kHz audio call. If you need a special BC to turn off the echo
> cancelers, etc, use the 3.1 kHz audio.
> -----------------------------------
> Hank Karl
> Opinions mine, not my company's
> to reply, remove the "imnothere" from my address
I thought the call setup "control signaling" component of H.323 was
Q.931. If this is true, then a PC attached to the Internet by a PPP
connection to its ISP can be able to request a 56 kbit/s data call or a
64 kbit/s data call, to the same ISDN destination call-to numbers, as
are able to be requested for voice bearercaps of audio and speech. The
mapping seems obvious to me, but the Internet Telephone IP telephony
voice caller may prefer the voice quality of human conversation that
does not receive further *enhancements* within the ISDN/PSTN, and that
is why I promote the definition of a NEW voice bearercap that requests
that the network give the best end-to-end treatment as possible for
so-inclined voice callers. This is NOT a 64 kbit/s data bearercap,
because a data bearercap request will NOT be presented to a POTS line to
answer !!! (Except, of course, with Laurence-influenced DMS switch
mistranslations ;-)
Thanks for trying. Jeffrey
Eric Smith
> It is always acceptable for the carrier to apply lossless digital
> compression, since by definition the customer(s) can't tell the
> difference.
himnoth...@imnotherenlc.com (Hank Karl) writes:
> Provided there is no significant delay introduced.
How much delay is significant? And even if the delay was significant, how
could the customer tell that the delay was caused by lossless compression,
rather than some other cause (like routing the call through a satellite
link to Lower Slobovia)?
Robert Blackshaw
category - that's (roughly speaking) 64kbit/s ADPCM.
> > > The request is for 8 kHz integrity, as you know, what you get is what
> > > you get once the circuit switch mode call is answered and the route path
> > > for the "voice signal" is transported end-to-end. It's all that stuff in
> > > between that "data" calls are able to avoid, that I promote to be
> > > bypassable via a NEW voice bearer, since it is not a capability that we
> > > all seek with our ISDN calls, it is a request that we make.
> > > Unfortunately, once a "voice" call is promoted to a "data" call, the
> > > routing network that establishes the circuit switch mode route path is
> > > unable to demote back to "ring" an analog phone.
> > I'll assume that you are talking about fax here. Speech is a
> > non-issue, and is already handled. Fax does not need 64K, it works
> > fine on existing voice type lines at 56K, provided you turn off
> > "enhancements". That's what 3.1 kHz audio is for.
>
> Where do I lose you? 3.1kHz audio bearercap has NO influence on the
> route path of switched circuits in the ISDN/PSTN. It is totally
> ineffective for avoiding *enhancements* such as AT&T's True Voice.
Then whoever wrote the switch software needs to be taken to the
woodshed. :-)
> As
> far as SS7 routing goes, while it is possible to route specially, based
> on separate voice bearercaps, the practise is non-existent! As Thor
> points out, other bits are embedded within the initial setup message to
> indicate that compression is enabled, that echo cancelling is already
> active, that the call's rearward route path has already traversed a
> satellite, etc. Unfortunately, there is no way for a "voice" caller from
> the ISDN/PSTN to indicate to the SS7/IP gateway that the full 64K is
> needed for transport within the Internet BECAUSE MAYBE THAT WILL SOUND
> BETTER to the caller.
They could try IEEE 802.9 :-)
> Instead, any voice bearercap for a crossover
> PSTN/ISDN caller to the Internet Telephone answerer will be given to the
> SS7/IP gateway and be subject to the *enhancement* provided by a
> G-whatever vocoder !!! (I don't claim to know IP telephony standards
> citations all that well, either ;-)
>
G.711 for mu-law, but there's a whole bunch.
> > The 8 kHz integrity (as I understand it) only means that you will get
> > a sample rate of 8 kHz. It does not mean that the value of each
> > sample will be unaffected. The amplitude of the sample may be changed
> > (eg the signal may be run through a digital filter.)
IIRC 8 kHz means that whatever 8 bits the sender inputs will be
delivered as the same 8 bits, kind of implies byte timing.
H.323 does indeed use Q.931 signaling and can use G.711, G.722, G.723
or G.728 voice. Then throw in H.245 control, T.120, etc. However,
it only talks to the real world through a gateway of some sort.
> Thanks for trying. Jeffrey
Anytime. :-)
Amanda Walker
>Amanda Walker wrote:
>> Data means "the bits are important."
>Also, "please answer the call with a data device", OK?
Actually, no, at least not as I understand it. Q.931 does not
mark the *purpose* of the signal, just its nature. A "data"
call at the Q.931 level just means that the bits themselves
are the signal. Those bits may be 8KHz audio, MPEG-compressed
32KHz audio, voice over IP, or whatever.
Now, it's common for cheap endpoint equipment to route calls
based on the bearer capability of a call in an inflexible
fashion (i.e, you often can't route data calls to a POTS jack),
but that's not actually what the BC is for; it's just a
description of what the payload is, not what it's for.
Personally, I like using DNIS for call routing rather than
the BC, but I realize that many people don't think that way.
>> 3.1KHz Audio means "the sound is important, and don't assume it's speech."
>So that means it is OK to "provide lossless digital compression to 9600
>bit/s when possible", right"
It means that the payload is a 3.1KHz bandwidth audio signal.
What is or is not be done to it is determined by the policy of
the *carrier*, not by Q.931.
>> Speech means "the sound is important, and it's probably speech."
>And elaborate, consecutive, accumulated *enhancements* may make the
>resulting, answered connection immutable ;-)
If that is the policy of the carrier(s) involved, yes. Conversely,
it may also mean that the call can be completed over links that are
not digital at all. Sometimes this is better than nothing. There
are still lots of Trailblazers running UUCP over lossy analog trunks
all over the world.
I think that what you want to happen is fine; I just don't think that
adding new Q.931 bearer capabilities is the place to do it.
Amanda Walker
>Unfortunately, there is no way for a "voice" caller from
>the ISDN/PSTN to indicate to the SS7/IP gateway that the full 64K is
>needed for transport within the Internet BECAUSE MAYBE THAT WILL SOUND
>BETTER to the caller.
Indeed. It doesn't know. There are two ways to get you call across
the network: speak H.323 directly, and use an IP data service (all
audio processing is done at the endpoint, which should provide the
highest quality), or speak audio and let the gateway deal with it
according to whatever policy it is configured to apply.
>If ISDN *data* bearercaps
>and *voice* bearercaps are converted to *packetized data* bearercaps at
>the SS7/IP gateway, then how is the PC supposed to know which answering
>device to use for an incoming call?
Any number of ways. Use DNIS. Look to see if the first bit of data
looks like HDLC. Speak IP to the gateway, and run H.323 over a
pre-established PPP connection. PC endpoints are the most flexible,
not the least flexible. VOIP "phone sets" are likely to be the
most annoying, though they are likely to be baby PCs in phone-shaped
cases anyway.
>This is NOT a 64 kbit/s data bearercap,
>because a data bearercap request will NOT be presented to a POTS line to
>answer !!!
I think this is an endpoint equipment inflexible policy problem,
not a bearer capability problem.
Amanda Walker
> > It is always acceptable for the carrier to apply lossless digital compression,
> > since by definition the customer(s) can't tell the difference.
An endpoint cannot constrain what delay is introduced. One
satellite hop, for example, will introduce far more delay than
most audio compression schemes.
Robert Blackshaw
in the Compatibility IEs, though I doubt many devices pay much
attention to them.
Hank Karl
<eric-no-spam-...@brouhaha.com> wrote:
> I wrote:
> > It is always acceptable for the carrier to apply lossless digital
> > compression, since by definition the customer(s) can't tell the
> > difference.
>
> himnoth...@imnotherenlc.com (Hank Karl) writes:
> > Provided there is no significant delay introduced.
>
> How much delay is significant? And even if the delay was significant, how
> could the customer tell that the delay was caused by lossless compression,
> rather than some other cause (like routing the call through a satellite
> link to Lower Slobovia)?
I'd say two seconds for the overall delay is not bad (its not good
either), but the compression will be only one component. You may have
that sattelite link added to the compression delay.
The delay I was thinking of is generally caused by getting enough
samples to start up the compression algorithm (eg some compression
routines build a dictionary based on all the data). The processing
part of the compression delay may be addressed by selecting a faster
compression device.
Hank Karl
<jeffrey...@attws.com> wrote:
Jeff,
It seems the whole argument (well, a good part of it anyway) in this
thread is "what is the meaning of the Speech BC and the 3.1 kHz BC"?
You seem to have a different idea of what they do than I do. I don't
have a spec in front of me, but if alone can check a spec and post the
difference between 3.1 kHz and speech, they would help us put this
issue to bed.
The network may violate the specs. It may be their policy to, or it
may be a limitation of the equipment they use. Just because one
player violates the specs does not mean that we need a new BC (so they
can violate that one too?).
My understanding is that 3.1 kHz audio should not have any
enhancements to it. The bits presented on one side (at least the 7
MSB in each octet) should come out the other, the only difference
between input and output would be a time delay.
>
> > The 8 kHz integrity (as I understand it) only means that you will get
> > a sample rate of 8 kHz. It does not mean that the value of each
> > sample will be unaffected. The amplitude of the sample may be changed
> > (eg the signal may be run through a digital filter.)
> >
> > > This NEW voice bearer will make IP telephony crossover, between the
> > > packet switched world of IP telephony and the circuit switched world of
> > > ISDN/PSTN, able to avoid unnecessairy *enhancements* that can be
> > > selected by switch translations provisioning, along the route request
> > > control signaling path(s) that provide call setup!
> > If you are sending IP packetized, compressed voice to some special
> > telephone like device (ie a PC with speaker and mic) then the device
> > should be able to accept an ISDN data call.
>
> Egads, given you last sentence, then how can a *real data* crossover
> (ISDN-to-IP) call be established with the PC? If ISDN *data* bearercaps
> and *voice* bearercaps are converted to *packetized data* bearercaps at
> the SS7/IP gateway, then how is the PC supposed to know which answering
> device to use for an incoming call? These crossover calls are either a
> PPP connection for *real data* appropriately answered at the PC's COM
> port (for example), or *real voice* appropriately answered by the
> Internet Telephone at the PC's sound card, or the crossover call may be
> *data voice* (analog modem/fax) that really needs to "talk" to an analog
> modem/fax at the PC's COM port (for example) ...
The device I have in mind is connected to the PSTN via ISDN, and to an
ISP via AO/DI. It can answer both ISDN calls and IP telephony calls.
DOV works by using the destination number to determine the routing of
the call (to an HDLC controller or a modem). You could do the same
with voice on a data bearer.
If you get a call with BC=data, you don't know what that data is
anyway. You may only accept PPP or V.120 (or PPP over V.120) or it
could be T.90 or LAPB or X.25 or SNA or speech or some higher fidelity
speech compressed to 8 kbytes/sec.
The VoIP to PSTN crossover point is not really an issue here, the
issue is can a device receive a call and run the bitstream through a
codec, and can tell the system that it can accept speech calls and
that it can accept data calls. The network doesn't care that the data
transferred is voice data.
>
> > > BTW, you aren't
> > > suggesting that the Q.931 component of IP telephony use bearer requests
> > > for "Packet, Unrestricted Data mode", are you? I suppose that is
> > > possible, but I would convert such a request at the SS7/IP gateway
> > > boundary, no?
> > I thought the component of IP telephony (H.323) was H.225. I'm not
> > familiar with this spec, so I don't know what the BCs are. But at the
> > IP/SS7 or IP/ISDN gateway, the call should go out as a speech or 3.1
> > kHz audio call. If you need a special BC to turn off the echo
> > cancelers, etc, use the 3.1 kHz audio.
> > -----------------------------------
> > Hank Karl
> > Opinions mine, not my company's
> > to reply, remove the "imnothere" from my address
>
> I thought the call setup "control signaling" component of H.323 was
> Q.931.
H.225 is a descendant of Q.931. Not having seen that spec, I can't
say if or how much it varies from Q.931. I suspect that there would
be at least a difference for the IEs dealing with the channel IDs,
because IP is not channelized like a BRI or PRI.
> If this is true, then a PC attached to the Internet by a PPP
> connection to its ISP can be able to request a 56 kbit/s data call or a
> 64 kbit/s data call, to the same ISDN destination call-to numbers, as
> are able to be requested for voice bearercaps of audio and speech.
This may be correct, I don't know, but suspect that you can do at
least this much.
> The
> mapping seems obvious to me, but the Internet Telephone IP telephony
> voice caller may prefer the voice quality of human conversation that
> does not receive further *enhancements* within the ISDN/PSTN, and that
> is why I promote the definition of a NEW voice bearercap that requests
> that the network give the best end-to-end treatment as possible for
> so-inclined voice callers.
Depends on who pays the PSTN bill. If billing goes to the user, the
user can select the QOS. If the Gateway will be the one paying for
the call, the user may not have a choice. But this all depends on the
definition of the "speech" and "3.1 kHz audio" BCs.
>This is NOT a 64 kbit/s data bearercap,
> because a data bearercap request will NOT be presented to a POTS line to
> answer !!! (Except, of course, with Laurence-influenced DMS switch
> mistranslations ;-)
And it need not (but probably will be) a 64K voice call. Generally,
voice is fine at 56K. (But nowadays you usually get 64K clear
channel, 56K seems to be almost gone).
Hank Karl
<blac...@erols.com> wrote:
> Jeffrey Rhodes wrote:
> >
> > Where do I lose you? 3.1kHz audio bearercap has NO influence on the
> > route path of switched circuits in the ISDN/PSTN. It is totally
> > ineffective for avoiding *enhancements* such as AT&T's True Voice.
>
> Then whoever wrote the switch software needs to be taken to the
> woodshed. :-)
Don't get out your switch too quickly there Bob :-) The switch could
be OK. It could be the network guys provisioned it incorrectly by
either policy or error.
>
> > > The 8 kHz integrity (as I understand it) only means that you will get
> > > a sample rate of 8 kHz. It does not mean that the value of each
> > > sample will be unaffected. The amplitude of the sample may be changed
> > > (eg the signal may be run through a digital filter.)
>
> IIRC 8 kHz means that whatever 8 bits the sender inputs will be
> delivered as the same 8 bits, kind of implies byte timing.
If I read this one way, I agree. But the first time I read it, I may
have read it wrong. When you say "the same 8 bits" do you mean that
the 8 bits form a byte, and the contents of the byte are unchanged, or
that the bits in a byte are numbered from 0 to 7, and each side knows
which bit is which (i.e. each side knows where the byte boundaries
are)?
I thought 8 kHz meant that the bytes would be presented on the same
boundary -- you could look at the data as a string of bytes and know
where the MSB was always. This is so you could use the frame sync
from the DSL rather than embedding a frame sync into your datastream
when running the data to a codec. I thought it did not guarantee that
the bytes going in one side will be the same bytes coming out the
other side (ie a value of 0x98 on one side may be seen as 0x95 on the
other).
An example would be BC=speech, which has 8 kHz integrity. Assume
codecs on each side and that the call goes over some analog link
somewhere. The datastream each endpoint would get would have 8 kHz
integrity (ie be byte-aligned) but the value of each byte may change
slightly (or not-so-slightly on Jeff's network :-)
Robert Blackshaw
>
> On Wed, 07 Oct 1998 07:46:26 -0400, Robert Blackshaw
> <blac...@erols.com> wrote:
>
> > Jeffrey Rhodes wrote:
> > >
>
> > > route path of switched circuits in the ISDN/PSTN. It is totally
> > > ineffective for avoiding *enhancements* such as AT&T's True Voice.
> >
> > Then whoever wrote the switch software needs to be taken to the
> > woodshed. :-)
> be OK. It could be the network guys provisioned it incorrectly by
> either policy or error.
>
> >
> > > > a sample rate of 8 kHz. It does not mean that the value of each
> > > > sample will be unaffected. The amplitude of the sample may be changed
> > > > (eg the signal may be run through a digital filter.)
> >
> > IIRC 8 kHz means that whatever 8 bits the sender inputs will be
> > delivered as the same 8 bits, kind of implies byte timing.
> have read it wrong. When you say "the same 8 bits" do you mean that
> the 8 bits form a byte, and the contents of the byte are unchanged, or
> that the bits in a byte are numbered from 0 to 7, and each side knows
> which bit is which (i.e. each side knows where the byte boundaries
> are)?
>
give mostly noise. A lot of European nets do provide byte timing
though there were some interesting deals proposed for video
conferencing where the TA was delivering 56k adaptation simply
directed at finding the byte boundaries, forget the number of
the paper at the moment.
> I thought 8 kHz meant that the bytes would be presented on the same
> boundary -- you could look at the data as a string of bytes and know
> where the MSB was always. This is so you could use the frame sync
> from the DSL rather than embedding a frame sync into your datastream
> when running the data to a codec. I thought it did not guarantee that
> the bytes going in one side will be the same bytes coming out the
> other side (ie a value of 0x98 on one side may be seen as 0x95 on the
> other).
>
Only in an A-law to mu-law translation I hope!
> An example would be BC=speech, which has 8 kHz integrity. Assume
> codecs on each side and that the call goes over some analog link
> somewhere. The datastream each endpoint would get would have 8 kHz
> integrity (ie be byte-aligned) but the value of each byte may change
> slightly (or not-so-slightly on Jeff's network :-)
> >
Hmm, yes I can see how that could happen.
Jeffrey Rhodes
Eric,
I did exaggerate a little. I meant to say 4800 bps. Does that change
your math any?
Most people flying over North America in commercial aircraft are only
able to connect with 2400 bps fax calls, either to, or from, the
PSTN/ISDN. An entire fax page is converted to its inherent digital
information content, onboard the aircraft, and then this "stored"
content is "forwarded" (store and forward) to the ground at 4800 bps.
I'm pretty sure that before an airborne fax sender gets confirmation
that a page has been received, that the on-board DSP, that provides the
lossless digital compression, has received radio confirmation for the
entire page from the ground, where the information content is
reconstructed to 64000 bit/s for transport within the PSTN/ISDN.
It IS possible to digitally compress the 64000 bps *encoding* losslessly
at a network element, to the 2400 bps that the fax caller only really
requires, for perfect reproduction of the original information content
at the answering fax. There is no need to use 8 KHz sampling, either. I
wouldn't guarantee that every bit of every byte sent is delivered the
same under this arrangement, and that is another reason why a NEW voice
bearer is needed to "signal" to the network elements that complete a
call, that EVERY BIT OF EVERY BYTE MUST BE THE SAME end-to-end !!! As
far as SS7 routing is concerned, there is no way for a voice call to
guarantee this quality of service.
Regards,
Jeffrey
Eric Smith
> I did exaggerate a little. I meant to say 4800 bps. Does that change
> your math any?
It's closer. I completely understand your argument about compressing fax
by demodulating it and sending the digital bits. That works great.
My argument is with your statement that you can in general do lossless
comression of a 3.1 KHz bandlimited audio signal with 8-bit nonlinear
quantization down to 2400 (or 4800) bps. Yes, if you know that it fax
(or some other well-known low-rate modem modulation) you can do it. But
what if my 3.1 KHz signal was from a V.32 modem?
My point is that you can only guarantee to do lossless compression if you
can make some assumptions about the content.
With regard to ISDN bearer capabilities, if I specify 3.1KHz audio, I
don't expect the carrier to apply any ADPCM compression or TrueSpeech
processing. However, I don't know what the carriers actually do (*).
Cheers
Eric
(*) Except that AT&T will bill me at a higher rate for anything that isn't
simple voice. I asked them why, and they had some bullshit excuse about
fraud prevention costing them more on data calls.
Hank Karl
<blac...@erols.com> wrote:
> Hank Karl wrote:
> > I thought 8 kHz meant that the bytes would be presented on the same
> > boundary -- you could look at the data as a string of bytes and know
> > where the MSB was always. This is so you could use the frame sync
> > from the DSL rather than embedding a frame sync into your datastream
> > when running the data to a codec. I thought it did not guarantee that
> > the bytes going in one side will be the same bytes coming out the
> > other side (ie a value of 0x98 on one side may be seen as 0x95 on the
> > other).
> >
> Only in an A-law to mu-law translation I hope!
>
That would be one instance. Another is any kind of filter on the
line. A 12K lowpass filter will pass voiceband data (300 Hz - 3,400
Hz, more or less) but it will distort the signal by introducing some
phase delays, etc. The digital version of the filter will also
distort the signal. The distortion may not be noticeable by a human,
but it would dramatically affect HDLC data.
> > An example would be BC=speech, which has 8 kHz integrity. Assume
> > codecs on each side and that the call goes over some analog link
> > somewhere. The datastream each endpoint would get would have 8 kHz
> > integrity (ie be byte-aligned) but the value of each byte may change
> > slightly (or not-so-slightly on Jeff's network :-)
> > >
> Hmm, yes I can see how that could happen.
>
> Bob
-----------------------------------
Hank Karl
<jeffrey...@attws.com> wrote:
> Most people flying over North America in commercial aircraft are only
> able to connect with 2400 bps fax calls, either to, or from, the
> PSTN/ISDN. An entire fax page is converted to its inherent digital
> information content, onboard the aircraft, and then this "stored"
> content is "forwarded" (store and forward) to the ground at 4800 bps.
> I'm pretty sure that before an airborne fax sender gets confirmation
> that a page has been received, that the on-board DSP, that provides the
> lossless digital compression, has received radio confirmation for the
> entire page from the ground, where the information content is
> reconstructed to 64000 bit/s for transport within the PSTN/ISDN.
>
> It IS possible to digitally compress the 64000 bps *encoding* losslessly
> at a network element, to the 2400 bps that the fax caller only really
> requires, for perfect reproduction of the original information content
> at the answering fax. There is no need to use 8 KHz sampling, either. I
> wouldn't guarantee that every bit of every byte sent is delivered the
> same under this arrangement, and that is another reason why a NEW voice
> bearer is needed to "signal" to the network elements that complete a
> call, that EVERY BIT OF EVERY BYTE MUST BE THE SAME end-to-end !!! As
> far as SS7 routing is concerned, there is no way for a voice call to
> guarantee this quality of service.
>
Jeff, in this store and forward approach, are you saying that the user
on the airplane connects to a special device that is similar to a fax
modem on the airplane, sends his fax to that device, that device sends
the digital data to a ground station, which then remodulates it via
another "fax modem" and sends it via the PSTN to its destination?
If this is the case, then you don't need a special BC because the
modulated signal on the plane probably doesn't have any special
processing applied to it between the user's PC and the "fax modem" on
the plane. (even if it did, the signal should be reconstructed
correctly by the "fax modem"). The digital signal can be sent as a
bunch of packets or as a stream of data (actually, you may consider
that stream as one big packet). The ground station (or ground station
network) will re modulate the digitized fax data (at 2400 bps) onto a
digital trunk where (one hopes) it only goes through one IXC before it
reaches it's ultimate destination. Also, the IXC _should_ be able to
pass fax data without a problem.
If I understand you correctly, this special case of faxing degenerates
to be essentially the same as two regular fax machines connecting.
(Actually, its even better because the ground station does not have an
analog path to the network.)
Jeffrey Rhodes
> >the ISDN/PSTN to indicate to the SS7/IP gateway that the full 64K is
> >needed for transport within the Internet BECAUSE MAYBE THAT WILL SOUND
> >BETTER to the caller.
>
> the network: speak H.323 directly, and use an IP data service (all
> audio processing is done at the endpoint, which should provide the
> highest quality), or speak audio and let the gateway deal with it
> according to whatever policy it is configured to apply.
Hello Amanda,
In terms of MultiVoice and IP Navigator-speak, how many "Absolute QOS"
are able to be mapped to native IP's Type of Service? Would you agree
that IP's TOS=7 (bits 3,4,5 in header) is equivalent to the bit-for-bit,
every byte the same, in and out end-to-end, copy guarantee that I seek
for a NEW voice bearercap? I suspect you would choose to map this
request for bit integrity to ISDN's 64 kbit/s Unrestricted data
bearercap only, yes?
> >If ISDN *data* bearercaps
> >and *voice* bearercaps are converted to *packetized data* bearercaps at
> >the SS7/IP gateway, then how is the PC supposed to know which answering
> >device to use for an incoming call?
>
> Any number of ways. Use DNIS. Look to see if the first bit of data
> looks like HDLC. Speak IP to the gateway, and run H.323 over a
> pre-established PPP connection. PC endpoints are the most flexible,
> not the least flexible. VOIP "phone sets" are likely to be the
> most annoying, though they are likely to be baby PCs in phone-shaped
> cases anyway.
Do you mean Dialed Number Incoming Service for DNIS? But that implies
that an ISDN user needs two numbers, one for *data* and one for *voice*,
right? I want all my numbers to do both. I think it makes sense to have
separate call forwarding activations for *voice* features vs. *data*
features. Actually, there aren't too many times I would want to forward
any of my *data* calls, if ever.
> >This is NOT a 64 kbit/s data bearercap,
> >because a data bearercap request will NOT be presented to a POTS line to
> >answer !!!
>
> I think this is an endpoint equipment inflexible policy problem,
> not a bearer capability problem.
Well, the entire end-point, network/user border, of ISDN would need to
change to route ISDN data bearercaps to voice-only provisioned numbers.
That makes it pretty inflexible, right? Are you suggesting that all
calls should ALWAYS be delivered, regardless of bearercap, and ALWAYS
answered by ISDN answering equipment that is able to probe the resultant
connection for protocols, details, device to "ring", etc. ?????
> Amanda Walker
> Senior Software Engineer
> Ascend Communications, Inc.
> [personal opinion, not an official statement from Ascend]
Jeffrey Rhodes
Sr. Systems Engineer
AT&T Wireless Services
regards, jcr ;-)
Jeffrey Rhodes
...
> Jeff, in this store and forward approach, are you saying that the user
> on the airplane connects to a special device that is similar to a fax
> modem on the airplane, sends his fax to that device, that device sends
> the digital data to a ground station, which then remodulates it via
> another "fax modem" and sends it via the PSTN to its destination?
Yes, this is correct. AT&T FFAST did the system design and Claircom
engineers built boards into their reverse engineered ISDN PBX in the sky
;-)
> If this is the case, then you don't need a special BC because the
> modulated signal on the plane probably doesn't have any special
> processing applied to it between the user's PC and the "fax modem" on
> the plane. (even if it did, the signal should be reconstructed
> correctly by the "fax modem"). The digital signal can be sent as a
> bunch of packets or as a stream of data (actually, you may consider
> that stream as one big packet). The ground station (or ground station
> network) will re modulate the digitized fax data (at 2400 bps) onto a
> digital trunk where (one hopes) it only goes through one IXC before it
> reaches it's ultimate destination. Also, the IXC _should_ be able to
> pass fax data without a problem.
Now why would it matter how many IXCs are involved? Obviously AT&T is
one IXC and the called number is a LEC, so what is so special about the
number of carriers involved on the ground? Like I've said, it won't
matter what voice bearercap is generated for the call setup requested by
the ground faxer, both audio and speech are routed the same within the
switched circuits that SS7 "control signaling" is able to provide.
> If I understand you correctly, this special case of faxing degenerates
> to be essentially the same as two regular fax machines connecting.
> (Actually, its even better because the ground station does not have an
> analog path to the network.)
Yes, this is correct. And regardless of bearercap, the AT&T
TrueVoice(tm) circuits are bypassed by disabling the echo cancellers. As
you must know, this can be done AFTER the call is answered, and cannot
help but be done, when the reconstructed 64000 bit/s data stream
constitutes the *sound* that an analogmodem/fax makes. The TV(tm)
circuits do not care what voice bearercap is requested, speech and audio
can both be an analog modem or fax caller, and the right TV(tm) circuits
will be enabled based on SS7 echo canceller bits.
Oh yes, Thor, the SS7 echo canceller bits are able to keep off TV(tm) in
some AT&T circuit switches, but one of the AT&T circuit switches in the
call's routepath will have the TV(tm) enabled, perhaps regardless of the
SS7 bit setting, but certainly regardless of the voice bearercap
setting. As you all probably know, a single echo canceller in each
direction is more effective than piling on the echo cancellers. The
enabled echo cancellers will automatically be turned off (ie, become
disabled), and stay off, provided the 64000 bit/s data stream thru their
DSPs is able to *sound* like an analog modem or fax. I think it is
sufficient to state that, once disabled, the active TV(tm) echo
cancellers will remain disabled, as long as the analog energy equivalent
of the 64000 bit/s data stream is not characteristically "low", for 250
milliseconds or so.
> -----------------------------------
> Hank Karl
> Opinions mine, not my company's
> to reply, remove the "imnothere" from my address
Hank, you do understand that I have provided this air-to-ground fax
example merely to indicate how a voice bearercap for audio can be
digitally compressed losslessly, without regard for "bit-for-bit byte
integrity" of 64000 bit/s, right? The NEW voice bearercap is not needed
for this type of call. BTW, ground-to-air fax is also possible, and
this, too, does not depend on voice bearercap, either.
The NEW voice bearercap has always been needed for digital cellphone to
digital cellphone calls when the call's routepath is via the ISDN/PSTN
circuit switch networks that do not provide "bit-for-bit byte
integrity". (OK, that's a stretch, but each *enhancement* adds a little,
to the overall end-to-end delay characteristic ;-) Now that the packet
switched Internet network is able to provide IP telephony, the NEW voice
bearercap is needed for cross-over voice calls that seek end-to-end ISDN
"bit-for-bit byte integrity", even across the SS7/IP gateway boundary.
The NEW voice bearercap would be useful for private voice encryption,
direct TDMA to TDMA packet delivery bypass of long distance switch
circuits, etc. and is not limited to cross-over voice calls.
Regards, Jeffrey
Robert Blackshaw
>
> Eric Smith wrote:
> >
> > I wrote:
> > > Since there is no way to do lossless compression of 3.1 KHz audio at 8-bit
> > > quantization and 8 KHz sampling down to 9600 bps, your statement is
> > > meaningless anyhow.
> >
> > Jeffrey Rhodes <jeffrey...@attws.com> writes:
> > > Au contraire. A fax caller onboard a commercial aircraft can use an ISDN
> > > voice bearer to indicate that a fax assisted, digital lossless
> > > compression of the fax information content is requested onboard, so that
> >
> > Yes. That is lossless fax compression. It is most decidedly not lossless
> > audio compression. The audio coming out the end may be measurably different
> > than the audio at the near end; it just won't be different in any way that
> > will matter to a V.29 modem.
> >
> > But just because I use a bearer capability of 3.1 KHz audio doesn't tell
> > the phone company that I am doing fax. Therefore, in the general case,
> > they can't demodulate it to use a lower bit rate.
> >
> > > So there, what do you know? It IS possible to provide lossless digital
> > > compression for BC=3.1KHz Audio bearercaps, if that is what the network
> > > provider that receives that bearercap request, wants to do.
> >
> > No, it is NOT.
> >
> >
> > is theoretically required. For 8-bit quantization, this still would require
> > 49.6 Kbps, a far cry from your claimed 9600 bps.
> >
> > Eric
>
> Eric,
>
> your math any?
>
> able to connect with 2400 bps fax calls, either to, or from, the
> PSTN/ISDN. An entire fax page is converted to its inherent digital
> information content, onboard the aircraft, and then this "stored"
> content is "forwarded" (store and forward) to the ground at 4800 bps.
> I'm pretty sure that before an airborne fax sender gets confirmation
> that a page has been received, that the on-board DSP, that provides the
> lossless digital compression, has received radio confirmation for the
> entire page from the ground, where the information content is
> reconstructed to 64000 bit/s for transport within the PSTN/ISDN.
>
4800bps, and I doubt that it has improved too much.
Laurence V. Marks
>The 8 kHz integrity (as I understand it) only means that you will get
>a sample rate of 8 kHz. It does not mean that the value of each
>sample will be unaffected. The amplitude of the sample may be changed
>(eg the signal may be run through a digital filter.)
My understanding of 8 KHz integrity is that byte boundaries are preserved.
What you put in on each sample of a B-channel comes out that way on the
other end. You absolutely need this with speech samples--they would be
trashed if slipped by a bit either way. You don't need it on HDLC-ish
data, and such data changes alignment with every zero-bit-insert after
five ones, anyway, but you get it. I think you get it on all
circuit-switched services, just not on packet-switched. And you certainly
don't need it there.
Or is Jeffrey lobbying for packet-switched service with 8 KHz integrity.?
Laurence V. Marks
IBM Corp. - Research Triangle Park, NC
Laurence V. Marks
>Now, it's common for cheap endpoint equipment to route calls
>based on the bearer capability of a call in an inflexible
>fashion (i.e, you often can't route data calls to a POTS jack),
>but that's not actually what the BC is for; it's just a
>description of what the payload is, not what it's for.
>
>Personally, I like using DNIS for call routing rather than
>the BC, but I realize that many people don't think that way.
>
We liked it in WaveRunner in 1994, too. We did that, and we also permitted
routing via BC. You could configure it either way.
Amanda Walker
> In <6vfsiv$6is$1...@news.intercon.com>, "Amanda Walker" <ama...@ascend.com> writes:
> >Now, it's common for cheap endpoint equipment to route calls
> >based on the bearer capability of a call in an inflexible
> Now Amanda, was that a nice thing to say about the USR Total Control rack?
Actually, I didn't have the Total Control in mind at all; I was
thinking of things like serial TAs ("ISDN Modems"), and meant "cheap"
as "inexpensive." No cheap shot (so to speak) intended. On the other
hand, any access concentrator these days that doesn't let the customer
decide what goes where is probably not going to sell as well.
> >Personally, I like using DNIS for call routing rather than
> We liked it in WaveRunner in 1994, too.
Yup. I always thought the WaveRunner was cool device.
Amanda Walker
> In terms of MultiVoice and IP Navigator-speak, how many "Absolute QOS"
> are able to be mapped to native IP's Type of Service?
Sigh. You're mixing layers again.
> Would you agree
> that IP's TOS=7 (bits 3,4,5 in header) is equivalent to the bit-for-bit,
> every byte the same, in and out end-to-end, copy guarantee that I seek
> for a NEW voice bearercap?
No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
provides no timing or delivery guarantees.
> I suspect you would choose to map this
> request for bit integrity to ISDN's 64 kbit/s Unrestricted data
> bearercap only, yes?
IP's ToS has nothing to do with "bit integrity". At the IP layer, each
packet either gets through or it doesn't. It's not a bit stream. Now,
some equipment (such as IP Navigator, or Cisco's tag switching stuff)
may decide to treat IP as stream protocol in order to provide additional
performance or services, but this is not something defined by IP; it's
a matter of policy implemented inside the router/switch/whatever. IP
itself remains strictly unsequenced datagrams delivered on a best-effort
basis. Anything else is layered on top of IP.
> Do you mean Dialed Number Incoming Service for DNIS?
Yes.
> But that implies that an ISDN user needs two numbers, one for *data* and
> one for *voice*,
I have yet to encounter an RBOC that doesn't force an ISDN user to have
two directory numbers on a BRI, actually. Might as well use them for
call routing :-).
> > I think this is an endpoint equipment inflexible policy problem,
> > not a bearer capability problem.
>
> Well, the entire end-point, network/user border, of ISDN would need to
> change to route ISDN data bearercaps to voice-only provisioned numbers.
If your line is provisioned for curcuit switched voice, you get to establish
virtual voice circuits. If you need to transport a bitstream (i.e., establish
a virtual circuit for digital data), why not provision the line for
circuit switched data?
Once again, I don't see (a) how this is a bearer capability problem, or
(b) how defining a new voice BC that is treated as a data BC by the
network will accomplish the goals you're describing.
> That makes it pretty inflexible, right? Are you suggesting that all
> calls should ALWAYS be delivered, regardless of bearercap, and ALWAYS
> answered by ISDN answering equipment that is able to probe the resultant
> connection for protocols, details, device to "ring", etc. ?????
Not at all. I'm suggesting that calls should be presented if the line
is provisioned for them. If the equipment on the other end can answer
them, it should accept the call. What the endpoint equipment decides
to do with it from there is up to it. The network doesn't care.
Hank Karl
<jeffrey...@attws.com> wrote:
> Hank Karl wrote:
> ...
> > Jeff, in this store and forward approach, are you saying that the user
> > on the airplane connects to a special device that is similar to a fax
> > modem on the airplane, sends his fax to that device, that device sends
> > the digital data to a ground station, which then remodulates it via
> > another "fax modem" and sends it via the PSTN to its destination?
>
> Yes, this is correct. AT&T FFAST did the system design and Claircom
> engineers built boards into their reverse engineered ISDN PBX in the sky
> ;-)
Jeff, I know that the entire job wasn't reverse engineered, it does
have ISDN in it.
>
> > If this is the case, then you don't need a special BC because the
> > modulated signal on the plane probably doesn't have any special
> > processing applied to it between the user's PC and the "fax modem" on
> > the plane. (even if it did, the signal should be reconstructed
> > correctly by the "fax modem"). The digital signal can be sent as a
> > bunch of packets or as a stream of data (actually, you may consider
> > that stream as one big packet). The ground station (or ground station
> > network) will re modulate the digitized fax data (at 2400 bps) onto a
> > digital trunk where (one hopes) it only goes through one IXC before it
> > reaches it's ultimate destination. Also, the IXC _should_ be able to
> > pass fax data without a problem.
>
> Now why would it matter how many IXCs are involved?
One hopes that each IXC will only apply one instance of signal
processing, etc. (see your note on echo cancelers below). If more
than one IXC handle a call, each IXC may process the signal.
> Obviously AT&T is
> one IXC and the called number is a LEC, so what is so special about the
> number of carriers involved on the ground? Like I've said, it won't
> matter what voice bearercap is generated for the call setup requested by
> the ground faxer, both audio and speech are routed the same within the
> switched circuits that SS7 "control signaling" is able to provide.
>
> > If I understand you correctly, this special case of faxing degenerates
> > to be essentially the same as two regular fax machines connecting.
> > (Actually, its even better because the ground station does not have an
> > analog path to the network.)
>
> Yes, this is correct. And regardless of bearercap, the AT&T
> TrueVoice(tm) circuits are bypassed by disabling the echo cancellers. As
> you must know, this can be done AFTER the call is answered, and cannot
> help but be done, when the reconstructed 64000 bit/s data stream
> constitutes the *sound* that an analogmodem/fax makes. The TV(tm)
> circuits do not care what voice bearercap is requested, speech and audio
> can both be an analog modem or fax caller, and the right TV(tm) circuits
> will be enabled based on SS7 echo canceller bits.
>
> Oh yes, Thor, the SS7 echo canceller bits are able to keep off TV(tm) in
> some AT&T circuit switches, but one of the AT&T circuit switches in the
> call's routepath will have the TV(tm) enabled, perhaps regardless of the
> SS7 bit setting, but certainly regardless of the voice bearercap
> setting.
- > As you all probably know, a single echo canceler in each
- > direction is more effective than piling on the echo cancelers.
Jeffrey Rhodes
>
> Jeffrey Rhodes <jeffrey...@attws.com> writes:
> > In terms of MultiVoice and IP Navigator-speak, how many "Absolute QOS"
> > are able to be mapped to native IP's Type of Service?
>
> Sigh. You're mixing layers again.
You think this is bad? You should take a look at IS-41 Subsystems that
are redundantly required in the application layer and the transport
layer, yet are really pretty meaningless and only get in the way ;-)
> > Would you agree
> > that IP's TOS=7 (bits 3,4,5 in header) is equivalent to the bit-for-bit,
> > every byte the same, in and out end-to-end, copy guarantee that I seek
> > for a NEW voice bearercap?
>
> No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
> provides no timing or delivery guarantees.
>
> > I suspect you would choose to map this
> > request for bit integrity to ISDN's 64 kbit/s Unrestricted data
> > bearercap only, yes?
>
> IP's ToS has nothing to do with "bit integrity". At the IP layer, each
> packet either gets through or it doesn't. It's not a bit stream. Now,
> some equipment (such as IP Navigator, or Cisco's tag switching stuff)
> may decide to treat IP as stream protocol in order to provide additional
> performance or services, but this is not something defined by IP; it's
> a matter of policy implemented inside the router/switch/whatever. IP
> itself remains strictly unsequenced datagrams delivered on a best-effort
> basis. Anything else is layered on top of IP.
Well, this is the point I am making: there is no way for the Q.931
control signaling of H.323 SS7/IP gateways to indicate that the IP
portion of a crossover call has been *enhanced* by G-whatever vocoders,
and that further *enhancements* are NOT indicated, which is another way
of saying that the circuit switch portion of the call requires "bit for
bit, every byte the same" delivery to the called destination.
Or do you stand by the ISDN standards and try to claim that the
bearercap of 3.1KHz Audio is a sufficient mapping for such a call,
afterall the PSTN has been processing similar calls from cellular
switches without too much complaint, but then the public would probably
welcome any improvements that are more likely to be noticed when the
public's total call consumption is at least 50% crossover to cellular,
crossover to crossover call forwarding, or the existing digital cellular
to digital celluar calls.
Or do you believe that such a crossover call, bound to an circuit switch
dialed number, must be mapped to an ISDN bearercap of Unrestricted 64
kbit/s data? I don't think so, which is why I asked you:
> If your line is provisioned for curcuit switched voice, you get to establish
> virtual voice circuits. If you need to transport a bitstream (i.e., establish
> a virtual circuit for digital data), why not provision the line for
> circuit switched data?
>
> Once again, I don't see (a) how this is a bearer capability problem, or
> (b) how defining a new voice BC that is treated as a data BC by the
> network will accomplish the goals you're describing.
Well, do you see the connumdrom now? BTW, how does Ascend Multivoice
provide "Absolute QOS"? Is there an "Absolute QOS" for 64000 bit/s
"bit-for-bit, every byte the same"? Is there a different value for
"Absolute QOS" that maps to "audio, do what you like, it's only a speech
call" vs. "audio, but do what you like as long as the resulting
information content is able to fit within 3100 Hz analog modem call"?
> > That makes it pretty inflexible, right? Are you suggesting that all
> > calls should ALWAYS be delivered, regardless of bearercap, and ALWAYS
> > answered by ISDN answering equipment that is able to probe the resultant
> > connection for protocols, details, device to "ring", etc. ?????
>
> Not at all. I'm suggesting that calls should be presented if the line
> is provisioned for them. If the equipment on the other end can answer
> them, it should accept the call. What the endpoint equipment decides
> to do with it from there is up to it. The network doesn't care.
So we agree that converting the crossover call from IP to SS7 cannot
possibly guarantee "bit-for-bit, every byte the same" within the
PSTN/ISDN since the only existing ISDN standards bearercap that provides
that is Unrestricted 64000 bit/s data, right? Hmmmm, seems we need a NEW
voice bearercap to accomplish this overlooked benefit!
> Amanda Walker
> Senior Software Engineer
> Ascend Communications, Inc.
> [personal opinion, not an official statement from Ascend]
Jeffrey Rhodes
Sr. Systems Engineer
AT&T Wireless, Aviation Communications Division
Copyright by Jeffrey Rhodes for AT&T on October 12, 1998
Permission to recirculate within Usenet newsgroup comp.dcom.isdn,
unconditionally waivered ;-)
Jeffrey Rhodes
>
> Jeffrey Rhodes wrote:
> >
> > Most people flying over North America in commercial aircraft are only
> > able to connect with 2400 bps fax calls, either to, or from, the
> > PSTN/ISDN. An entire fax page is converted to its inherent digital
> > information content, onboard the aircraft, and then this "stored"
> > content is "forwarded" (store and forward) to the ground at 4800 bps.
> > I'm pretty sure that before an airborne fax sender gets confirmation
> > that a page has been received, that the on-board DSP, that provides the
> > lossless digital compression, has received radio confirmation for the
> > entire page from the ground, where the information content is
> > reconstructed to 64000 bit/s for transport within the PSTN/ISDN.
> >
> The last time I worked on the air-to-ground systems the rate was
> 4800bps, and I doubt that it has improved too much.
>
> Bob
Does that mean you know about the variable ringing frequency for
autoanswer fax vs. speech? What standard does this come from?
Someday multiple packet data call types will provide more "tunnels" that
can be "bumped" by voice calls. A fax delivered within E-mail to a
ground mail server could then do better than 2400/4800 on a good day,
and won't require the back-to-back faxing for lossless digital
compression ;-)
Regards, Jeffrey
Jeffrey Rhodes
>
> On Fri, 09 Oct 1998 14:51:54 -0700, Jeffrey Rhodes
> <jeffrey...@attws.com> wrote:
>
> > Hank Karl wrote:
> > ...
> > > Jeff, in this store and forward approach, are you saying that the user
> > > on the airplane connects to a special device that is similar to a fax
> > > modem on the airplane, sends his fax to that device, that device sends
> > > the digital data to a ground station, which then remodulates it via
> > > another "fax modem" and sends it via the PSTN to its destination?
> >
> > Yes, this is correct. AT&T FFAST did the system design and Claircom
> > engineers built boards into their reverse engineered ISDN PBX in the sky
> > ;-)
> Jeff, I know that the entire job wasn't reverse engineered, it does
> have ISDN in it.
The hardware is reverse engineered. Did you see where Cisco bought
Summa4, I guess to quelch the rumours of a Lucent merger? Some of the
software, the Level 2 stuff modified with "Rob signaling", is
leased/licensed from Telenetworks. Thanks. BTW, I came up with a way to
make the TEI assignments transparent between Type 1 handsets (TEI=0) and
Type 2 handsets (TEI auto assigned, at least 60 values descending from
126, for each E1).
> > Now why would it matter how many IXCs are involved?
> One hopes that each IXC will only apply one instance of signal
> processing, etc. (see your note on echo cancelers below). If more
> than one IXC handle a call, each IXC may process the signal.
Now that local service is becoming long distance service, now that local
portability means calls may "deflect" from a "default" switch, it is not
apparent that one carrier's enhancement needs to be able to prevent
other carrier's enhancement as the carrier's call establishes a "talk
path"?
>jcr> Oh yes, Thor, the SS7 echo canceller bits are able to keep off TV(tm) in
>jcr> some AT&T circuit switches, but one of the AT&T circuit switches in the
>jcr> call's routepath will have the TV(tm) enabled, perhaps regardless of the
>jcr> SS7 bit setting, but certainly regardless of the voice bearercap
>jcr> setting.
>jcr -- > As you all probably know, a single echo canceler in each
>jcr -- > direction is more effective than piling on the echo cancelers.
Of course, the bearercap request in an SS7 IAM or Q.931 SETUP message
has nothing to do with echo cancellers, right?
And I still want an answer to:
> > Hank, you do understand that I have provided this air-to-ground fax
> > example merely to indicate how a voice bearercap for audio can be
> > digitally compressed losslessly, without regard for "bit-for-bit byte
> > integrity" of 64000 bit/s, right? The NEW voice bearercap is not needed
> > for this type of call. BTW, ground-to-air fax is also possible, and
> > this, too, does not depend on voice bearercap, either.
> >
> > The NEW voice bearercap has always been needed for digital cellphone to
> > digital cellphone calls when the call's routepath is via the ISDN/PSTN
> > circuit switch networks that do not provide "bit-for-bit byte
> > integrity". (OK, that's a stretch, but each *enhancement* adds a little,
> > to the overall end-to-end delay characteristic ;-) Now that the packet
> > switched Internet network is able to provide IP telephony, the NEW voice
> > bearercap is needed for cross-over voice calls that seek end-to-end ISDN
> > "bit-for-bit byte integrity", even across the SS7/IP gateway boundary.
> > The NEW voice bearercap would be useful for private voice encryption,
> > direct TDMA to TDMA packet delivery bypass of long distance switch
> > circuits, etc. and is not limited to cross-over voice calls.
> >
And you do realize, that I realize, this is NOT a showstopper. It is
simply a suggested improvement that the ISDN standards have no means YET
to provide, since I believe I have convinced you that a bearercap
request for 3.1KHz Audio does NOT provide "bit-for-bit, every byte the
same" transport at intermediate "talk path" switches. This NEW voice
bearercap could be used to request a "talk path" that could support
end-to-end private voice encryption, too, though I believe thes most
useful use is for "mid-talk path *enhancement* requires mid-to-end bit
integrity".
Regards, Jeffrey
Robert Blackshaw
>
> Robert Blackshaw wrote:
> >
> > Jeffrey Rhodes wrote:
> > >
> > > Most people flying over North America in commercial aircraft are only
> > > able to connect with 2400 bps fax calls, either to, or from, the
> > > PSTN/ISDN. An entire fax page is converted to its inherent digital
> > > information content, onboard the aircraft, and then this "stored"
> > > content is "forwarded" (store and forward) to the ground at 4800 bps.
> > > I'm pretty sure that before an airborne fax sender gets confirmation
> > > that a page has been received, that the on-board DSP, that provides the
> > > lossless digital compression, has received radio confirmation for the
> > > entire page from the ground, where the information content is
> > > reconstructed to 64000 bit/s for transport within the PSTN/ISDN.
> > >
> > The last time I worked on the air-to-ground systems the rate was
> > 4800bps, and I doubt that it has improved too much.
> >
> > Bob
>
> Does that mean you know about the variable ringing frequency for
> autoanswer fax vs. speech? What standard does this come from?
>
the data rate (at that time) was 4800 bit/s from the air (or
even when on the ground and the squat switch was on). They
may have improved the rate since then, it was back in '86.
Robert Blackshaw
>
> Jeffrey Rhodes <jeffrey...@attws.com> writes:
> > In terms of MultiVoice and IP Navigator-speak, how many "Absolute QOS"
> > are able to be mapped to native IP's Type of Service?
>
> Sigh. You're mixing layers again.
>
> > that IP's TOS=7 (bits 3,4,5 in header) is equivalent to the bit-for-bit,
> > every byte the same, in and out end-to-end, copy guarantee that I seek
> > for a NEW voice bearercap?
>
> No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
> provides no timing or delivery guarantees.
>
Vernon Schryver
Robert Blackshaw <blac...@erols.com> wrote:
> ...
>> No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
>> provides no timing or delivery guarantees.
>>
>In fact if you can find anyone who implements TOS, I'll fall over.
On the contrary, it has been common for several years for packets from
various UNIX (e.g. `rlogin`) and some PC applications (e.g. from FTP
Software) to set the IP TOS bits. It has for many years been common for
PPP and SLIP implementations to do things based on IP TOS bits. Some
major router vendors (especially very big ones with names starting with
'C') have been talking for years about doing something different to IP
packets with various TOS bits. True, I've never found a place to test my
code (either SLIP, PPP, or application) with commercial routers that
actually had the right version of the 'IOS' and had TOS queuing turned on.
I think the trouble with IP TOS queing is manifold:
- support of IP TOS bits has been slow in coming.
- there is nothing that can make an over-subscribed link or network
other than busy. Most people have no idea what IP TOS bits are,
and think they are magic for "make the link idle." IP TOS queuing
is good for interactive traffic sharing WAN links saturated by batch
(e.g. FTP) traffic. IP TOS bits are particularly useful in situations
like moving MBytes with FTP or NFS over an ISDN link while
simultanously trying to get remote interactive work done--I've done
such stuff for many years.
- most of the remainder think IP TOS, RED, fair queuing, RSVP, ATM CBR,
ATM ABR, ATM VBR, telephone-over-SuperInfoHypeWay, and plain ol' 56
kbps audio are all one and the same thing.
- IP TOS bits won't help HTTP, except perhaps to get it out of the way
of applications such as `rlogin`.
Vernon Schryver v...@rhyolite.com
P.S. I'm assuming that Mr. Blackshaw meant the old fashioned, reasonable
meaning of the word "implements", instead of the modern, self-important,
delusional nonsense that makes it a synonym for "took it out of the box
and even remembered to plug it in."
--
Vernon Schryver v...@rhyolite.com
Rhodes
Robert Blackshaw wrote in message <362289...@erols.com>...
>Amanda Walker wrote:
...
>>
>> No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
>> provides no timing or delivery guarantees.
>>
>In fact if you can find anyone who implements TOS, I'll fall over.
>
>Bob
>--
>"Since when was genius found respectable?"
> E. B. Browning
I wouldn't give up on TOS just yet. Thanks, Jeffrey
Hank Karl
<jeffrey...@attws.com> wrote:
> Robert Blackshaw wrote:
> >
> > Jeffrey Rhodes wrote:
> > >
> Someday multiple packet data call types will provide more "tunnels" that
> can be "bumped" by voice calls.
Perhaps this "future" service will use 53 byte "cells"?
> A fax delivered within E-mail to a
> ground mail server could then do better than 2400/4800 on a good day,
> and won't require the back-to-back faxing for lossless digital
> compression ;-)
Maybe we will call the sending of lower priority data when
transmission resources are available "Available Bit Rate"?
David desJardins
> I think the trouble with IP TOS queing is manifold:
You left out of your list: "There's no disincentive for all of the users
of a congested link to just set all of their packets to the highest
priority."
David desJardins
Aaron Leonard
On 12 Oct 1998 22:26:55 -0600, v...@calcite.rhyolite.com (Vernon Schryver) wrote:
~ >> No. IP's TOS is not a guarantee of anything. IP, even with ToS tagging,
~ >> provides no timing or delivery guarantees.
~ >>
~ >In fact if you can find anyone who implements TOS, I'll fall over.
~
~ On the contrary, it has been common for several years for packets from
~ various UNIX (e.g. `rlogin`) and some PC applications (e.g. from FTP
~ Software) to set the IP TOS bits. It has for many years been common for
~ PPP and SLIP implementations to do things based on IP TOS bits. Some
~ major router vendors (especially very big ones with names starting with
~ 'C') have been talking for years about doing something different to IP
~ packets with various TOS bits. True, I've never found a place to test my
~ code (either SLIP, PPP, or application) with commercial routers that
~ actually had the right version of the 'IOS' and had TOS queuing turned on.
IOS can do all kinds of stuff with the TOS bits, if you'd like.
That is, an extended IP access list (since when? relatively recently
I suppose) can match packets on the basis of TOS (as well as IP
address, port number, etc.) and then route 'em or priority-queue 'em
or custom-queue 'em or traffic-shape 'em or what have you accordingly.
~ I think the trouble with IP TOS queing is manifold:
~
~ - support of IP TOS bits has been slow in coming.
~
~ - there is nothing that can make an over-subscribed link or network
~ other than busy. Most people have no idea what IP TOS bits are,
~ and think they are magic for "make the link idle." IP TOS queuing
~ is good for interactive traffic sharing WAN links saturated by batch
~ (e.g. FTP) traffic. IP TOS bits are particularly useful in situations
~ like moving MBytes with FTP or NFS over an ISDN link while
~ simultanously trying to get remote interactive work done--I've done
~ such stuff for many years.
Yes, if TOS is useful for anything, this is it. However, this does count
on the end applications setting the TOS correctly. Weighted fair queueing
accomplishes the same results in that scenario, without requiring any special
mods to the applications or any a priori traffic prioritization on the
router side.
To the above objections to TOS I would add the following (and in my view
decisive) one:
- TOS is set by the end application which will often have a poor or biased
understanding of the performance characteristics and competing traffic
flavors in the network, and is therefore a relatively untrustworthy indicator.
Of course, Vernon has control of the end application and I have control
of the network, so our views on this last point may diverge ...
Aaron
Hank Karl
Looking through the specs (Q.931), I remembered the BC = Unrestricted
digital information with tones/announcements (the old 7 kHz audio BC).
I think that Bob Blackshaw or someone had mentioned this earlier. I
believe that this BC means that unrestricted (64 kHz) data may be sent
through the system, the system won't change the data, and that the
data is audio-type data.
I also saw that in Q.931, section 5.11.1 there was a discussion that a
setup could have several BC's, and the last one in the message had the
highest priority. So you could say "give me unrestricted data w/
Tones and Announcements, if you can't do that, try 3.1 kHz, and if
that fails, give me speech".
>
On Mon, 12 Oct 1998 11:37:49 -0700, Jeffrey Rhodes
<jeffrey...@attws.com> wrote:
> Hank Karl wrote:
> >
> > On Fri, 09 Oct 1998 14:51:54 -0700, Jeffrey Rhodes
> > <jeffrey...@attws.com> wrote:
> >
>
> > > Now why would it matter how many IXCs are involved?
>
> > One hopes that each IXC will only apply one instance of signal
> > processing, etc. (see your note on echo cancelers below). If more
> > than one IXC handle a call, each IXC may process the signal.
>
> Now that local service is becoming long distance service, now that local
> portability means calls may "deflect" from a "default" switch, it is not
> apparent that one carrier's enhancement needs to be able to prevent
> other carrier's enhancement as the carrier's call establishes a "talk
> path"?
This is a bigger issue in that it will affect POTS users as well as
ISDN users. One solution may be to promote speech calls to 3.1k or
"unrestricted digital information with tones/announcements" after the
first set of enhancements is done.
Note: I believe that
- BC = speech -- data is octet aligned, but may be modified by echo
canceling or other digital enhancements.
- BC = 3.1 kHz audio -- data is octet aligned, but should not have any
enhancements.
- BC = Unrestricted digital information with tones/announcements (the
old 7 kHz audio BC) means that unrestricted (64 kHz) data may be sent
through the system, and that the data is audio-type data.
>
> >jcr> Oh yes, Thor, the SS7 echo canceller bits are able to keep off TV(tm) in
> >jcr> some AT&T circuit switches, but one of the AT&T circuit switches in the
> >jcr> call's routepath will have the TV(tm) enabled, perhaps regardless of the
> >jcr> SS7 bit setting, but certainly regardless of the voice bearercap
> >jcr> setting.
>
> >jcr -- > As you all probably know, a single echo canceler in each
> >jcr -- > direction is more effective than piling on the echo cancelers.
>
> Of course, the bearercap request in an SS7 IAM or Q.931 SETUP message
> has nothing to do with echo cancellers, right?
So a speech BC gets the same treatment as a data BC? And all AT&T
does is bill more for the data BC? I'd hope that if I'm paying more
for a data call AT&T will turn off the echo cancelers, etc (Wait a
minute--are they giving me less for more money? :-)
>
> And I still want an answer to:
> > > Hank, you do understand that I have provided this air-to-ground fax
> > > example merely to indicate how a voice bearercap for audio can be
> > > digitally compressed losslessly, without regard for "bit-for-bit byte
> > > integrity" of 64000 bit/s, right? The NEW voice bearercap is not needed
> > > for this type of call. BTW, ground-to-air fax is also possible, and
> > > this, too, does not depend on voice bearercap, either.
You are not compressing the 64k signal losslessly. You are extracting
the relevant information (by DEmodulating it) and re-creating the 64k
signal later. It's very clear in the case of a fax originated from
the ground. The ground-side fax connects via a copper wire, which
adds something to the signal (loss, inductance, noise, etc). The
ground station recreates the fax data and sends it to the airplane.
The device on the plane will re-modulate the fax signal, but does not
have any knowledge of the noise, etc that the ground station ignored.
So this is a lossy compression. While no "important" information was
lost, some information was deliberately thrown away (the noise). This
is similar to a lossy voice compression algorithm, which _attempts_ to
keep the important part of the signal and throws away all else. (the
"important part of the signal" is a subjective measure and I'm sure
there have been some wars fought over what was best, or even
acceptable.)
> > >
> > > The NEW voice bearercap has always been needed for digital cellphone to
> > > digital cellphone calls when the call's routepath is via the ISDN/PSTN
> > > circuit switch networks that do not provide "bit-for-bit byte
> > > integrity". (OK, that's a stretch, but each *enhancement* adds a little,
> > > to the overall end-to-end delay characteristic ;-) Now that the packet
> > > switched Internet network is able to provide IP telephony, the NEW voice
> > > bearercap is needed for cross-over voice calls that seek end-to-end ISDN
> > > "bit-for-bit byte integrity", even across the SS7/IP gateway boundary.
> > > The NEW voice bearercap would be useful for private voice encryption,
> > > direct TDMA to TDMA packet delivery bypass of long distance switch
> > > circuits, etc. and is not limited to cross-over voice calls.
> > >
>
> And you do realize, that I realize, this is NOT a showstopper. It is
> simply a suggested improvement that the ISDN standards have no means YET
> to provide, since I believe I have convinced you that a bearercap
> request for 3.1KHz Audio does NOT provide "bit-for-bit, every byte the
> same" transport at intermediate "talk path" switches. This NEW voice
> bearercap could be used to request a "talk path" that could support
> end-to-end private voice encryption, too, though I believe thes most
> useful use is for "mid-talk path *enhancement* requires mid-to-end bit
> integrity".
>
I think the Unrestricted digital information with tones/announcements
(the old 7 kHz audio BC) will do what you are talking about.
Jeffrey Rhodes
Aaron,
What do you mean "Vernon has control of the end application"? What
application? All of them?
From Ascend's homepage:
"Most venders can only offer either relative or best effort QoS.
Ascend's IP Navigator gives providers the capability of delivering
multiservice QoS, including the industry's only "Absolute QoS" feature.
With Absolute QoS, reserved bandwidth guarantees a path and quality for
a call, yet can be utilized by other traffic while no traffic from that
call is available. Absolute QoS provides this capability by linking IP
Navigator on Ascend switches to the MAX and MAX TNT access equipment
through use of the Type of Service (ToS) field in IP to indicate to the
switch the required class of service for a call. IP Navigator then uses
this information to set up the required service levels across the
network." (end-quote)
Are you saying that both Cisco and Ascend are giving up on TOS-based
routing, or are you saying that it is hopeless to enforce? Does Cisco
have anything like "Absolute Q0S" and, if so, are the Q.931 bearercaps
for speech, audio and data all separate values mappable for a crossover
call from IP to SS7, and for SS7 to IP?
Thanks, Jeffrey
Jeffrey Rhodes
> > > Jeffrey Rhodes wrote:
> > > >
>
> > Someday multiple packet data call types will provide more "tunnels" that
> > can be "bumped" by voice calls.
> Perhaps this "future" service will use 53 byte "cells"?
It might? Right now 128 byte "packets" are in vogue, based on some
trade-off study for over-the-air error correction.
>
> > A fax delivered within E-mail to a
> > ground mail server could then do better than 2400/4800 on a good day,
> > and won't require the back-to-back faxing for lossless digital
> > compression ;-)
> Maybe we will call the sending of lower priority data when
> transmission resources are available "Available Bit Rate"?
Does that translate to TOS value=0 for bits 3,4,5 of the "Type of
Service" field in the IPv4 header?
Regards, Jeffrey
Jeffrey Rhodes
>
> Jeffrey,
>
> Looking through the specs (Q.931), I remembered the BC = Unrestricted
> digital information with tones/announcements (the old 7 kHz audio BC).
> I think that Bob Blackshaw or someone had mentioned this earlier. I
> believe that this BC means that unrestricted (64 kHz) data may be sent
> through the system, the system won't change the data, and that the
> data is audio-type data.
I don't think so. The only commercial application that uses 7 kHz audio
bearercap that I am familiar with is extending a stereo FM broadcast
signal to remoted broadcast antennaes. Maybe commercial TV uses this for
audio feed, while the video takes a satellite feed, since I notice that
I "hear" golf shots on TV before the golf ball "appears" to be struck.
Anyway, I want the NEW voice bearercap that requests mid-to-end bit
integrity to be able to be used for cellular TDMA callers. Somehow, a
request for 7 kHz audio, does not really fit with me. I wonder, too, if
SS7 routing translations are able to pass this bearercap universally
within ISDN?
> I also saw that in Q.931, section 5.11.1 there was a discussion that a
> setup could have several BC's, and the last one in the message had the
> highest priority. So you could say "give me unrestricted data w/
> Tones and Announcements, if you can't do that, try 3.1 kHz, and if
> that fails, give me speech".
Well, thanks for the reference, but it says "It will not apply to
situations involving interworking with non-ISDNs". Also, a limit of two
bearercap IEs only are permitted in the user's SETUP. For want of
anything better, I suppose this is applicable, provided one considers
the cross-over SS7/IP "hybrid" call to remain "within an ISDN" ???
> I think the Unrestricted digital information with tones/announcements
> (the old 7 kHz audio BC) will do what you are talking about.
I wonder how well the 7 kHz audio BC is provisioned in existing ISDN/SS7
switch's routing data translations? The fallback would be 3.1 kHz audio
but the calling user's ISDN equipment will know that a routing selection
fallback has occurred "within the ISDN" by receiving a PROGRESS message.
I also wonder how well SS7 networks handle this "bearer capability
selection is allowed" for duplicate BC IEs in an IAM ???
> -----------------------------------
> Hank Karl
> Opinions mine, not my company's
> to reply, remove the "imnothere" from my address
Thanks, I can use this, but I still think the industry would do better
with a NEW voice bearercap that provides "mid-to-end bit integrity". It
seems that the only way that the Q.931 standard is able to achieve bit
integrity anywhere in the ISDN is when the resultant call is end-to-end
ISDN. When the "call is not end-to-end ISDN, further call progress
information may be available in-band" or "destination address is
non-ISDN", "the user shall assume a bearer service category of
circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio
information transfer". Somehow, IP telephony does not seem to fit this
description, so it still seems to me that a NEW voice bearercap is
needed for crossover calls SS7 to IP and IP to SS7. Not imperative, but
I predict that a slight improvement can be noted. As opposed to noting
ANY difference between speech and audio.
Thanks, again, Jeffrey
Aaron Leonard
~ > To the above objections to TOS I would add the following (and in my view
~ > decisive) one:
~ >
~ > - TOS is set by the end application which will often have a poor or biased
~ > understanding of the performance characteristics and competing traffic
~ > flavors in the network, and is therefore a relatively untrustworthy indicator.
~ >
~ > Of course, Vernon has control of the end application and I have control
~ > of the network, so our views on this last point may diverge ...
~ What do you mean "Vernon has control of the end application"? What
~ application? All of them?
Sorry, I was being a little flippant. My point if I had one was
that Mr. Schryver writes the code that sets the TOS flag in TCP
(i.e. controls the TCP sockets) while we (qua router purveyor) take
the TCP header fields as (pretty much of) a given and control
what connects the sockets.
~ From Ascend's homepage:
~
~ "Most venders can only offer either relative or best effort QoS.
~ Ascend's IP Navigator gives providers the capability of delivering
~ multiservice QoS, including the industry's only "Absolute QoS" feature.
~ With Absolute QoS, reserved bandwidth guarantees a path and quality for
~ a call, yet can be utilized by other traffic while no traffic from that
~ call is available. Absolute QoS provides this capability by linking IP
~ Navigator on Ascend switches to the MAX and MAX TNT access equipment
~ through use of the Type of Service (ToS) field in IP to indicate to the
~ switch the required class of service for a call. IP Navigator then uses
~ this information to set up the required service levels across the
~ network." (end-quote)
~
~ Are you saying that both Cisco and Ascend are giving up on TOS-based
~ routing, or are you saying that it is hopeless to enforce?
Whoa - I am not speaking for Cisco (let alone Ascend!) But let me repeat
what I said ...
~ IOS can do all kinds of stuff with the TOS bits, if you'd like.
~ That is, an extended IP access list (since when? relatively recently
~ I suppose) can match packets on the basis of TOS (as well as IP
~ address, port number, etc.) and then route 'em or priority-queue 'em
~ or custom-queue 'em or traffic-shape 'em or what have you accordingly.
So, yes, we can definitely can route or queue based on TOS.
~ Does Cisco
~ have anything like "Absolute Q0S"
I'm not a fancy queueing / QoS side guy, plus which this is the
first I've heard of "Absolute QOS", but we do have all kinds of
routing and queueing stuff we can do ...
~ and, if so, are the Q.931 bearercaps
~ for speech, audio and data all separate values mappable for a crossover
~ call from IP to SS7, and for SS7 to IP?
It's hard for me to keep track of what all is available and/or
in the works in this area. It sure makes sense to me that
there be in general customizable mappings between Q.931 fields
(ANI and DNIS as well as the bearercap stuff) vs. IP side stuff
(IP and TCP header stuff and QoS), but I don't have a clear
mental picture of exactly how all that would fall out.
~ Thanks, Jeffrey
Regards,
Aaron
Vernon Schryver
From: David desJardins <de...@math.berkeley.edu>
] > I think the trouble with IP TOS queing is manifold:
]
] You left out of your list: "There's no disincentive for all of the users
] of a congested link to just set all of their packets to the highest
] priority."
Not so! The problem of fairness has nothing to do with whether the network
honors IP TOS bits. It is easy to abuse any scheme that gives some traffic
better service based on actions of the endpoints. This applies just as
much to IP TOS as to RSVP or even Frame Relay. One of the jobs of the
network is to ensure that abusers pay for their abuse in money, effective
quality of service, termination of service, nasty phone calls from NOC
and/or any other way, and so don't do it unnecessarily. It makes exactly
as much sense to worry about people cheating and setting low-delay IP TOS
bits on their FTP packets as to worry about people cheating and not doing
slow-start on their TCP links. Both are theoretically valid worries, but
to date, many more have abused the Internet by failing to reduce congestion
windows.
In article <3623c906....@news.cisco.com>,
Aaron Leonard <Aa...@Cisco.COM> wrote:
> ...
>~ What do you mean "Vernon has control of the end application"? What
>~ application? All of them?
>
>Sorry, I was being a little flippant. My point if I had one was
>that Mr. Schryver writes the code that sets the TOS flag in TCP
>(i.e. controls the TCP sockets) while we (qua router purveyor) take
>the TCP header fields as (pretty much of) a given and control
>what connects the sockets.
I got the point, and mostly agree, with the provisio that I've had
and have my fingers in various boxes that do various non-host things.
> ...
>~ and, if so, are the Q.931 bearercaps
>~ for speech, audio and data all separate values mappable for a crossover
>~ call from IP to SS7, and for SS7 to IP?
>
>It's hard for me to keep track of what all is available and/or
>in the works in this area. It sure makes sense to me that
>there be in general customizable mappings between Q.931 fields
>(ANI and DNIS as well as the bearercap stuff) vs. IP side stuff
>(IP and TCP header stuff and QoS), but I don't have a clear
>mental picture of exactly how all that would fall out.
I think you're being too kind. It seems to me that talk of Q.931 tags
being changed as the result of IP TOS bits or vice versa is a bogus mixing
of layers and concepts. That a packet with some set of IP TOS bits arrives
on the IP side of a box which connects phone circuits to an IP network
implies nothing about whether the bits from the packet should go out the
phone side labeled speech or data. In the opposite direction, there also
is no single, valid mapping. There is simply no notion of speech versus
data in the IP TOS bits. For example, low latency IP TOS bits might be
used on voice/IP packets, but they have been used for years for the pure
data IP packets of some network time protocols that have more need of
special queuing by routers than speech. (A millisecond spent in a queue
here and there does not hurt voice, but is the fundamental problem that
time protocols attack.) I saw nothing in the quoted words from Ascend
contrary to my view.
The main point against IP TOS bits that I skipped in my list is that the
people who buy and operate routers like to twiddle knobs. IP TOS bits
are set by applications on hosts, and so are immediately suspect by those
whose only use of hosts is to talk to routers. Since they can't (or could
not until the really fancy IOS mapping) control the results of the TOS
bits, they weren't interested. I am not being flippant. For many years
rabid router people sneered that only routers can forward packets, and
that routers are routers and hosts are hosts and never the twain shall
meet. That nonsense has become less obvious since practically all routers
became hosts (e.g. by answering `telnet`), but it remains. Every time
you encounter someone who soils their undergarments when they find `routed`
running without "-s", you've met a router/host bigot and segregationist.
That silly caste-thinking is the main reason I was never able to run tests
to see how IP TOS bits on interactive packets would have helped the
world-wide corporate network of my erstwhile UNIX vendor employer.
Vernon Schryver v...@rhyolite.com
David desJardins
> Not so! The problem of fairness has nothing to do with whether the network
> honors IP TOS bits. It is easy to abuse any scheme that gives some traffic
> better service based on actions of the endpoints.
No, if you charge the user based on the quality of service that they
request, then it's not easy, or even possible, for them to "abuse" the
system; they get exactly what they pay for. If they get better service
by paying more, that's not abuse; it's capitalism.
> One of the jobs of the network is to ensure that abusers pay for their
> abuse in money, effective quality of service, termination of service,
> nasty phone calls from NOC and/or any other way, and so don't do it
> unnecessarily.
This seems to contradict the previous statement that any scheme is easy
to abuse. Now you are saying (more correctly in my view) that network
providers can act to stop such abuse.
However, such deterrence has not been particularly successful, and the
problem is growing:
> It makes exactly as much sense to worry about people cheating and
> setting low-delay IP TOS bits on their FTP packets as to worry about
> people cheating and not doing slow-start on their TCP links. Both are
> theoretically valid worries, but to date, many more have abused the
> Internet by failing to reduce congestion windows.
Exactly! All three of these are the same sort of problem. Of course,
there are currently more noncooperative users using "improper"
congestion control than "improper" TOS, simply because TOS is mostly
ignored, so there's little incentive to fake it. But deploy TOS widely,
and that could change fast.
The problem with TCP congestion control is precisely that it relies on
users to be honest and cooperative; we are therefore stuck with a major
effort in trying to police that, something that no one has really
figured out how to do. I think that a lot of people are reluctant to
make big efforts to deploy other services (such as IP TOS) that have the
same problem.
David desJardins
Hank Karl
<jeffrey...@attws.com> wrote:
> Hank Karl wrote:
> >
> > Jeffrey,
> >
> > Looking through the specs (Q.931), I remembered the BC = Unrestricted
> > digital information with tones/announcements (the old 7 kHz audio BC).
> > I think that Bob Blackshaw or someone had mentioned this earlier. I
> > believe that this BC means that unrestricted (64 kHz) data may be sent
> > through the system, the system won't change the data, and that the
> > data is audio-type data.
>
> I don't think so. The only commercial application that uses 7 kHz audio
> bearercap that I am familiar with is extending a stereo FM broadcast
> signal to remoted broadcast antennaes.
That's one more application than the bearercap you are proposing. And
this bearercap is not restricted to 7 kHz anymore. How would it be
different than what you are proposing?
> Maybe commercial TV uses this for
> audio feed, while the video takes a satellite feed, since I notice that
> I "hear" golf shots on TV before the golf ball "appears" to be struck.
> Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> integrity to be able to be used for cellular TDMA callers. Somehow, a
> request for 7 kHz audio, does not really fit with me.
The meaning of the BC has been changed from 7 kHz in the 1992 version
of Q.931.
> I wonder, too, if
> SS7 routing translations are able to pass this bearercap universally
> within ISDN?
As with all things ISDN, that probably depends on whose equipment you
are using. :-(
>
> > I also saw that in Q.931, section 5.11.1 there was a discussion that a
> > setup could have several BC's, and the last one in the message had the
> > highest priority. So you could say "give me unrestricted data w/
> > Tones and Announcements, if you can't do that, try 3.1 kHz, and if
> > that fails, give me speech".
>
> Well, thanks for the reference, but it says "It will not apply to
> situations involving interworking with non-ISDNs". Also, a limit of two
> bearercap IEs only are permitted in the user's SETUP. For want of
> anything better, I suppose this is applicable, provided one considers
> the cross-over SS7/IP "hybrid" call to remain "within an ISDN" ???
In the situation you are talking about, ISDN is a concept; there are a
bunch of spec's that implement devices that perform ISDN, and often
ISDN is used to refer to Q.931 BRI and PRI devices. But ISDN (in its
broad sense) encompasses BRIs, PRIs, ATM (well, broadband ISDN) and I
think we can make the point that IP can become an ISDN if VoIP is
implemented.
Integrated -- IP integrates data and voice calls, and can carry other
protocols in the IP payloads.
Digital -- IP is digital
Services -- H.323 has H.225 as a component, H.225 is a Q.931
descendent (variant?). I suspect that the services available on H.323
are similar to the services available on Q.931.
Network -- Q.E.D.
ISDN was intended to be the "last mile" connection to the SS7. H.323
allows a LAN to act as the last mile.
>
> > I think the Unrestricted digital information with tones/announcements
> > (the old 7 kHz audio BC) will do what you are talking about.
>
> I wonder how well the 7 kHz audio BC is provisioned in existing ISDN/SS7
> switch's routing data translations? The fallback would be 3.1 kHz audio
> but the calling user's ISDN equipment will know that a routing selection
> fallback has occurred "within the ISDN" by receiving a PROGRESS message.
> I also wonder how well SS7 networks handle this "bearer capability
> selection is allowed" for duplicate BC IEs in an IAM ???
>
> > -----------------------------------
> > Hank Karl
> > Opinions mine, not my company's
> > to reply, remove the "imnothere" from my address
>
> Thanks, I can use this, but I still think the industry would do better
> with a NEW voice bearercap that provides "mid-to-end bit integrity". It
> seems that the only way that the Q.931 standard is able to achieve bit
> integrity anywhere in the ISDN is when the resultant call is end-to-end
> ISDN.
SS7 in the middle should be the same as end-to-end ISDN.
> When the "call is not end-to-end ISDN, further call progress
> information may be available in-band" or "destination address is
> non-ISDN", "the user shall assume a bearer service category of
> circuit-mode 64 kbit/s 8 kHz structured usable for 3.1 kHz audio
> information transfer". Somehow, IP telephony does not seem to fit this
> description,
Why is IP telephony different?
If you compress the data, you must de-compress it somewhere if a user
is going to listen to it. If that point is an interworking unit
between VoIP and a PRI, you can change the bearercap there if you call
from the IP device to the PRI. If you go from the PRI to the IP
device, you do have a problem. There is no way to indicate which
compression you want. But you can use the "Unrestricted digital
information with tones/announcements" to tell the interworking unit to
not modify the data, and speech to tell the interworking unit that the
data is compressible with a voice compression algorithm, and 3.1 kHz
audio to hint that it may be fax or modem data (or you can use the
dialed number to determine this).
> so it still seems to me that a NEW voice bearercap is
> needed for crossover calls SS7 to IP and IP to SS7. Not imperative, but
> I predict that a slight improvement can be noted. As opposed to noting
> ANY difference between speech and audio.
>
> Thanks, again, Jeffrey
-----------------------------------
Jeffrey Rhodes
I always find your postings to be very readable, but they are laced with
sarcasm, so sometimes I am bewildered. Would you please help me
understand how IP telephony is going to provide a "guaranteed quality of
service"? Will the Internet's routers need to sustain a virtual private
network, where the VPN is able to enforce adherence to TOS routing
principles, for this application?
More questions below.
Vernon Schryver wrote:
>
> From: David desJardins <de...@math.berkeley.edu>
>
Actually, it was me who wrote the following question:
> > ...
> >~ and, if so, are the Q.931 bearercaps
> >~ for speech, audio and data all separate values mappable for a crossover
> >~ call from IP to SS7, and for SS7 to IP?
And I think this is Aaron's response:
> >
> >It's hard for me to keep track of what all is available and/or
> >in the works in this area. It sure makes sense to me that
> >there be in general customizable mappings between Q.931 fields
> >(ANI and DNIS as well as the bearercap stuff) vs. IP side stuff
> >(IP and TCP header stuff and QoS), but I don't have a clear
> >mental picture of exactly how all that would fall out.
And this is your response to Aaron:
> I think you're being too kind. It seems to me that talk of Q.931 tags
> being changed as the result of IP TOS bits or vice versa is a bogus mixing
> of layers and concepts. That a packet with some set of IP TOS bits arrives
> on the IP side of a box which connects phone circuits to an IP network
> implies nothing about whether the bits from the packet should go out the
> phone side labeled speech or data.
Well, an IP caller may want to call an ISDN user, and may want to
perform 64 kbit/s data for PPP when the call is answered, or, the IP
caller may want to call an ISDN user to talk to them. Seems that IPv4's
ToS, or IPv6's QoS, will need to map separate IP tags into separate ISDN
tags, for this to be possible?
As far as "bogus mixing of layers and concepts", that hasn't stopped SS7
from progressing. ;-) A good example is IS-41's SS7 Subsystem numbers
that must be provisioned correctly for messages to be sent to the data
layer, and then the same Subsystem numbers are replicated in the
application layer for the end-points. And the end-points really don't
need them, but that's the way it is "implemented by standards".
> In the opposite direction, there also
> is no single, valid mapping. There is simply no notion of speech versus
> data in the IP TOS bits. For example, low latency IP TOS bits might be
> used on voice/IP packets, but they have been used for years for the pure
> data IP packets of some network time protocols that have more need of
> special queuing by routers than speech. (A millisecond spent in a queue
> here and there does not hurt voice, but is the fundamental problem that
> time protocols attack.) I saw nothing in the quoted words from Ascend
> contrary to my view.
We seem to see the importance of voice/IP packet delivery differently.
Low latency is desirable, but a vocoder can provide "background noise"
when a packet is late in arriving. As you know, a 64 kbit/s ISDN data
call cannot tolerate latencies that exceed a given amount. But an H.323
call setup for an IP telephony data caller is currently able to request
a Q.931/H.323 bearercap for *packet mode* at 64 kbit/s, and this can be
mapped to an ISDN's Q.931 data bearercap for *circuit mode* at 64
kbit/s, by the SS7/IP gateway device (or at least I think the ISDN
standards allow vendors to create such). Let's say a crossover IP voice
caller is unhappy with a resultant voice connection's latency (even with
background noise generation)that is completed on both the
*packet-driven* Internet and the *circuit-driven* ISDN. A NEW voice
bearercap would allow this IP voice caller to specify a QoS of 64 kbit/s
(with no latency, right?) and the SS7/IP gateway could convert this
request to a voice bearercap for the circuit mode portion of the call.
Vice-versa, a digital cellular caller to a crossover IP voice
destination, may not be happy with the resultant delays and latencies,
and would be able to make use of the NEW voice bearercap, to indicate to
the SS7/IP gateway (or any intermeditate point) that the packet portion
(or the remaining circuit mode portion, mid-to-end) of the call PREFERS
NOT to utilize yet another vocoder, or other voice enhancement.
> The main point against IP TOS bits that I skipped in my list is that the
> people who buy and operate routers like to twiddle knobs. IP TOS bits
> are set by applications on hosts, and so are immediately suspect by those
> whose only use of hosts is to talk to routers. Since they can't (or could
> not until the really fancy IOS mapping) control the results of the TOS
> bits, they weren't interested. I am not being flippant. For many years
> rabid router people sneered that only routers can forward packets, and
> that routers are routers and hosts are hosts and never the twain shall
> meet. That nonsense has become less obvious since practically all routers
> became hosts (e.g. by answering `telnet`), but it remains. Every time
> you encounter someone who soils their undergarments when they find `routed`
> running without "-s", you've met a router/host bigot and segregationist.
> That silly caste-thinking is the main reason I was never able to run tests
> to see how IP TOS bits on interactive packets would have helped the
> world-wide corporate network of my erstwhile UNIX vendor employer.
>
>
> Vernon Schryver v...@rhyolite.com
I wonder if you know my boss, Gregg Siegfried? He has deep roots into
Unix and IP.
Thanks for the information.
Jeffrey Rhodes at jeffrey...@attws.com
Jeffrey Rhodes
>
> On Tue, 13 Oct 1998 16:34:20 -0700, Jeffrey Rhodes
> <jeffrey...@attws.com> wrote:
>
> > Hank Karl wrote:
> > Maybe commercial TV uses this for
> > audio feed, while the video takes a satellite feed, since I notice that
> > I "hear" golf shots on TV before the golf ball "appears" to be struck.
> > Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> > integrity to be able to be used for cellular TDMA callers. Somehow, a
> > request for 7 kHz audio, does not really fit with me.
> The meaning of the BC has been changed from 7 kHz in the 1992 version
> of Q.931.
OK, OK. I'm shelving my bound copy of the Blue Book and will print out a
copy of the 03/93 ITU Q.931 standard from AT&T's intranet. Was this the
White Book? Is there a Green Book for 1996? I guess I shouldn't be
surprised when something consented to by ITU in 1993, is actually
showing up in the US ISDN in 1998 ;-)
> > I wonder, too, if
> > SS7 routing translations are able to pass this bearercap universally
> > within ISDN?
> As with all things ISDN, that probably depends on whose equipment you
> are using. :-(
I wonder, too, how well so many US SS7 vendors are prepared for "bearer
capability
selection is allowed" for duplicate BC IEs in an IAM ???
> > Well, thanks for the reference, but it says "It will not apply to
> > situations involving interworking with non-ISDNs". Also, a limit of two
> > bearercap IEs only are permitted in the user's SETUP. For want of
> > anything better, I suppose this is applicable, provided one considers
> > the cross-over SS7/IP "hybrid" call to remain "within an ISDN" ???
> In the situation you are talking about, ISDN is a concept; there are a
> bunch of spec's that implement devices that perform ISDN, and often
> ISDN is used to refer to Q.931 BRI and PRI devices. But ISDN (in its
> broad sense) encompasses BRIs, PRIs, ATM (well, broadband ISDN) and I
> think we can make the point that IP can become an ISDN if VoIP is
> implemented.
>
> Integrated -- IP integrates data and voice calls, and can carry other
> protocols in the IP payloads.
>
> Digital -- IP is digital
>
> Services -- H.323 has H.225 as a component, H.225 is a Q.931
> descendent (variant?). I suspect that the services available on H.323
> are similar to the services available on Q.931.
>
> Network -- Q.E.D.
>
> ISDN was intended to be the "last mile" connection to the SS7. H.323
> allows a LAN to act as the last mile.
OK, it's all ISDN. I am trying to extend the circuit-intensive ISDN
world into the packet-intensive Internet here. Let's back up just a
little. An IP telephony caller needs to be able to specify whether or
not a call is *data* or is *voice*, right? An H.323 data caller can use
the same data bearercap, specifying *packet mode* on the Internet side
and *circuit mode* on the existing ISDN-side. No trouble mapping this
request (how IP guarantees continuous 64 kbit/s is yet to be determined
;-)
But an H.323 voice caller will be subjected to a G-whatever vocoder's
packetizing for delivery on the IP portion of a crossover call. An
SS7/IP gateway will unpacketize the G-whatever vocoder's packets and
deliver 64 kbit/s PCM to the SS7 circuit. Now if the SS7/IP gateway uses
an audio or speech bearercap, the call's talkpath of circuits may
encounter some more vocoders or *enhancements*. The result will probably
be intelligible for humans to communicate, but is it possible that the
resulting conversation MIGHT be of better subjective quality when the
voice call is completed WITHOUT G-whatever vocoders, i.e. the IP portion
is required to deliver a steady stream of 64 kbit/s PCM samples instead.
It seems to me that IP telephony needs to support an option to bypass
G-whatever vocoders for voice calls, no doubt at a premium per-call
cost, in the event that the Internet slows down ;-)
> > > I think the Unrestricted digital information with tones/announcements
> > > (the old 7 kHz audio BC) will do what you are talking about.
> > Thanks, I can use this, but I still think the industry would do better
> > with a NEW voice bearercap that provides "mid-to-end bit integrity". It
> > seems that the only way that the Q.931 standard is able to achieve bit
> > integrity anywhere in the ISDN is when the resultant call is end-to-end
> > ISDN.
> Why is IP telephony different?
> If you compress the data, you must de-compress it somewhere if a user
> is going to listen to it. If that point is an interworking unit
> between VoIP and a PRI, you can change the bearercap there if you call
> from the IP device to the PRI. If you go from the PRI to the IP
> device, you do have a problem. There is no way to indicate which
> compression you want. But you can use the "Unrestricted digital
> information with tones/announcements" to tell the interworking unit to
> not modify the data, and speech to tell the interworking unit that the
> data is compressible with a voice compression algorithm, and 3.1 kHz
> audio to hint that it may be fax or modem data (or you can use the
> dialed number to determine this).
Every number in the ISDN should be able to support voice and data. A
user does not want to change numbers in order to add a capability to
their existing service. I don't like to use DNIS to sort out
applications.
> > so it still seems to me that a NEW voice bearercap is
> > needed for crossover calls SS7 to IP and IP to SS7. Not imperative, but
> > I predict that a slight improvement can be noted. As opposed to noting
> > ANY difference between speech and audio.
> >
> > Thanks, again, Jeffrey
>
> -----------------------------------
> Hank Karl
> Opinions mine, not my company's
> to reply, remove the "imnothere" from my address
I would want the 7 kHz audio bearercap from ISDN to map to an IP's
guaranteed QoS of 64 kbit/s delivery of the PCM samples delivered from
the SS7 side, and speech or 3.1 kHz audio to map to the compressed
G-whatever vocoder's IP capability. As an IP telephony caller, I would
want the option of requesting a 7 kHz audio bearercap, to be mapped to
IP's guaranteed QoS of 64 kbit/s delivery of the PCM samples that are
collected by my computer, in the event that the G-whatever samples that
are collected by my computer (that are decoded at the SS7/IP gateway)
were somehow, temporarily perhaps, of lesser subjective use. Somehow I
don't think things are headed this way, though.
Regards, Jeffrey
Robert Blackshaw
>
> Hank Karl wrote:
> >
> > Jeffrey,
> >
> > digital information with tones/announcements (the old 7 kHz audio BC).
> > I think that Bob Blackshaw or someone had mentioned this earlier. I
> > believe that this BC means that unrestricted (64 kHz) data may be sent
> > through the system, the system won't change the data, and that the
> > data is audio-type data.
>
> bearercap that I am familiar with is extending a stereo FM broadcast
> audio feed, while the video takes a satellite feed, since I notice that
> I "hear" golf shots on TV before the golf ball "appears" to be struck.
> Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> integrity to be able to be used for cellular TDMA callers. Somehow, a
> SS7 routing translations are able to pass this bearercap universally
> within ISDN?
>
for AM broadcast stations back in Bell Canada. 7kHz FM? <barf>
Robert Blackshaw
>
> Hank Karl wrote:
> >
> > On Tue, 13 Oct 1998 16:34:20 -0700, Jeffrey Rhodes
> > <jeffrey...@attws.com> wrote:
> >
> > > Hank Karl wrote:
> Actually, it was me who wrote the next paragraph:
> > > Maybe commercial TV uses this for
> > > audio feed, while the video takes a satellite feed, since I notice that
> > > I "hear" golf shots on TV before the golf ball "appears" to be struck.
> > > Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> > > integrity to be able to be used for cellular TDMA callers. Somehow, a
> > > request for 7 kHz audio, does not really fit with me.
> > The meaning of the BC has been changed from 7 kHz in the 1992 version
> > of Q.931.
>
> OK, OK. I'm shelving my bound copy of the Blue Book and will print out a
> copy of the 03/93 ITU Q.931 standard from AT&T's intranet. Was this the
> White Book? Is there a Green Book for 1996? I guess I shouldn't be
> surprised when something consented to by ITU in 1993, is actually
> showing up in the US ISDN in 1998 ;-)
>
coloured books pretty much became history. Now when a Study
Group agrees that aa Recommendation is ready it is "Decided"
and is published on the spot (Well, after translation into
French and Spanish). The old 4-year study period idea is
history.
Hank Karl
<jeffrey...@attws.com> wrote:
> Hank Karl wrote:
> >
> > On Tue, 13 Oct 1998 16:34:20 -0700, Jeffrey Rhodes
> > <jeffrey...@attws.com> wrote:
> >
> > > Hank Karl wrote:
> Actually, it was me who wrote the next paragraph:
> > > Maybe commercial TV uses this for
> > > audio feed, while the video takes a satellite feed, since I notice that
> > > I "hear" golf shots on TV before the golf ball "appears" to be struck.
> > > Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> > > integrity to be able to be used for cellular TDMA callers. Somehow, a
> > > request for 7 kHz audio, does not really fit with me.
> > The meaning of the BC has been changed from 7 kHz in the 1992 version
> > of Q.931.
>
> OK, OK. I'm shelving my bound copy of the Blue Book and will print out a
> copy of the 03/93 ITU Q.931 standard from AT&T's intranet. Was this the
> White Book? Is there a Green Book for 1996?
I think that after the 1992 version the spec's were released on an "as
ready" basis, and there are no more "books" every four years.
> I guess I shouldn't be
> surprised when something consented to by ITU in 1993, is actually
> showing up in the US ISDN in 1998 ;-)
It may not be showing up yet. Lucent and Nortel have to put it into
their specs, then their switches, then the LECs have to roll it out...
But in this case the bearer capability may have been more of a
name-change than any switch functionality (ie that bearer capability
just got passed through at 64K).
>
> > > I wonder, too, if
> > > SS7 routing translations are able to pass this bearercap universally
> > > within ISDN?
> > As with all things ISDN, that probably depends on whose equipment you
> > are using. :-(
This is where you separate the ...ah... adults from the children.
That QOS issue is another reason for the BC to be selected on the IP
side. I suspect that the compression algorithm and the delay and the
jitter will be issues affecting the quality of an IP call.
>
> But an H.323 voice caller will be subjected to a G-whatever vocoder's
> packetizing for delivery on the IP portion of a crossover call. An
> SS7/IP gateway will unpacketize the G-whatever vocoder's packets and
> deliver 64 kbit/s PCM to the SS7 circuit. Now if the SS7/IP gateway uses
> an audio or speech bearercap, the call's talkpath of circuits may
> encounter some more vocoders or *enhancements*. The result will probably
> be intelligible for humans to communicate, but is it possible that the
> resulting conversation MIGHT be of better subjective quality when the
> voice call is completed WITHOUT G-whatever vocoders, i.e. the IP portion
> is required to deliver a steady stream of 64 kbit/s PCM samples instead.
> It seems to me that IP telephony needs to support an option to bypass
> G-whatever vocoders for voice calls, no doubt at a premium per-call
> cost, in the event that the Internet slows down ;-)
That's a good place to put it (ie the IP portion). Putting it in the
ISDN is an ugly work-around, and may lead to tarrifing issues like
those that caused DOV.
Also, each different compression may be charged differently. If the
user is charged per-packet, (or per byte) it will happen by default.
>
> > > > I think the Unrestricted digital information with tones/announcements
> > > > (the old 7 kHz audio BC) will do what you are talking about.
>
> > > Thanks, I can use this, but I still think the industry would do better
> > > with a NEW voice bearercap that provides "mid-to-end bit integrity". It
> > > seems that the only way that the Q.931 standard is able to achieve bit
> > > integrity anywhere in the ISDN is when the resultant call is end-to-end
> > > ISDN.
>
> > Why is IP telephony different?
> > If you compress the data, you must de-compress it somewhere if a user
> > is going to listen to it. If that point is an interworking unit
> > between VoIP and a PRI, you can change the bearercap there if you call
> > from the IP device to the PRI. If you go from the PRI to the IP
> > device, you do have a problem. There is no way to indicate which
> > compression you want. But you can use the "Unrestricted digital
> > information with tones/announcements" to tell the interworking unit to
> > not modify the data, and speech to tell the interworking unit that the
> > data is compressible with a voice compression algorithm, and 3.1 kHz
> > audio to hint that it may be fax or modem data (or you can use the
> > dialed number to determine this).
>
> Every number in the ISDN should be able to support voice and data. A
> user does not want to change numbers in order to add a capability to
> their existing service. I don't like to use DNIS to sort out
> applications.
There's tarrifing issues. I have to pay extra to get data and voice
on my B channels. If I have a telephone only device I don't want to
pay for a service I don't use. However, I'm in Connecticut (3 cents
per minute data, voice unmetered on local calls), so I may want Voice
capability on my Data lines.
>
> > > so it still seems to me that a NEW voice bearercap is
> > > needed for crossover calls SS7 to IP and IP to SS7. Not imperative, but
> > > I predict that a slight improvement can be noted. As opposed to noting
> > > ANY difference between speech and audio.
> > >
> > > Thanks, again, Jeffrey
> >
> > -----------------------------------
> > Hank Karl
> > Opinions mine, not my company's
> > to reply, remove the "imnothere" from my address
>
> I would want the 7 kHz audio bearercap from ISDN to map to an IP's
> guaranteed QoS of 64 kbit/s delivery of the PCM samples delivered from
> the SS7 side, and speech or 3.1 kHz audio to map to the compressed
> G-whatever vocoder's IP capability.
How about speech to the compressed vocoder and 3.1k audio to a
fax/modem? Demodulate the fax/modem data and just send the important
stuff, as you do on the Airphone system. Or even use 3.1k for
fax/modem and speech, if no tones (ie the one to turn off the echo
canceler) are heard, assume speech and send it to a higher quality
voice compression device.
> As an IP telephony caller, I would
> want the option of requesting a 7 kHz audio bearercap, to be mapped to
> IP's guaranteed QoS of 64 kbit/s delivery of the PCM samples that are
> collected by my computer, in the event that the G-whatever samples that
> are collected by my computer (that are decoded at the SS7/IP gateway)
> were somehow, temporarily perhaps, of lesser subjective use. Somehow I
> don't think things are headed this way, though.
I guess it depends on what people are willing to pay for.
>
> Regards, Jeffrey
Amanda Walker
> Well, this is the point I am making: there is no way for the Q.931
> control signaling of H.323 SS7/IP gateways to indicate that the IP
> portion of a crossover call has been *enhanced* by G-whatever vocoders,
> and that further *enhancements* are NOT indicated,
Correct.
> which is another way
> of saying that the circuit switch portion of the call requires "bit for
> bit, every byte the same" delivery to the called destination.
I do not agree. Yes, I agree that some types of signal processing,
particularly compression, degrade the signal, and that this results in
lower audio quality than a call placed over a path which does not do
as much modification of the audio signal. I just don't agree that
changing the labelling at the Q.931 layer is the right solution.
Using better compressors, for example, or treating the call as data
end-to-end (where both endpoints are PCs or VOIP "phones"), strike me
as being much more effective places to address issues of audio
quality. Now, granted, I'm a "data bigot", in that I think that a big
ATM switching fabric hauling data around is a more useful wide area
transport facility than the current PSTN. I would much prefer to move
to a network where everything's data and it's up to the endpoints to
deal with analog audio.
> Or do you stand by the ISDN standards and try to claim that the
> bearercap of 3.1KHz Audio is a sufficient mapping for such a call,
> afterall the PSTN has been processing similar calls from cellular
> switches without too much complaint, but then the public would probably
> welcome any improvements that are more likely to be noticed when the
> public's total call consumption is at least 50% crossover to cellular,
> crossover to crossover call forwarding, or the existing digital cellular
> to digital celluar calls.
I think that a bearer capability of 3.1KHz Audio is sufficient, and I
think that the cellular analogy is quite reasonable.
> Well, do you see the connumdrom now? BTW, how does Ascend Multivoice
> provide "Absolute QOS"?
Multivoice implements bandwidth and latency management policies which
guarantee particular qualities of service. It does not, and cannot,
rely on IP or Q.931 to do this. Absolute QoS is a policy implemented
by the switching fabric (i.e., the carrier), not the customer endpoint
equipment. This is precisely where I've been saying such policy
should be implemented, and I'm not even on the Multivoice team :-).
> So we agree that converting the crossover call from IP to SS7 cannot
> possibly guarantee "bit-for-bit, every byte the same" within the
> PSTN/ISDN since the only existing ISDN standards bearercap that provides
> that is Unrestricted 64000 bit/s data, right?
Correct, ignoring 56K data for the moment. If you need to preserve a
bitstream, only a data bearer call will do.
> Hmmmm, seems we need a NEW
> voice bearercap to accomplish this overlooked benefit!
Incorrect. Audio is not a bitstream. Really. How well an audio signal
is represented by a bitstream for transport, and what transformations may
be done upon it in transit, are a policy issue.
Vernon Schryver
David desJardins <da...@desjardins.org> wrote:
>Vernon Schryver <v...@calcite.rhyolite.com> writes:
>> Not so! The problem of fairness has nothing to do with whether the network
>> honors IP TOS bits. It is easy to abuse any scheme that gives some traffic
>> better service based on actions of the endpoints.
>
>request, then it's not easy, or even possible, for them to "abuse" the
>system; they get exactly what they pay for. If they get better service
>by paying more, that's not abuse; it's capitalism.
Ease of abuse (i.e. hogging bandwidth) is different from paying for abuse.
>> One of the jobs of the network is to ensure that abusers pay for their
>> abuse in money, effective quality of service, termination of service,
>> nasty phone calls from NOC and/or any other way, and so don't do it
>> unnecessarily.
>
>This seems to contradict the previous statement that any scheme is easy
>to abuse. Now you are saying (more correctly in my view) that network
>providers can act to stop such abuse.
>
>However, such deterrence has not been particularly successful, and the
>problem is growing:
I've seen no evidence that the problem is growing. I've heard rumors of
modern TCP implementations that supposedly intentionally lack slow start,
but a few years ago the TCP from certain large PC outfits was also broken,
supposedly not on purpose. Supposed intentions are irrelevant to the
effects of actions. I've also heard of things like "replacements" for
TCP using UDP "tunnels," but blast-and-forget-UDP has been around on the
Internet since NSFNet days. Since before the big congestion problems
on the NSFNet, there was hand wringing about the evils bandwidth hogging
and how realsoonnow accounting and billing would have to change, usually
to pay-by-the-packet.
One of the wonders of capitalism is that when <<and if>> the problem
gets bad enough, the major carriers will changing their billing
and accounting to deal with it. Until then, the decades of academic,
telco, and lawyerly/congresscritter demands for changes are mere
wannabe command-economy commissar consciousness raising.
>> It makes exactly as much sense to worry about people cheating and
>> setting low-delay IP TOS bits on their FTP packets as to worry about
>> people cheating and not doing slow-start on their TCP links. Both are
>> theoretically valid worries, but to date, many more have abused the
>> Internet by failing to reduce congestion windows.
>
>Exactly! All three of these are the same sort of problem. Of course,
>there are currently more noncooperative users using "improper"
>congestion control than "improper" TOS, simply because TOS is mostly
>ignored, so there's little incentive to fake it. But deploy TOS widely,
>and that could change fast.
Yes, the sky could fall. Worse, the sky has fallen before, and there
are sufficent reasons to expect it to fall again.
>The problem with TCP congestion control is precisely that it relies on
>users to be honest and cooperative; we are therefore stuck with a major
>effort in trying to police that, something that no one has really
>figured out how to do. I think that a lot of people are reluctant to
>make big efforts to deploy other services (such as IP TOS) that have the
>same problem.
I very much doubt that has anything to do with the lack of use of IP TOS.
IP TOS matters most at low-speed choke-points, such as on home computers
running at most 128 Kbit/sec, and and small IPS's. As others have
observed, other schemes are better at big routers "in the core" (whatever
that means today). The advantage of IP TOS is that it needs only about
15 lines of C and one extra pointer per queue (less if you don't worry
about starvation), and so could be done in the tiniest of ISDN routers
and even hosts.
--
Vernon Schryver v...@rhyolite.com
David desJardins
> Ease of abuse (i.e. hogging bandwidth) is different from paying for abuse.
If I'm willing to pay the cost of the resources that I use, that it's
not at all "abuse" for me to do so, just because you think it's more
than I should have. It seems to me that you are the advocate of the
"command economy" here, rather than its enemy.
>> However, such deterrence has not been particularly successful, and the
>> problem is growing:
>
> I've seen no evidence that the problem is growing. I've heard rumors of
> modern TCP implementations that supposedly intentionally lack slow start,
> but a few years ago the TCP from certain large PC outfits was also broken,
> supposedly not on purpose.
The problem is growing because a growing fraction of the traffic is UDP
traffic which doesn't obey TCP congestion controls. Certainly some
people hack their TCP implementations to deliberately bypass congestion
controls (I wouldn't be surprised to find myself doing that, one of
these days), but I'm not claiming that that problem is necessarily
growing. I don't have any data. But I do know the fraction of *total
traffic* that ignores congestion controls is growing.
> I very much doubt that has anything to do with the lack of use of IP TOS.
> IP TOS matters most at low-speed choke-points, such as on home computers
> running at most 128 Kbit/sec, and and small IPS's.
I don't know what an "IPS" is. I don't at all agree that TOS matters
most at low-speed points. The problem, from my point of view, is that
that my small number of packets from my low-bandwidth latency-sensitive
uses (such as telnet/ssh sessions) tend to get dropped by congested
backbone routers; for those types of uses, even small packet loss rates
are significant. This is precisely the point at which TOS could make a
substantial difference, by putting my small number of high-priority
packets ahead of the larger amount of traffic which is much more
latency- and congestion-tolerant.
> As others have observed, other schemes are better at big routers "in
> the core" (whatever that means today).
If you can explain how you think latency-sensitive low-bandwidth traffic
should be moved ahead of latency-insensitive high-bandwidth traffic, I'd
be glad to hear about it. I don't see how you can do that without
distinguishing the two.
David desJardins
jcrh...@my-dejanews.com
lma...@vnet.ibm.com (Laurence V. Marks) wrote:
> In <361a97f0...@news.sonic.net>, himnoth...@imnotherenlc.com (Hank
Karl) writes:
> >The 8 kHz integrity (as I understand it) only means that you will get
> >a sample rate of 8 kHz. It does not mean that the value of each
> >sample will be unaffected. The amplitude of the sample may be changed
> >(eg the signal may be run through a digital filter.)
>
> My understanding of 8 KHz integrity is that byte boundaries are preserved.
> What you put in on each sample of a B-channel comes out that way on the
> other end. You absolutely need this with speech samples--they would be
> trashed if slipped by a bit either way. You don't need it on HDLC-ish
> data, and such data changes alignment with every zero-bit-insert after
> five ones, anyway, but you get it. I think you get it on all
> circuit-switched services, just not on packet-switched. And you certainly
> don't need it there.
>
> Or is Jeffrey lobbying for packet-switched service with 8 KHz integrity.?
>
> Laurence V. Marks
> IBM Corp. - Research Triangle Park, NC
Hey, Laurence, I'm over here. Did you see the posting I tried to send to you
that relays that "No, my newsadmin is NOT blocking the 'ibm.com' domain".
Claircom gets a newsfeed from Northwest NEXUS, so maybe they have a problem
with spam from IBM?
"8 KHz integrity" (do the new standards use 8 kHz, like they do for bearcap
specification of 3.1 kHz and 7 kHz Audio, or is there something subtle going
on with KHz?) must mean alot of different things to different standards
people.
If you look at ALL my postings on this thread, (I assume you don't see them
unless you make a special effort, which is why I came over here to post ;-),
what I am looking for is two different "sockets" for the IP portion of the
crossover SS7/IP voice call. As an ISDN voice caller to the IP ISDN, I'd like
to use a 7 kHz Audio bearercap to request the type of socket that a 64 kbit/s
ISDN data call would ALSO be able to use, for the IP portion of a crossover
SS7/IP call. I'd like the speech and 3.1 kHz audio bearercaps to request a
different "socket", so that the IP portion of a crossover SS7/IP voice call
is supported by transporting packets of G-whatever H.323 vocoders.
Hank has me intrigued with the "bearer capability selection" procedures
introduced in the 1992 ITU-T standards for Q.931. (You don't really believe
any of this has hit the US ISDN and SS7 switches yet, right?) It seems that
ISDN callers need to be able to request two types of IP transport: one that
provides 64 kbit/s transport of raw PCM (or other raw bit streams) and
another less intensive IP connection (by that I mean one that requires a less
stringent IP QoS) that transports a G-whatever vocoders' packets at around 8
or so kbit/s transport, I guess the speed required depends on the vocoder's
encodability.
So, no, for the IP "socket" that is able to *Guarantee Quality of Service*
for 64 kbit/s "socket to socket", I do not need the IP sockets to deliver the
IP packets at EXACTLY 8 bits per 1/8000ths of a second, as long as the
latency of packets' delivered is able to ASSURE that the 64 kbit/s data
stream is embedded in IP to continously transport every byte of the 64 kbit/s
data stream when it is needed, at what must on average be 8 bits per
1/8000ths of a second.
Would you care to guess how IP would be able to provide a QoS that is able to
deliver the continuous 64 kbit/s needed to support an ISDN data call? Yes,
this does not imply byte alignment, nor is it needed as you post above, since
even PPP has bit-stuffing, right?
The same QoS could be used for a voice call, using encrypted PCM for privacy,
for example, or, nonencrypted PCM simply for the subjective improvement that
results when the G-whatever vocoder is bypassed on the IP portion of a
crossover SS7/IP voice call. While byte alignment for voice encrypted PCM is
a necessity, TCP is a streaming protocol that is able to accomplish this. How
to get the circuit mode bytes to line up with IP packet mode bytes might be
tricky, but once the startbyte boundaries are synced between circuit mode
transport and packet mode transport, the alignment will follow. I mention
this because I sense that Amanda wants 8 kHz Integrity to imply somekind of
synchronicity, whereas all I need is somekind of alignment that can suffer
minor latencies within a "window of synchronicity".
So if 8 KHz Integrity implies that an HDLC-like protocol with zero bit
insertion is not possible, then that is not what I am lobbying for. If 8 KHz
Integrity implies that "every bit of every byte is delivered exactly the
same, end-to-end at 64 kbit/s" (I think Robert holds this to be a
characteristic of 8 KHz Integrity) then I AM lobbying for "packet switch
service with 8 KHz integrity".
One other detail about Q.931 standard that I need help with. I've never looked
that closely at an ISDN 64 kbit/s data call's SETUP trace to know exactly what
the bearercap IE looks like. I've always assumed that existing US ISDN encoded
the "Transfer mode" of Octet 4 of the Bearer Capability Information element,
bits 7 and 6, to be "circuit mode". Am I wrong, is this EVER encoded as
"packet-mode" for calls that remain within the switched circuits of the Public
Switching Network?
Oh,yes, before I let you go, we both agree that the low level compatibility
information is not passed in the US ISDN. Have you ever been able to use these
IEs effectively WITHIN a single US ISDN switch?
Thanks for your support, I hope others will feel free to respond to this
thread.
Regards, Jeffrey
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Jeffrey Rhodes
>
> Jeffrey Rhodes wrote:
> >
> > Hank Karl wrote:
> > >
> > >
> > > Looking through the specs (Q.931), I remembered the BC = Unrestricted
> > > digital information with tones/announcements (the old 7 kHz audio BC).
> > > I think that Bob Blackshaw or someone had mentioned this earlier. I
> > > believe that this BC means that unrestricted (64 kHz) data may be sent
> > > through the system, the system won't change the data, and that the
> > > data is audio-type data.
> >
> > bearercap that I am familiar with is extending a stereo FM broadcast
> > audio feed, while the video takes a satellite feed, since I notice that
> > I "hear" golf shots on TV before the golf ball "appears" to be struck.
> > Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> > integrity to be able to be used for cellular TDMA callers. Somehow, a
> > SS7 routing translations are able to pass this bearercap universally
> > within ISDN?
> >
> for AM broadcast stations back in Bell Canada. 7kHz FM? <barf>
>
>
> --
> "Since when was genius found respectable?"
> E. B. Browning
Bob,
When you set up those 15kHz "lines" for AM broadcast, how many "lines"
are needed, if one considers each "line" a DS0's-worth of a call?
Yes, I know 7kHz non-stereo FM must *sound* kind of barfy, but who cares
what it sounds like at some ski lodge between mountaintops where the
broadcaster simply wants to transmit their commercials to?
Regards, Jeffrey
Rhodes
analysers I've used let me click on the "Q931 : 6178:SETUP" line and,
bingo, there's the entire message all mapped out. The Bearer Cap IE is in
there some place, two bits of it determine whether "circuit mode" or "packet
mode" is requested.
regards, jcr
wdg@[204.52.135.1] wrote in message <3629e156...@news.hal-pc.org>...
>In article <708l78$4gi$1...@nnrp1.dejanews.com> jcrh...@my-dejanews.com
>writes:
>
>[snip]
>
>>One other detail about Q.931 standard that I need help with. I've never
looked
>>that closely at an ISDN 64 kbit/s data call's SETUP trace
>
>peruse at will.
>See below. Entire Q931 call setup trace from an OCLM connecting at 64k.
>(unless I'm missing something obvious, I don't see that bearer capability
>was ever negotiated)
>
>MSGID : TIME: (column increment is in tenths of seconds)
>
>Q931 : 6177:<1>Message from CC: (buffer addr = 0x1d9cc6), data
>length=268
>Q931 : 6177:Contents:20 bytes:
> 00 31 00 08 10 40 0a 32 38 31 35 36 30 30 31 34 | ^1^^^@^281560014
> 35 00 00 00 | 5^^^
>Q931 : 6177:Switch Type: 3, Subtype: 0
>Q931 : 6177:cr_index -1 call block 1 cref 49
>Q931 : 6177:SETUP_R
>Q931 : 6177:Initial L3 State: U0-Idle
>Q931 : 6177:Q.931 Link = 1
>Q931 : 6177:M&M Event : User Request
>Q931 : 6177:M&M State : Initialized
>Q931 : 6177:IE (encoded for transmission): Chan ID
>Q931 : 6177:IE (encoded for transmission): Keypad
>Q931 : 6177:Encode origination address IE
>Q931 : 6177:<1>Message to Q.921 (DL_DATA): (buffer addr = 0x1db24a)
>Q931 : 6178:Contents:33 bytes:
> 08 01 31 05 04 02 88 90 18 01 83 2c 0a 37 31 33 | ^^1^^^^^^^^,^713
> 36 32 35 39 39 30 39 6c 08 c1 35 36 30 30 31 34 | 6259909l^^560014
> 35 | 5
>Q931 : 6178:SETUP
>Q931 : 6178:Start Timer, cref=0x31, ntimers=1
>Q931 : 6178:Final L3 State : U1-Call Init
>Q931 : 6186:<1>Message from Q.921 (DL_DATA): (buffer addr = 0x1decdc)
>Q931 : 6186:Contents:7 bytes:
> 08 01 b1 02 18 01 89 | ^^^^^^^
>Q931 : 6186:Cref 49 length 1
>Q931 : 6186:CALL PROCeeding
>Q931 : 6186:IE (received) : Chan ID
>Q931 : 6186:cr_index 1 call block 1 cref 49
>Q931 : 6186:Initial L3 State: U1-Call Init
>Q931 : 6186:Q.931 Link = 1
>Q931 : 6186:M&M Event : Msg with no ID
>Q931 : 6186:M&M State : Initialized
>Q931 : 6186:Enter Stoptimer
>Q931 : 6186:Stop Timer, cref=0x31, ntimers=0
>Q931 : 6186:<1>Message to CC: (buffer addr = 0x1dc438), data length=4
>Q931 : 6186:CALL_PROC_I
>Q931 : 6186:Start Timer, cref=0x31, ntimers=1
>Q931 : 6186:Final L3 State : U3-Call Proceeding
>Q931 : 6191:<1>Message from Q.921 (DL_DATA): (buffer addr = 0x1dde84)
>Q931 : 6191:Contents:7 bytes:
> 08 01 b1 01 34 01 01 | ^^^^4^^
>Q931 : 6191:Cref 49 length 1
>Q931 : 6191:ALERTing
>Q931 : 6191:IE (received) : Signal
>Q931 : 6191:cr_index 1 call block 1 cref 49
>Q931 : 6191:Initial L3 State: U3-Call Proceeding
>Q931 : 6191:Q.931 Link = 1
>Q931 : 6191:M&M Event : Msg with no ID
>Q931 : 6191:M&M State : Initialized
>Q931 : 6191:Enter Stoptimer
>Q931 : 6191:Stop Timer, cref=0x31, ntimers=0
>Q931 : 6191:<1>Message to CC: (buffer addr = 0x1dc7ce), data length=4
>Q931 : 6191:ALERT_I
>Q931 : 6191:Final L3 State : U4-Alerting
>Q931 : 6191:<1>Message from Q.921 (DL_DATA): (buffer addr = 0x1da524)
>Q931 : 6191:Contents:7 bytes:
> 08 01 b1 07 34 01 3f | ^^^^4^?
>Q931 : 6191:Cref 49 length 1
>Q931 : 6191:CONNected
>Q931 : 6191:IE (received) : Signal
>Q931 : 6191:cr_index 1 call block 1 cref 49
>Q931 : 6191:Initial L3 State: U4-Alerting
>Q931 : 6191:Q.931 Link = 1
>Q931 : 6191:M&M Event : Msg with no ID
>Q931 : 6191:M&M State : Initialized
>Q931 : 6191:<1>Message to CC: (buffer addr = 0x1dee0e), data length=52
>Q931 : 6191:CONN_I
>Q931 : 6191:<1>Message to Q.921 (DL_DATA): (buffer addr = 0x1dac50)
>Q931 : 6191:Contents:4 bytes:
> 08 01 31 0f | ^^1^
>Q931 : 6191:CONNect ACK
>Q931 : 6191:Final L3 State : U10-Active
>END
>
>Total elapsed time to connect: 1.4 secs Not bad.
>
>[posted and mailed]
>
Robert Blackshaw
>
>
> Would you care to guess how IP would be able to provide a QoS that is able to
> deliver the continuous 64 kbit/s needed to support an ISDN data call? Yes,
> this does not imply byte alignment, nor is it needed as you post above, since
> even PPP has bit-stuffing, right?
>
> The same QoS could be used for a voice call, using encrypted PCM for privacy,
> for example, or, nonencrypted PCM simply for the subjective improvement that
> results when the G-whatever vocoder is bypassed on the IP portion of a
> crossover SS7/IP voice call. While byte alignment for voice encrypted PCM is
> a necessity, TCP is a streaming protocol that is able to accomplish this. How
> to get the circuit mode bytes to line up with IP packet mode bytes might be
> tricky, but once the startbyte boundaries are synced between circuit mode
> transport and packet mode transport, the alignment will follow. I mention
> this because I sense that Amanda wants 8 kHz Integrity to imply somekind of
> synchronicity, whereas all I need is somekind of alignment that can suffer
> minor latencies within a "window of synchronicity".
>
> So if 8 KHz Integrity implies that an HDLC-like protocol with zero bit
> insertion is not possible, then that is not what I am lobbying for. If 8 KHz
> Integrity implies that "every bit of every byte is delivered exactly the
> same, end-to-end at 64 kbit/s" (I think Robert holds this to be a
> characteristic of 8 KHz Integrity) then I AM lobbying for "packet switch
> service with 8 KHz integrity".
>
Sheesh, Churchill was right.
8kHz integrity is exactly what it says, the English is perfectly
clear dammit. What the sender gives the network as a byte will
be delivered as a byte. We don't care what is in the &^%$# byte
nor will we examine it, it is just a byte. If you give me
8 bits in "this" timeframe I'm goona deliver those 8 bits in a
"matching" timeframe.
Yeah, I'm getting to be a curmudgeon.
Robert Blackshaw
>
> Robert Blackshaw wrote:
> >
> > Jeffrey Rhodes wrote:
> > >
> > > Hank Karl wrote:
> > > >
> > > > Jeffrey,
> > > >
> > > > digital information with tones/announcements (the old 7 kHz audio BC).
> > > > I think that Bob Blackshaw or someone had mentioned this earlier. I
> > > > believe that this BC means that unrestricted (64 kHz) data may be sent
> > > > through the system, the system won't change the data, and that the
> > > > data is audio-type data.
> > >
> > > bearercap that I am familiar with is extending a stereo FM broadcast
> > > signal to remoted broadcast antennaes. Maybe commercial TV uses this for
> > > audio feed, while the video takes a satellite feed, since I notice that
> > > I "hear" golf shots on TV before the golf ball "appears" to be struck.
> > > Anyway, I want the NEW voice bearercap that requests mid-to-end bit
> > > integrity to be able to be used for cellular TDMA callers. Somehow, a
> > > request for 7 kHz audio, does not really fit with me. I wonder, too, if
> > > SS7 routing translations are able to pass this bearercap universally
> > > within ISDN?
> > >
> > Glad I don't listen to those stations, heck we even put in 15kHz lines
> > for AM broadcast stations back in Bell Canada. 7kHz FM? <barf>
> >
> >
> > --
> > "Since when was genius found respectable?"
> > E. B. Browning
>
>
> When you set up those 15kHz "lines" for AM broadcast, how many "lines"
> are needed, if one considers each "line" a DS0's-worth of a call?
>
the necessary bandwidth (matter of fact I once used a pair of
them in a stereo system - pretty decent for their day). Of
course these were permanent studio to transmitter lines, though
we even set them up for "field" broadcasts given adequate
notice.
Rhodes
Robert Blackshaw wrote in message <362891...@erols.com>...
>
>8kHz integrity is exactly what it says, the English is perfectly
>clear dammit. What the sender gives the network as a byte will
>be delivered as a byte. We don't care what is in the &^%$# byte
>nor will we examine it, it is just a byte. If you give me
>8 bits in "this" timeframe I'm goona deliver those 8 bits in a
>"matching" timeframe.
>
>Yeah, I'm getting to be a curmudgeon.
>
>Bob
Is that somekind of animal?
Hank Karl posted on this thread:
>The network may violate the specs. It may be their policy to, or it
>may be a limitation of the equipment they use. Just because one
>player violates the specs does not mean that we need a new BC
>(so they can violate that one too?).
>My understanding is that 3.1 kHz audio should not have any
>enhancements to it. The bits presented on one side (at least the 7
>MSB in each octet) should come out the other, the only difference
>between input and output would be a time delay.
>
>The 8 kHz integrity (as I understand it) only means that you will get
>a sample rate of 8 kHz. It does not mean that the value of each
>sample will be unaffected. The amplitude of the sample may be changed
>(eg the signal may be run through a digital filter.)
> >
Does 8kHz Integrity mean "every bit the same, every byte continuous within a
window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
meaning of this term widely misinterpreted (wrt "the standards") such that a
NEW voice bearercap would be able to express to the network EXACTLY what is
desired for routing purposes?
Thanks, Jeffrey
Robert Blackshaw
>
> Robert Blackshaw wrote in message <362891...@erols.com>...
> >jcrh...@my-dejanews.com wrote:
> >>
> >
> >>
> >
> >8kHz integrity is exactly what it says, the English is perfectly
> >clear dammit. What the sender gives the network as a byte will
> >be delivered as a byte. We don't care what is in the &^%$# byte
> >nor will we examine it, it is just a byte. If you give me
> >8 bits in "this" timeframe I'm goona deliver those 8 bits in a
> >"matching" timeframe.
> >
> >Yeah, I'm getting to be a curmudgeon.
> >
> >Bob
>
> Is that somekind of animal?
>
> Hank Karl posted on this thread:
>
> >The network may violate the specs. It may be their policy to, or it
> >may be a limitation of the equipment they use. Just because one
> >player violates the specs does not mean that we need a new BC
> >(so they can violate that one too?).
>
> >My understanding is that 3.1 kHz audio should not have any
> >enhancements to it. The bits presented on one side (at least the 7
> >MSB in each octet) should come out the other, the only difference
> >between input and output would be a time delay.
> >
> >a sample rate of 8 kHz. It does not mean that the value of each
> >sample will be unaffected. The amplitude of the sample may be changed
> >(eg the signal may be run through a digital filter.)
> > >
>
> window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
> meaning of this term widely misinterpreted (wrt "the standards") such that a
> NEW voice bearercap would be able to express to the network EXACTLY what is
> desired for routing purposes?
>
unless it is a voice call from A-law to mu-law, in which case
a translation does happen.
Laurence V. Marks
>Not at all. I'm suggesting that calls should be presented if the line
>is provisioned for them. If the equipment on the other end can answer
>them, it should accept the call. What the endpoint equipment decides
>to do with it from there is up to it. The network doesn't care.
>
Sometimes the switch doesn't care either. A DMS-100 will happily deliver a
64K Unrestricted Digital call to your POTS phone. At least it used to.
Laurence V. Marks
>At the Melbourne meeting in 93 the CCITT became ITU-T and the
>coloured books pretty much became history. Now when a Study
>Group agrees that aa Recommendation is ready it is "Decided"
>and is published on the spot (Well, after translation into
>French and Spanish). The old 4-year study period idea is
>history.
>
Laurence V. Marks
>The problem is growing because a growing fraction of the traffic is UDP
>traffic which doesn't obey TCP congestion controls. Certainly some
>people hack their TCP implementations to deliberately bypass congestion
>controls (I wouldn't be surprised to find myself doing that, one of
>these days), but I'm not claiming that that problem is necessarily
>traffic* that ignores congestion controls is growing.
>
All those young whipper-snappers using ICQ and playing Quake. :-(
Laurence V. Marks
>Hey, Laurence, I'm over here. Did you see the posting I tried to send to you
>that relays that "No, my newsadmin is NOT blocking the 'ibm.com' domain".
>Claircom gets a newsfeed from Northwest NEXUS, so maybe they have a problem
>with spam from IBM?
>
were any quoted ones where I didn't also see the original.
I usually only read the ng once a week these days, which means you may
think I'm not responding--and sometimes I have nothing interesting to say.
(Say, you don't suppose I'm in the killfile on the machine you use to read
Claircom, do you? Try rm .killfile .)
>"8 KHz integrity" (do the new standards use 8 kHz, like they do for bearcap
>specification of 3.1 kHz and 7 kHz Audio, or is there something subtle going
>on with KHz?) must mean alot of different things to different standards
>people.
>
Nobody seems to know the real intent of 64K UDI with tones/announcements.
I thought it was going to be used when an ISDN-originated call got lost in
POTS-land, and the tape said, "beep BEEP BEEEEP. The number you have
called is not in service. Please be sure you are dialing the correct
number." directed to your 64K data terminal. I have seen this happen.
But some text Hank Karl posted implied that this was not how it was to be
used.
>If you look at ALL my postings on this thread, (I assume you don't see them
>unless you make a special effort, which is why I came over here to post ;-),
I do see them, I do. I just don't always have anything to say.
>what I am looking for is two different "sockets" for the IP portion of the
>crossover SS7/IP voice call. As an ISDN voice caller to the IP ISDN, I'd like
>to use a 7 kHz Audio bearercap to request the type of socket that a 64 kbit/s
>ISDN data call would ALSO be able to use, for the IP portion of a crossover
>SS7/IP call. I'd like the speech and 3.1 kHz audio bearercaps to request a
>different "socket", so that the IP portion of a crossover SS7/IP voice call
>is supported by transporting packets of G-whatever H.323 vocoders.
>
I am not sure I understand the issues very well. I understand a call over
IP. I understand calls over Circuit-switched, e./g., DS-0s. I do not even
understand calls over SS7.
>Hank has me intrigued with the "bearer capability selection" procedures
>introduced in the 1992 ITU-T standards for Q.931. (You don't really believe
>any of this has hit the US ISDN and SS7 switches yet, right?) It seems that
Since I left the ISDN group, I don't usually get ISDN switch announcements
any more. It was only an accident that I found out about NA-009 last year.
But they only add stuff there is demand for. Your requirement is
sufficiently arcane that there is probably not much of a line waiting for
the feature. (I don't even own a pager--much less a cell phone.)
>ISDN callers need to be able to request two types of IP transport: one that
>provides 64 kbit/s transport of raw PCM (or other raw bit streams) and
>another less intensive IP connection (by that I mean one that requires a less
>stringent IP QoS) that transports a G-whatever vocoders' packets at around 8
>or so kbit/s transport, I guess the speed required depends on the vocoder's
>encodability.
>
Once voice has been processed by a G.7xx vocoder, it's not voice. It's
data, and the forwarder should use data links for the next hops, right. If
there's a network provided reverse-vocoder on the other end, he should use
a voice BC for the next hops. If you are going to change the form of the
information, you change the required BC with it, right?
>
>Would you care to guess how IP would be able to provide a QoS that is able to
>deliver the continuous 64 kbit/s needed to support an ISDN data call? Yes,
>this does not imply byte alignment, nor is it needed as you post above, since
>even PPP has bit-stuffing, right?
>
Sure. This sounds like a conversion from circuit-switched to
packet-switched to me. This is defined in X.31, for example.
>The same QoS could be used for a voice call, using encrypted PCM for privacy,
>for example, or, nonencrypted PCM simply for the subjective improvement that
>results when the G-whatever vocoder is bypassed on the IP portion of a
>crossover SS7/IP voice call. While byte alignment for voice encrypted PCM is
>a necessity, TCP is a streaming protocol that is able to accomplish this. How
>to get the circuit mode bytes to line up with IP packet mode bytes might be
>tricky, but once the startbyte boundaries are synced between circuit mode
>transport and packet mode transport, the alignment will follow. I mention
>this because I sense that Amanda wants 8 kHz Integrity to imply somekind of
>synchronicity, whereas all I need is somekind of alignment that can suffer
>minor latencies within a "window of synchronicity".
>
Maybe I'm missing something obvious, but encrypted PCM isn't voice,
Jeffrey. It's data.
>So if 8 KHz Integrity implies that an HDLC-like protocol with zero bit
>insertion is not possible, then that is not what I am lobbying for. If 8 KHz
>Integrity implies that "every bit of every byte is delivered exactly the
>same, end-to-end at 64 kbit/s" (I think Robert holds this to be a
>characteristic of 8 KHz Integrity) then I AM lobbying for "packet switch
>service with 8 KHz integrity".
>
I agree. All packet-switched stuff has integrity. It's a data service.
>One other detail about Q.931 standard that I need help with. I've never looked
>that closely at an ISDN 64 kbit/s data call's SETUP trace to know exactly what
>the bearercap IE looks like. I've always assumed that existing US ISDN encoded
>the "Transfer mode" of Octet 4 of the Bearer Capability Information element,
>bits 7 and 6, to be "circuit mode". Am I wrong, is this EVER encoded as
>"packet-mode" for calls that remain within the switched circuits of the Public
>Switching Network?
>
I dunno. I'm answering so you know I saw the posting in its entirety.
>Oh,yes, before I let you go, we both agree that the low level compatibility
>information is not passed in the US ISDN. Have you ever been able to use these
>IEs effectively WITHIN a single US ISDN switch?
>
Never tried. I don't have any easy vehicles to experiment with. If I did,
I might drop all the different code loads in the Teleos (Madge) switch, and
see what happens with the US simulation, AT&T Custom, Euro, 1TR6, and
INS-NET 64 (NTT). But I don't.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
You and Fred both, huh? Must be turning into mouse-users.... :-)
Rhodes
<24zpay5...@amanda-gw2k.eng.hrn.ascend.com>...
>Jeffrey Rhodes <jeffrey...@attws.com> writes:
>> Well, this is the point I am making: there is no way for the Q.931
>> control signaling of H.323 SS7/IP gateways to indicate that the IP
>> portion of a crossover call has been *enhanced* by G-whatever vocoders,
>> and that further *enhancements* are NOT indicated,
>
>Correct.
below.
>Correct, ignoring 56K data for the moment. If you need to preserve a
>bitstream, only a data bearer call will do.
>
>> Hmmmm, seems we need a NEW
>> voice bearercap to accomplish this overlooked benefit!
>
>Incorrect. Audio is not a bitstream. Really. How well an audio signal
>is represented by a bitstream for transport, and what transformations may
>be done upon it in transit, are a policy issue.
>
>
>Amanda Walker
>Senior Software Engineer
>Ascend Communications, Inc.
>[personal opinion, not an official statement from Ascend]
Hello Amanda,
OK, ignoring 56K *data* for the moment. Hank seems to agree with you about
policy, or at least at the SS7/IP *voice* boundary. I agree with you in the
sense that these things are largely not within most users' control. But Hank
also makes a case for extending ISDN via VoIP claiming that the D in ISDN is
digital, like IP is digital. OK, but an ISDN user, in my opinion, needs to
be able to have all their services on one number (or at least customisable
for one number), more numbers optional, but the basic concept of ISDN
integrates voice and digital networks, so I want to make a case for
extending ISDN's *data* calls via IP. How does Ascend's "Absolute Q0S" make
a 64 kbit/s data call possible with IP?
>Absolute QoS is a policy implemented
>by the switching fabric (i.e., the carrier), not the customer endpoint
>equipment.
But an ISDN customer can make a data call to an IP's ISDN number, so the
customer endpoint MUST have the ability to select whatever policy that
"Absolute QoS" establishes for ISDN data calls. IMHO, it would be nice if
ISDN voice end-users had a capability to select this same "Absolute QoS". 7
kHz Audio bearercap could imply this preference to the SS7/IP gateway and
with "bearer capability selection" procedures, a fallback bearercap of 3.1
kHz Audio would select the general purpose audio "Absolute QoS". It would be
carrier policy as to whether or not the premium "Absolute QoS" is granted or
the fallback is forced.
Thanks,
Jeffrey Rhodes
Sr. Systems Engineer
AT&T Wireless Services Aviation Communications Division
Vernon Schryver
David desJardins <da...@desjardins.org> wrote:
> ...
>> I've seen no evidence that the problem is growing. I've heard rumors of
> ...
>The problem is growing because a growing fraction of the traffic is UDP
>traffic which doesn't obey TCP congestion controls. Certainly some
>people hack their TCP implementations to deliberately bypass congestion
>controls (I wouldn't be surprised to find myself doing that, one of
>these days), but I'm not claiming that that problem is necessarily
>growing. I don't have any data. But I do know the fraction of *total
>traffic* that ignores congestion controls is growing.
I don't understand. You say you do not know the problem is growing and
you also mention "growing fraction of the traffic is UDP" and "the fraction
of *total traffic* that ignores congestion controls is growing." Do you
mean to say that now a larger fraction of 'core traffic' is UDP or
otherwise congestion-bad than (for example) 10 years ago but you don't
know whether problems caused by such traffic are finally, after decades
of false predictions, becoming significant?
>> I very much doubt that has anything to do with the lack of use of IP TOS.
>> IP TOS matters most at low-speed choke-points, such as on home computers
>> running at most 128 Kbit/sec, and and small IPS's.
>
>I don't know what an "IPS" is.
Internet Service Provider+typo--consider the queuing delay that a small
ISP with a fractional T1 can offer its customers given a router queue of
50 KBytes (a one time common default on a very large router vendor's
boxes). Or consider someone at home trying to play an interactive game
(including telnet/ssh) while simultaneously copying files (either HTTP or
FTP) through an ISDN router with a similarly sized queue.
(You want substantial router queues to prevent packet losses from either
a small number of streams between hosts using TCP windows large enough to
get reasonable performance on >=100 Mbit/sec LANs or a modest number of
small window TCP streams, such as HTTP. To push 100 Mbit/sec through a
LAN, it's handy to have a TCP window of at least 60K. Then there is the
bandwidth*delay product on T3 WANs.)
> I don't at all agree that TOS matters
>most at low-speed points. The problem, from my point of view, is that
>that my small number of packets from my low-bandwidth latency-sensitive
>uses (such as telnet/ssh sessions) tend to get dropped by congested
>backbone routers;
How do you know your packets are being dropped in the backbone instead of
near the endpoints? I've been spending time with rlogin/ssh recently via
PSI-Uunet-ultranet. Sometimes I do see some evidence of packet loss and
consequent dleays, but not nearly as bad as the delays in the world-wide
corporate network I used before, and from what I can tell, my packets are
now being lost on at the ultranet-customer end. Five to ten (5-10) second
(second!) delays on telnet and rlogin keystrokes are a lot different than
what I see now. Note that those old corporate delays had nothing to do
with packet loss but purely with queuing delays. Note also that they
stopped most of my screaming by reducing the sizes of the router queues
and increasing the bit rates to the FR cloud, instead of honoring the TOS
bits with which I labelled my packets.
> for those types of uses, even small packet loss rates
>are significant.
Yes, each packet loss commonly causes an echo-hiccup of a multiple
(typically 1) of the RTT. With modern Internet RTT's, I'm not sure such
hiccups are significant. On the other hand, my typing was honed on 110
bps FDX TTY's where the echo of every keystroke was at least 200 ms.
> This is precisely the point at which TOS could make a
>substantial difference, by putting my small number of high-priority
>packets ahead of the larger amount of traffic which is much more
>latency- and congestion-tolerant.
On the contrary, I do not see how IP TOS helps packet losses. If you lose
x% of your telnet/ssh packets when they are put on the end of a queue,
then why won't you also lose x% of them when they are put near the front
of the same queue? IP TOS is commonly expected to change where in the
output queue a new packet is placed, not its suitability for dropping.
In my view, IP TOS is good for moving low or high latency packets to the
ends of a queue that is otherwise scheduled by simple FIFO. (If you use
RED on the queue, your extremely low frequency telnet/ssh packets will
not be hit.)
>> As others have observed, other schemes are better at big routers "in
>> the core" (whatever that means today).
>
>If you can explain how you think latency-sensitive low-bandwidth traffic
>should be moved ahead of latency-insensitive high-bandwidth traffic, I'd
>be glad to hear about it. I don't see how you can do that without
>distinguishing the two.
First, your complaints aobut telnet/ssh packet loss are not about queuing
delays, but packet loss. The usual use of IP TOS, at least in what I've
seen and heard about, does not affect packet loss rates, but only queuing
delays.
Do you mean to say that if your telnet/ssh packets were effectively marked,
they would have lower queuing delays, and so the effective RTT would be
smaller, and so the echo-hiccup you see as the result of losses would be
smaller? If so, I think I would disagree, because the queuing delays of
a router running at core-speed is necessarily low. Even merely 50 ms of
queue delay is a lot of bits at 155 Mbit/sec. Do many core routers have
more than 10 Mbit of output queue?. Those 5-10 second echo delays that
bugged me came from 50+Kbytes of router queue at 50-100 Kbit/sec.
Second, the many reports about RED, fair-queuing, early congestion
notification, and so forth contain promising concerning ideas for dealing
with packet loss among unmarked or uniformly marked streams of packets,
as well as fixing mismarked (i.e. 'abusive') streams or over-committed
high-priority streams.
--
Vernon Schryver v...@rhyolite.com
Hank Karl
<blac...@erols.com> wrote:
> Rhodes wrote:
> > Does 8kHz Integrity mean "every bit the same, every byte continuous within a
> > window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
> > meaning of this term widely misinterpreted (wrt "the standards") such that a
> > NEW voice bearercap would be able to express to the network EXACTLY what is
> > desired for routing purposes?
> >
> Yes, there is no reason for the network to fiddle with the bits
> unless it is a voice call from A-law to mu-law, in which case
> a translation does happen.
>
Hi Bob,
There is one good reason besides u-law to A-law conversion. That is,
the call goes over an analog link. I suspect that the digital values
on each of the codecs will be slightly different, due to the impedance
of the copper.
There are some other, perhaps not so good, reasons for the network to
fiddle with the bits. These are echo cancelers and enhancements (ie
Truvoice).
I maintain that, with speech, you cannot guarantee that the bytes will
be the same on each end of the network. I believe that 8 kHz
integrity means that you will not get a "bit slippage", so that you
can transport a stream of bytes, not bits. (ie you always know which
bit is the MSB).
Hank Karl
wrote:
> In <708l78$4gi$1...@nnrp1.dejanews.com>, jcrh...@my-dejanews.com writes:
> >Hey, Laurence, I'm over here. Did you see the posting I tried to send to you
> >that relays that "No, my newsadmin is NOT blocking the 'ibm.com' domain".
> >Claircom gets a newsfeed from Northwest NEXUS, so maybe they have a problem
> >with spam from IBM?
> >
> I think I'm seeing all your posts, Jeffrey. At least I don't think there
> were any quoted ones where I didn't also see the original.
>
> I usually only read the ng once a week these days, which means you may
> think I'm not responding--and sometimes I have nothing interesting to say.
> (Say, you don't suppose I'm in the killfile on the machine you use to read
> Claircom, do you? Try rm .killfile .)
>
> >"8 KHz integrity" (do the new standards use 8 kHz, like they do for bearcap
> >specification of 3.1 kHz and 7 kHz Audio, or is there something subtle going
> >on with KHz?) must mean alot of different things to different standards
> >people.
> >
> Nobody seems to know the real intent of 64K UDI with tones/announcements.
> I thought it was going to be used when an ISDN-originated call got lost in
> POTS-land, and the tape said, "beep BEEP BEEEEP. The number you have
> called is not in service. Please be sure you are dialing the correct
> number." directed to your 64K data terminal. I have seen this happen.
>
> But some text Hank Karl posted implied that this was not how it was to be
> used
I'm only speculating here, I'm not on the ITU, nor do I work for a
carrier or LEC :-) But I think the meaning of the BC was expanded so
that you could send other compressions than 7kHz. After all, the
network is not going to decode them. Also, you do need to get the
tones and announcements, the intention is that there is a user there.
Previously, you had 7 kHz audio on this BC. I think you still can,
but you can also have other compressions. How it was to be used and
how you use it are two different things (DOV is one example). One
question is "what service do you get for this BC"? But I think the
real key is "what does your endpoint TE do when it gets this BC? Does
it assume voice, compressed voice, data, or what?
>
> >ISDN callers need to be able to request two types of IP transport: one that
> >provides 64 kbit/s transport of raw PCM (or other raw bit streams) and
> >another less intensive IP connection (by that I mean one that requires a less
> >stringent IP QoS) that transports a G-whatever vocoders' packets at around 8
> >or so kbit/s transport, I guess the speed required depends on the vocoder's
> >encodability.
> >
> Once voice has been processed by a G.7xx vocoder, it's not voice. It's
> data, and the forwarder should use data links for the next hops, right. If
> there's a network provided reverse-vocoder on the other end, he should use
> a voice BC for the next hops. If you are going to change the form of the
> information, you change the required BC with it, right?
Well, you can say that it's no longer voice (and is now data)
somewhere earlier than that-- is it data when it goes into the
microphone and gets converted to an analog electrical signal? When it
is digitized? When it is companded by a codec? :-)
> >So if 8 KHz Integrity implies that an HDLC-like protocol with zero bit
> >insertion is not possible, then that is not what I am lobbying for. If 8 KHz
> >Integrity implies that "every bit of every byte is delivered exactly the
> >same, end-to-end at 64 kbit/s" (I think Robert holds this to be a
> >characteristic of 8 KHz Integrity) then I AM lobbying for "packet switch
> >service with 8 KHz integrity".
> >
> I agree. All packet-switched stuff has integrity. It's a data service.
Huh? Packet switched (i.e. X.25) _service_ has no 8 kHz integrity
(but once you unstuff the bits, the payload does have integrity).
8kHz integrity (as I understand it) is harmful on a bit-synchronous
HDLC link but necessary on a byte-syncronous HDLC link. And the ISDN
packet service (X.25) uses bit-synchronous HDLC.
David desJardins
> I don't understand. You say you do not know the problem is growing and
> you also mention "growing fraction of the traffic is UDP" and "the fraction
> of *total traffic* that ignores congestion controls is growing."
Repeating myself:
1. Some fraction of TCP traffic fails to obey congestion controls, but I
don't know whether this fraction is increasing or decreasing.
2. UDP traffic, as a fraction of total traffic, is known to be growing
rapidly. Much of this UDP traffic ignores TCP congestion control
protocols.
3. I don't have any data on the real effects of this amount of "bad"
traffic on Internet performance. Whatever the effect, though, common
sense dictates that increases as the fraction of "bad" traffic
increases.
> you don't know whether problems caused by such traffic are finally,
> after decades of false predictions, becoming significant?
I first posted in this thread a few days ago. If I'd realized that you
have some sort of grudge that goes back "decades" against the discussion
of Internet congestion protocols, I would have tried harder to avoid
stepping on your toes.
> How do you know your packets are being dropped in the backbone instead of
> near the endpoints?
It's easy to see packet loss rates for ICMP packets with traceroute and
ping. ICMP traffic isn't always handled the same way as TCP traffic,
but in many cases I can observe that ICMP packet loss occurs at one and
only one point in the route from me to my destination. Logic dictates
that that's where my TCP packets are being lost as well.
> Yes, each packet loss commonly causes an echo-hiccup of a multiple
> (typically 1) of the RTT. With modern Internet RTT's, I'm not sure such
> hiccups are significant.
With all due respect, I'm a better judge of what is "significant" for my
use than you are. Packet loss definitely has very significant effects
for me; otherwise I wouldn't be talking about it.
> First, your complaints aobut telnet/ssh packet loss are not about queuing
> delays, but packet loss. The usual use of IP TOS, at least in what I've
> seen and heard about, does not affect packet loss rates, but only queuing
> delays.
The "usual use" of IP TOS is to ignore it completely. I certainly do
agree that using IP TOS simply to reduce queing delays is minor. A more
important and significant use of IP TOS, in my view, is to reduce packet
loss rates for high-priority low-volume traffic. Because in my view and
experience, packet loss is generally a considerably more significant
problem than RTT times.
> Do you mean to say that if your telnet/ssh packets were effectively marked,
> they would have lower queuing delays, and so the effective RTT would be
> smaller, and so the echo-hiccup you see as the result of losses would be
> smaller?
No. I mean that if IP TOS were meaningful, then routers could recognize
it, and reduce packet loss for higher priority traffic, by dropping more
lower-priority traffic instead. The RTT effects of queueing order seem
irrelevant to me, for the same reasons that you mention.
> Second, the many reports about RED, fair-queuing, early congestion
> notification, and so forth contain promising concerning ideas for dealing
> with packet loss among unmarked or uniformly marked streams of packets,
> as well as fixing mismarked (i.e. 'abusive') streams or over-committed
> high-priority streams.
I think the likelihood of a core backbone router being able to
distinguish and specially handle my telnet stream (measured at perhaps a
few packets/second) is extremely remote. If you have just a few streams
sharing a particular link, sure, you can enforce policy amongst them.
But when you have thousands and thousands of different "streams" coming
and going all the time, such solutions are infeasible.
And, even if you can enforce policy among streams, deciding on policy
based solely on the characteristics of the streams is inherently
incapable of resolving the whole problem. How can such solutions
possibly tell the difference between my latency-sensitive stream, for
which I'm willing to pay a high premium for low packet loss, and a
latency-insensitive stream with the same parameters, which the user just
wants delivered at the lowest possible net cost?
David desJardins
Jeffrey Rhodes
>
> On Sat, 17 Oct 1998 18:16:50 -0400, Robert Blackshaw
> <blac...@erols.com> wrote:
>
> > Rhodes wrote:
>
> > > Does 8kHz Integrity mean "every bit the same, every byte continuous within a
> > > window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
> > > meaning of this term widely misinterpreted (wrt "the standards") such that a
> > > NEW voice bearercap would be able to express to the network EXACTLY what is
> > > desired for routing purposes?
> > >
> > Yes, there is no reason for the network to fiddle with the bits
> > unless it is a voice call from A-law to mu-law, in which case
> > a translation does happen.
> >
> Hi Bob,
> There is one good reason besides u-law to A-law conversion. That is,
> the call goes over an analog link. I suspect that the digital values
> on each of the codecs will be slightly different, due to the impedance
> of the copper.
Are you suggesting that the network reject a request for 3.1 kHz Audio,
but allow a request for Speech, in the event that all the network has
available are analog circuits? Not that there are any such analog trunks
present in the network anymore, but hypothethically an analog modem or
fax calling with Audio bearercap will be able to survive the analog
conversion. I expect Speech and Audio to both be able to use the analog
trunks, so this example seems to substantiate my claim that, in general,
the network routes both bearercap requests the same!
> There are some other, perhaps not so good, reasons for the network to
> fiddle with the bits. These are echo cancelers and enhancements (ie
> Truvoice).
Of course, these turn themselves off after a call is answered and a
modem or fax tone is present, so there is no special network routing
required for Speech or Audio bearercap requests.
> I maintain that, with speech, you cannot guarantee that the bytes will
> be the same on each end of the network. I believe that 8 kHz
> integrity means that you will not get a "bit slippage", so that you
> can transport a stream of bytes, not bits. (ie you always know which
> bit is the MSB).
I maintain that 3.1 kHz Audio effectively provides no such guarantee,
either, not even for the 7 MSBs of every byte! Shirley (;-) a VoIP call
using G-whatever vocoders will not preserve "bit integrity" nor is it
needed.
> -----------------------------------
> Hank Karl
> Opinions mine, not my company's
> to reply, remove the "imnothere" from my address
regards, jcr
Al Varney
Hank Karl <himnoth...@imnotherenlc.com> wrote:
>On Sat, 17 Oct 1998 18:16:50 -0400, Robert Blackshaw
><blac...@erols.com> wrote:
>> Rhodes wrote:
>>> Does 8kHz Integrity mean "every bit the same, every byte continuous within a
>>> window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
>>> meaning of this term widely misinterpreted (wrt "the standards") such that a
>>> NEW voice bearercap would be able to express to the network EXACTLY what is
>>> desired for routing purposes?
8kHz integrity means the user/network interface can identify boundaries
on an 8000 Hz (synchronous) basis. It has nothing to do with whether or not
the bits themselves are changed in transport. It does imply that, on 64K
B-channels, you aren't going to package things in variable-length "packets"
of odd-bit sizes, and expect the network to find the boundaries.
(For X.25 packet over B-channel, the "service data unit" is used, and I
believe this is also used for some ATM-based speech where the SDU is 48 bytes.)
>> Yes, there is no reason for the network to fiddle with the bits
>> unless it is a voice call from A-law to mu-law, in which case
>> a translation does happen.
>Hi Bob,
>There is one good reason besides u-law to A-law conversion. That is,
>the call goes over an analog link. I suspect that the digital values
>on each of the codecs will be slightly different, due to the impedance
>of the copper.
>There are some other, perhaps not so good, reasons for the network to
>fiddle with the bits. These are echo cancelers and enhancements (ie
>Truvoice).
There are, in I.340, three connection types specified:
-Unrestricted digital means no part of the connection by contain active
speech processing or echo suppression functions, nor may it perform
A-law/mu-law conversion
-3.1 kHz Audio may contain echo suppression functions, and must perform
A-law/mu-law conversion where appropriate.
-Speech may contain echo suppression functions and speech processing functions,
and must perform A-law/mu-law conversion where appropriate.
Both Speech and 3.1 kHz audio can pass over analog facilities. Speech,
but not 3.1 kHz Audio, can be processed to minimize facility usage (over
trans-oceanic links, for example).
In general, the network can manipulate bits (except for Unrestricted
Digital) that are presented to it as G.711 PCM encoded octets in any manner
designed to enhance voice communication (Speech) or voice/voice-band data
communication (3.1 kHz Audio).
Al Varney - just my opinion
Amanda Walker
>1. Some fraction of TCP traffic fails to obey congestion controls, but I
> don't know whether this fraction is increasing or decreasing.
>2. UDP traffic, as a fraction of total traffic, is known to be growing
> rapidly. Much of this UDP traffic ignores TCP congestion control
> protocols.
Most TCP congestion control isn't handled by protocols per se, it's
implemented by TCP implementations (usually via a feedback mechanism
into the retransmission timing algorithm). Now, it is true that
UDP handling generally doesn't even go this far, though a certain
amount of it (streaming audio & video in particular) does do at
least rudimentary congestion control of it own.
Also, routers are starting to play a more active role in congestion
control, with developments like random early detection and class based
queuing, which avoid the "pumping" effects of a simple fixed-length
FIFO. If this becomes widely deployed, the only person a "misbehaving"
TCP/IP stack will annoy is the person using it.
>3. I don't have any data on the real effects of this amount of "bad"
> traffic on Internet performance. Whatever the effect, though, common
> sense dictates that increases as the fraction of "bad" traffic
> increases.
Common sense isn't always as simple as it looks, and large ISPs are
not simply dumping packets from one FIFO to another any more. These
days, I suspect it's as likely that congestion is cause at the local
router at one end or another than across an ISP backbone. Interconnection
points (such as MAE-EAST) are an exception, but these are being bypassed
more and more by bilateral interconnects between ISPs.
>I think the likelihood of a core backbone router being able to
>distinguish and specially handle my telnet stream (measured at perhaps a
>few packets/second) is extremely remote.
I don't, and I think the likelihood will grow as time goes on, for a
variety of reasons.
Amanda Walker
Robert Blackshaw
>
> On Sat, 17 Oct 1998 18:16:50 -0400, Robert Blackshaw
> <blac...@erols.com> wrote:
>
> > Rhodes wrote:
>
> > > Does 8kHz Integrity mean "every bit the same, every byte continuous within a
> > > window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
> > > meaning of this term widely misinterpreted (wrt "the standards") such that a
> > > NEW voice bearercap would be able to express to the network EXACTLY what is
> > > desired for routing purposes?
> > >
> > unless it is a voice call from A-law to mu-law, in which case
> > a translation does happen.
> >
> Hi Bob,
> There is one good reason besides u-law to A-law conversion. That is,
> the call goes over an analog link. I suspect that the digital values
> on each of the codecs will be slightly different, due to the impedance
> of the copper.
>
> There are some other, perhaps not so good, reasons for the network to
> fiddle with the bits. These are echo cancelers and enhancements (ie
> Truvoice).
>
> be the same on each end of the network. I believe that 8 kHz
> integrity means that you will not get a "bit slippage", so that you
> can transport a stream of bytes, not bits. (ie you always know which
> bit is the MSB).
>
rather imagining (hoping) all the FDM systems were history.
K-Carrier anyone?
Robert Blackshaw
> >On Sat, 17 Oct 1998 18:16:50 -0400, Robert Blackshaw
> ><blac...@erols.com> wrote:
> >> Rhodes wrote:
> >>> Does 8kHz Integrity mean "every bit the same, every byte continuous within a
> >>> window of latency", aka end-to-end, user-to-user "bit integrity", or, is the
> >>> meaning of this term widely misinterpreted (wrt "the standards") such that a
> >>> NEW voice bearercap would be able to express to the network EXACTLY what is
> >>> desired for routing purposes?
>
> on an 8000 Hz (synchronous) basis. It has nothing to do with whether or not
> the bits themselves are changed in transport. It does imply that, on 64K
> B-channels, you aren't going to package things in variable-length "packets"
> of odd-bit sizes, and expect the network to find the boundaries.
>
> (For X.25 packet over B-channel, the "service data unit" is used, and I
> believe this is also used for some ATM-based speech where the SDU is 48 bytes.)
>
> >> unless it is a voice call from A-law to mu-law, in which case
> >> a translation does happen.
>
> >Hi Bob,
> >There is one good reason besides u-law to A-law conversion. That is,
> >the call goes over an analog link. I suspect that the digital values
> >on each of the codecs will be slightly different, due to the impedance
> >of the copper.
>
> >There are some other, perhaps not so good, reasons for the network to
> >fiddle with the bits. These are echo cancelers and enhancements (ie
> >Truvoice).
>
> -Unrestricted digital means no part of the connection by contain active
> speech processing or echo suppression functions, nor may it perform
> A-law/mu-law conversion
> -3.1 kHz Audio may contain echo suppression functions, and must perform
> A-law/mu-law conversion where appropriate.
> -Speech may contain echo suppression functions and speech processing functions,
> and must perform A-law/mu-law conversion where appropriate.
>
> Both Speech and 3.1 kHz audio can pass over analog facilities. Speech,
> but not 3.1 kHz Audio, can be processed to minimize facility usage (over
> trans-oceanic links, for example).
>
> In general, the network can manipulate bits (except for Unrestricted
> Digital) that are presented to it as G.711 PCM encoded octets in any manner
> designed to enhance voice communication (Speech) or voice/voice-band data
> communication (3.1 kHz Audio).
>
case where a user was sending modem signals across ISDN. If it is done
by the carrier in such a manner that the user can (sucessfully) send
33.6 modem traffic through the network, it meets the requirement.
Robert Blackshaw
>
> On 18 Oct 1998 02:09:11 GMT, lma...@vnet.ibm.com (Laurence V. Marks)
> wrote:
>
> > In <708l78$4gi$1...@nnrp1.dejanews.com>, jcrh...@my-dejanews.com writes:
> > >Hey, Laurence, I'm over here. Did you see the posting I tried to send to you
> > >that relays that "No, my newsadmin is NOT blocking the 'ibm.com' domain".
> > >Claircom gets a newsfeed from Northwest NEXUS, so maybe they have a problem
> > >with spam from IBM?
> > >
> > I think I'm seeing all your posts, Jeffrey. At least I don't think there
> > were any quoted ones where I didn't also see the original.
> >
> > I usually only read the ng once a week these days, which means you may
> > think I'm not responding--and sometimes I have nothing interesting to say.
> > (Say, you don't suppose I'm in the killfile on the machine you use to read
> > Claircom, do you? Try rm .killfile .)
> >
> > >"8 KHz integrity" (do the new standards use 8 kHz, like they do for bearcap
> > >specification of 3.1 kHz and 7 kHz Audio, or is there something subtle going
> > >on with KHz?) must mean alot of different things to different standards
> > >people.
> > >
> > Nobody seems to know the real intent of 64K UDI with tones/announcements.
> > I thought it was going to be used when an ISDN-originated call got lost in
> > POTS-land, and the tape said, "beep BEEP BEEEEP. The number you have
> > called is not in service. Please be sure you are dialing the correct
> > number." directed to your 64K data terminal. I have seen this happen.
> >
> > But some text Hank Karl posted implied that this was not how it was to be
> I'm only speculating here, I'm not on the ITU, nor do I work for a
> carrier or LEC :-) But I think the meaning of the BC was expanded so
> that you could send other compressions than 7kHz. After all, the
> network is not going to decode them. Also, you do need to get the
> tones and announcements, the intention is that there is a user there.
>
> Previously, you had 7 kHz audio on this BC. I think you still can,
> but you can also have other compressions. How it was to be used and
> how you use it are two different things (DOV is one example). One
> question is "what service do you get for this BC"? But I think the
> real key is "what does your endpoint TE do when it gets this BC? Does
> it assume voice, compressed voice, data, or what?
>
believe
I've covered this in the Guide but until Tom gets the conversion done I
doubt that will help anyone. Right at the moment I'm up to my a** in
alligators, but the money is nice. :-). This assignment could turn
permanent.