[Foip] V.152 VBD; RE: Updated Problem Statement

[Steve Underwood]

Hi Paul,

I was probably wrong to call V.152 a joke. Its not a joke for carriers. 
Its only a joke for ordinary users, for two reasons - packet loss and 
timing accuracy.

I think most of the advocates of V.152 are carriers. Their concept of 
"end-to-end" is a controlled environment between ingress and egress PSTN 
gateway. Those gateways connect to the PSTN through something between a 
T1 and and OC192, all of which get their timing from the PSTN, which is 
Rubidium sourced, and highly predictable. The sample rate going in at 
the ingress gateway will be sure to match the sample rate at the egress 
gateway to high precision. The network is under their mamagement and can 
consistently keep the packet loss close to zero. The only problem these 
people had pre-V.152 was ensuring consistent signaling, to get the FAX 
calls into a suitable configuration.

Compare this to the more general VoIP case, of two ATAs, in two people's 
homes, try to talk through the Internet. The sampling clocks in the ATAs 
are not so accurate, and this can create issues. With voice calls crude 
adjustments occur to compensate for this, but during a modem call things 
are more difficult. FAX calls, being non-duplex, can be fudged by 
waiting for a silence, and inserting or dropping a sample. V.152 is 
advocated for general modem over IP operation, though, where sample 
insertion or deletion just won't work - it would completely scramble the 
training of both the modem's receiver and its echo canceller.

I have run numerous test calls across the globe lasting several days 
each, without a single lost packet, or period of significant jitter. 
Great, but is this the general case? Carriers love to tell us how few 
packets are lost on their backbones, and the figures they quote are most 
impressive, and no doubt honest and accurate. There is a reason why they 
like to quote backbone figures, though. Results end to end are far more 
variable. This is due to a combination of things. The tributaries 
average their loads less effectively, due to their smaller size, and the 
switching equipment in the tributaries is far more variable. The only 
thing relevant to a user is end-to-end packet loss, where considerations 
down to their own LANs are very important, and very variable. I'd say 
the basic problem is we are trying to send huge floods of tiny little 
media packets across an IP landscape which has been optimised for file 
transfer. As an example, Gigabit Ethernet introduced bigger packets, and 
its very hard to get good performance unless you actually use those 
bigger packets. Most Gigabit Ethernet switches choke at the packet rates 
needed for VoIP, yet perform extremely well for file transfers.

People usually make the assumption that two computers connected through 
an ethernet switch will have zero packet loss between them unless the 
load is very. This turns out to be a poor assumption. Lets take a look 
at a widely used VoIP type application which does exactly this. There is 
a FAXing solution for the Asterisk open source PBX, which consists of an 
IP based FAX modem called iaxmodem, and the popular FAX server HylaFAX. 
Asterisk and iaxmodem obviously need an IP connection free of packet 
loss, just like VBD, so just how often does that work out OK? Well, 
people almost always connect Asterisk and iaxmodem between two ports of 
the same Ethernet switch, and the results turn out to be quite variable. 
Many people can send a hundred concurrent FAXes without a hiccup, will 
others have endless trouble with very small loads. The trouble usually 
goes away if they connect the two computers directly, by a crossover 
ethernet cable. Therefore, the ethernet switches seem to be the main 
cause of dropped packets. However, we are not talking about obscure 
switches of unknown origin, or high load conditions. Many popular 
products from recognised brands, on LANs with modest levels of traffic, 
have been seen to loose FAX audio packets across a LAN.

I think we can all point to cases where we've seen impressively good 
results across the Internet, but a system design has to work to 
something closer to the worst case. The worst case with an IP network 
approaches infinitely bad, so working to the actual worst cases is 
simply meaningless. I think any sane telephony over IP solution has to 
work for at least the majority of the cases in G.1050, though. People 
with Internet connections considered generally pretty good have days of 
zero loss, and days of significant bursty loss. Telephony is expected to 
work for them every day. V.152 won't.

Steve

Paul E. Jones wrote:
> Steve,
>
> My apologizes for not responding to your original comment.  It appears the
> message transmitted on June 2 got failed to deliver due to the gray listing
> we run on our mail server.
>
> In any case, I do mentioned V.152 from time to time for a few reasons:
> 1) I have been told by some manufacturers (who are working with various
> carriers) that they fully intend to use V.152, citing the fact that, while
> it consumes bandwidth, it serves to address a lot of the issues seen with
> fax, modem, TTY, security alarm systems, and so forth.
> 2) I have been told by some carriers that their networks are nearly lossless
> and so pristine that V.152 works just fine and, likewise, they have no
> desire to do anything else.
>
> Those were statements made to me (or to the group of folks at the ITU, TIA,
> or elsewhere) during the time that V.152 was being drafted.  Whether the
> sentiments have changed since V.152 was drafted, I do not know.
>
> Within the bounds of a single carrier, I do fully believe it is possible to
> have a near-lossless network.  I monitor traffic on my home cable network
> (which offers no guarantees whatsoever), I have nearly a 0% packet loss when
> communicating between any two points inside the US at almost all times of
> the day.  That's also true when going between my home and Singapore most of
> the time.  I often see 5% packet loss between my home and Beijing, though.
>
> If a carrier wishes to build a reliable VoIP network, it is doable.  V.152
> would be a workable solution is well-engineered VoIP networks, like the ones
> I was told exist when V.152 was drafted and even within the realm of my own
> service provider (which is not just providing voice).  The issue, of course,
> is that not all calls are terminated on the same provider's network and SLAs
> do not exist everywhere.  In those cases, there must either be some kind of
> SLA in place or one will have to employ something else (e.g., V.150.x,
> V.151, V.152, T.38).
>
> The bottom line is that I don't think V.152 is a joke, no.  It is
> essentially G.711, but signaled as VBD.  As such, a service provider could
> allow its use within its network, but then have an SBC strip out that
> capability as calls leave its network.  Doing that would allow for the use
> of VBD in its network and then force T.38 otherwise. (That's just one
> possible scenario.)  The advantages of doing that might be that proprietary
> fax machine features might work, etc.  It might also prove to be more
> reliable:  we cannot argue with that possibility, since we have this WG
> formed specifically because there are deployment issues with T.38.
>
> I'm not trying to build a case of V.152, mind you.  I'm merely trying to
> expand on why I made those comments.  V.152 might be a good addition to T.38
> where it can be successfully used (i.e., pristine networks).  Or, it might
> even be preferred end-to-end, not just for the benefit of fax, but for all
> of the various modulated signaling protocols out there.  I've spent a lot of
> time with folks working on accessibility issues and they're also concerned
> about TTY transmission: a lost packet there can result in the lost of a
> character or two, and that can have deadly consequences when calling
> emergency numbers.  V.151 might fix that, but discriminating between all of
> the various TTY devices in the world, fax devices, modems, and everything
> else is not trivial.
>
> V.152 is definitely easier to implement on a gateway, as tone detection
> (without tone discrimination) is a far simpler problem to solve.
> Over-provisioning the VoIP network is also fairly simple and several
> engineers at one major service provider told me without hesitation that it
> was a heck of a lot cheaper to throw more bandwidth into the network core
> than it was to pay staff to try to fine-tune everything to the nth degree.
> If a carrier has that kind of attitude, I doubt V.152 would present them
> with the least bit of concern.
>
> Paul
>
>   
>> -----Original Message-----
>> From: Schwarz Albrecht [mailto:Albrecht.Schwarz at alcatel-lucent.de]
>> Sent: Friday, June 05, 2009 10:28 AM
>> To: Steve Underwood; Paul E. Jones
>> Cc: foip at sipforum.org
>> Subject: V.152 VBD; RE: [Foip] Updated Problem Statement
>>
>> Dear All!
>>
>> The biggest advantage of V.152 VBDoIP is the *explicit* method to
>> indicate (or negotiate) with the remote gateway the VBD service due to
>> dedicated SDP information elements.
>> This is not possible with non-V.152 VBD ("G.711 pass-through"; aka
>> pseudo-VBD, pVBD).
>>
>> The lacking signalling capabilities for pVBD is one of the observations
>> made in ETSI TISPAN concerning interoperability problems for "PSTN modem
>> calls".
>>
>> I'm not commenting any user plane aspects of T.38 or V.152, but we
>> definetely need explicit indication and negotion means in the signalling
>> plane (in order to minimize the probability of different settings in
>> both gateways).
>> See also attached TISPAN doc.
>>
>> Albrecht
>>
>>
>>
>>     
>>> -----Original Message-----
>>> From: foip-bounces at sipforum.org
>>> [mailto:foip-bounces at sipforum.org] On Behalf Of Steve Underwood
>>> Sent: Dienstag, 2. Juni 2009 18:33
>>> To: Paul E. Jones
>>> Cc: foip at sipforum.org
>>> Subject: Re: [Foip] Updated Problem Statement
>>>
>>> Hi Paul,
>>>
>>> Paul E. Jones wrote:
>>>       
>>>> Mike,
>>>>
>>>> Please find my comments and questions in the revision marks.
>>>>
>>>> Paul
>>>>
>>>>         
>>> You have made a reference to VBD, and several others here
>>> have too. Do you believe V.152 is anything but a joke put
>>> together during a really heavy drinking session? Look at its
>>> ground rules. They basically say there is an assumption of a
>>> perfectly clean channel. VBD seems little more than saying
>>> use ulaw/alaw, and adding redundancy might be a good idea.
>>>
>>> Steve
>>>
>>> _______________________________________________
>>> FoIP mailing list
>>> FoIP at sipforum.org
>>> http://sipforum.org/mailman/listinfo/foip
>>>
>>>       
>
>