[SIPForum-techwg] FW: Clarification regards modem passthrough with reference to IP PBX / Service provider Interoperability

[Tom-PT Taylor]

Just to stir the pot a little, the appropriate references are now RFCs 4733 and
4734 rather than RFC 2833. If using the RFC 4734 events, you would send the ANS
event (code 32) when 2100 Hz is first detected, and the /ANS event (code 33)
when phase reversal is detected.

Chris Gatch wrote:
> 
> 
> 1. If upon the detection of 2100 Hz tone if the system switches to g.711
> codec after initiating a reINVITE, what is to be done upon the reception of
> Phase reversal on the terminating side?
> 
> 
> 
> The originating side needs to receive the phase reversal such that echo
> cancellers can be disabled. This means that the terminating gateway needs to
> pass this information along.
> 
> 
> 
> If NTE (RFC2833) had been negotiated in the original session, the phase
> reversal can be sent as an NTE event to the originating side. It seems this
> would be independent of the reINVITE (for G.711 negotiation) meaning the
> event could be sent prior to the session being renegotiated for G.711. This
> also implies that the originating gateway must be capable of not only
> translating the NTE event back to the 2100 Hz tone on the TDM side but also
> acting on the event and disabling any active echo cancellation for the
> session.
> 
> 
> 
> If NTE had not been negotiated on the original session, then the 2100 Hz tone
> with phase reversal needs to be transmitted inband (in the voice codec).
> Assuming the original session is not using G.711, the tone will not be
> reliable until the reINVITE renegotiates with the G.711 codec. It is possible
> / likely that the originating side will not detect the 2100 Hz tone until
> G.711 is in use. It is reasonable that the G.711 negotiation would occur well
> in advance of the ceasing of the 2100 Hz tone (with or without phase
> reversal) by the terminating station.
> 
> 
> 
> 2. How do we indicate to the remote gateway as regards the phase reversal?
> 
> 
> 
> Answered in 1. Via NTE events if NTE is negotiated. Inband via G.711 once
> session is renegotiated for G.711.
> 
> 
> 
> 3. Do we disable ECAN upon receiving the phase reversal signal or how is it?
> 
> 
> 
> Yes.
> 
> 
> 
> 4. In the SIP re-INVITE, how do we specify whether it is a fax call or a
> modem call?
> 
> 
> 
> The concept of the "inband method" is that gateways are unaware the session
> is being used for fax transport. I know of no way to indicate fax for this
> method. Alternatively, if using T.38, then the negotiation of T.38 would
> indicate fax usage. Is there a reason that SIP would need to indicate fax or
> modem call if all it is doing is G.711?
> 
> 
> 
> From: Binod Roay (broay) [mailto:broay at cisco.com] Sent: Tuesday, April 10,
> 2007 11:53 AM To: Chris Sibley; Chris Gatch Subject: Clarification regards
> modem passthrough with reference to IP PBX / Service provider
> Interoperability
> 
> 
> 
> Hi Chris,
> 
> 
> 
> I am Binod Roay working with Cisco Systems. We are trying to implement the
> modem passthrough to be compliant with the SIP forum draft in this regard.
> 
> I had some doubts as regards the document
> sf-draft-twg-IP-PBX_SP_Interop-sibley-siipconnect  in the sip forum.
> 
> The doubt is as regards section 15.5 of that document. Please direct me to
> the appropriate person in case you aren't the ones who created this section.
> 
> 
> 
> 
> 
> 15.5 Fax and Modem Calls When performing in-band transport of fax or modem
> calls, any device that supports fax and/or modem transmissions MUST upon
> recognition of a 2100 Hz tone (+/- 15 Hz) tone: 1. Switch the active codec in
> use on the call to G.711 (if a codec other than G.711 was previously in use).
>  2. Disable the high pass filter. 3. Disable voice activity detection (VAD)
> and comfort noise generation (CNG). 4. Switch from any adaptive/dynamic
> jitter buffer in use to a fixed-length jitter buffer. (A RECOMMENDED depth of
> 200-ms is suggested when switching to a fixed-length jitter buffer.)
> 
> 
> Renegotiation of the session media attributes MUST be performed using the SIP
> reINVITE request as described in RFC 3261 [8] or the SIP UPDATE request as
> described in RFC 3311 [12]. Superior performance of fax transmissions over
> packet networks can be achieved by utilizing the ITU-T T.38 [22] fax relay
> specification (as opposed to in-band transport). In-band fax transmissions
> are especially problematic over packet networks, especially for calls that
> traverse the public Internet or other network that doesn't offer adequate
> QOS. Accordingly, it is RECOMMENDED that Enterprise devices utilize T.38 fax
> relay when possible. Trunking Gateways MUST support the ITU-T T.38 [22]
> specification and Enterprise devices SHOULD support the specification. It is
> important to note that steps 1-4 outlined above for in-band transport of
> fax/modem calls do not apply, to fax calls only, for implementations
> utilizing T.38 fax relay.
> 
> 
> 
> Questions
> 
> 
> 
> 
> 
> 1. If upon the detection of 2100 Hz tone if the system switches to g.711
> codec after initiating a reINVITE, what is to be done upon the reception of
> Phase reversal on the terminating side?
> 
> 2. How do we indicate to the remote gateway as regards the phase reversal
> 
> 3. Do we disable ECAN upon receiving the phase reversal signal or how is it ?
> 
> 
> 4. In the SIP re-INVITE, how do we specifiy whether it is a fax call or a
> modem call ?
> 
> 
> Low-speed modems (V.22bis and below) and faxes work with echo cancellers in
> place, and so for these connections the echo canceller should be active.
> High-speed modems disable the PSTN echo cancellers by adding phase reversals
> to their answer tones. The PSTN network detects these phase shifts, and are
> aware that the echo cancellers must be disabled. In a voice over packet
> situation, the same information needs to be used to disable the echo
> canceller.
> 
> 
> 
> 
> 
> Could you please provide your inputs ?
> 
> 
> 
> Thanks and regards,
> 
> Binod
> 
> 
> 
> 
> 
> ________________________________
> 
> This email may contain confidential information. If you are not the intended
> recipient, please advise by return email and delete immediately without
> reading or forwarding to others. -- Cbeyond
> 
> ________________________________
> 
>