[Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.

Wed Jun 24 16:56:33 EDT 2009

Hi, Chris,

It is true that for V.17 sessions, the T.38 SIP negotiations are mostly initiated by the receiving GWs upon the detection of V.21 preambles. For V.34 FoIP, with the consideration of possible MoIP in the system, intercepting of V.8 CM messages may be a better way to confirm a fax session.

Regarding the negotiation between V.34 emitting GW and V.17 receiving GW, there should be no failure. If the emitting GW advertises version 3, the receiving GW can response with a lower T.38 version if it does not support version 3. My understanding is that the version number that a GW sends out represnts the highest version it can support. It also means that it must support any version that is lower than it advertised.

Regards,

Michael
________________________________
From: foip-bounces at sipforum.org [foip-bounces at sipforum.org] On Behalf Of Wang, Chris [cwang at sonusnet.com]
Sent: Wednesday, June 24, 2009 12:58 PM
To: foip at sipforum.org
Subject: Re: [Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.

Hi Michael,

Thanks for the clarifications.

Regarding T38MaxBitRate attribute (first defined by T.38 Amd2), it was designed to be used for purpose of bandwidth allocation considerations only.  Using it to infer the modulation type is probably undesirable as it might lead to guessing, since multiple modulations share same bit rates.  Although Gerard’s suggestion of using T38FaxVersion is viable, but most of the implementations in the field still declare version 0 to allow wider interoperability.

There is also the question of which GW should initiate the negotiation.  Mule and Li’s draft recommended the fax detection should be tasked to the receiving GW, hence be the initiator of the negotiation.  This draft although never got ratified into a standard track RFC, but it is widely used and implemented.  Thus, if we want to let the emitting GW initiate the negotiations upon intercepting valid CM messages, we need to clearly state that this is only for a particular type of call flow, but not applicable to others (eg, non V.8 cases).  One danger here is the negotiation between a V.34 emitting GW and V.17 receiving GW would likely lead to failure (ie, SIP 488 response) because of T38FaxVersion being set to 3 and rejected by receiving GW.

Best regards,

Chris Wang
Sonus Networks

________________________________
From: gboulay.ext at orange-ftgroup.com [mailto:gboulay.ext at orange-ftgroup.com]
Sent: Wednesday, June 24, 2009 4:18 AM
To: Michael.Chen at lsi.com; Wang, Chris; foip at sipforum.org
Subject: RE: [Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.

Hi,
Concerning the first point, it seems to me that the best way to know, during the T.38 negotiation,  if a GW manages 14400 b/s rate in V.17 or V.34 is to look at the version parameter sent in the T38 parameters of the T.38 SIP negotiation. If it is version 3, it is V.34, otherwise for lower versions, it is V.17. And if the parameter is absent, the defaut value is 0.

Gerard

________________________________
De : foip-bounces at sipforum.org [mailto:foip-bounces at sipforum.org] De la part de Chen, Ximing M (Michael)
Envoyé : mardi 23 juin 2009 22:01
À : Wang, Chris; foip at sipforum.org
Objet : Re: [Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.
Hi, Chris,

Please see my following comments to your questions. I agree that we still need to sort out a few things.

1. "For Study Case #2, how would Emitting GW determine it only support G3?  Is it via some prior signaling with Receiving GW?"

The emitting GW knows the other GW's capabilities via SIP/SDP negotiation for T.38. The question are when such a negotiation should start, and which GW should initiate the negotiation. In this particular case, the emitting GW can start the SIP/SDP negotiation for T.38 after V.8 CM is received from the local fax machine. One problem with the negotiation is that in T.38 only the maximum data rate (not modulation type) is included in negotiation parameters. So if both sides agrees on 14400 bps, does it mean V.17 14400 or V.34 14400? My guess is that people may simply assume G3 fax if the max rate is less than (and equal to )14400, but V.34 does support the data rate all the way to 2400 bps.

2. "Does the Receiving GW need to jam/stop the CM from reaching answering FD?"

Most T.38/V.17 GWs do not have capability to detect V.8 CM. It probably makes more sense to let the emitting GW to jam the CM in this case.

3. "How would answering FD fallback to G3 gracefully?  By timing out or somehow receiving a modified CM with V.34 modulation capability removed in modn0 octet?"

The answering FD will fallback to G3 if CM is not detected. If the answering FD does not detect valid CMs during ANSam (~5 s), it will switch to G3 and start to generate v.21 preambles.

Regards,
Michael
________________________________
From: foip-bounces at sipforum.org [foip-bounces at sipforum.org] On Behalf Of Wang, Chris [cwang at sonusnet.com]
Sent: Tuesday, June 23, 2009 11:41 AM
To: foip at sipforum.org
Subject: Re: [Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.
A few comments/questions regarding V8-V34-V152 document.

For Study Case #2, how would Emitting GW determine it only support G3?  Is it via some prior signaling with Receiving GW?

Does the Receiving GW need to jam/stop the CM from reaching answering FD?

How would answering FD fallback to G3 gracefully?  By timing out or somehow receiving a modified CM with V.34 modulation capability removed in modn0 octet?

Best regards,

Chris Wang
Sonus Networks

________________________________
From: foip-bounces at sipforum.org [mailto:foip-bounces at sipforum.org] On Behalf Of Chen, Ximing M (Michael)
Sent: Monday, June 22, 2009 10:46 PM
To: Neil Weldon; foip at sipforum.org
Subject: [Foip] FoIP-TG: Issues with V.8/V.34/V.152 call flows.

Hi all,

Instead of looking into the call flows for all possible system/network configurations (which will be many), it  probably makes more sense for us  to concentrate on a few cases where clarification/guidance is needed from TG. Attached are brief descriptions of two possible cases.  Both of them are related to fallbacks from V.34 to V.17, which are not specified in T.38.  Please  comment  on these two cases and/or add any other cases that you think TG should look into and provide recommendations.

Regards,

Michael
________________________________
From: foip-bounces at sipforum.org [foip-bounces at sipforum.org] On Behalf Of Neil Weldon [Neil.Weldon at dialogic.com]
Sent: Thursday, June 18, 2009 5:41 AM
To: foip at sipforum.org
Subject: [Foip] June 17th Meeting Minutes.
Hi all,

Minutes from yesterday are attached.  I’ll follow-up with the updated Problem statement.

Next meeting will be called by Michael Chen, via this list. Please ensure you review material that Michael will provide over the coming weeks so we can gather some momentum for dealing with the identified problems.

Regards,

Neil

Neil Weldon
Director of Technology
CTO Office

Dialogic Distribution Limited
4034 Kingswood Avenue
Citywest Business Campus
Saggart, Co. Dublin
IRELAND
Tel:       +353 1 630 9000 ext 231
Fax:      +353 1 630 9099
Email:   neil.weldon at dialogic.com<mailto:neil.weldon at dialogic.com>
Web:    www.dialogic.com<http://www.dialogic.com>

Dialogic Distribution Ltd., a limited company.  Registered in Dublin, Ireland, registration #201976 with a registered office at Riverside One, Sir John Rogerson’s Quay, Dublin 2 Ireland.

This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/foip/attachments/20090624/013100b9/attachment-0001.html 