Subject: RE: [Megaco] T.38 MGC Transitioning Method

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 4 Oct 2005 00:41:10 -0400

One would build alternative session descriptions and utilize the
ReserveGroup property to have the MG prepare for the use of either
stream.  Each m= line would have to appear in its own v= section, per
H.248.1 clause 7.1.8.

Note that setting the port to 0 is a common way of indicating a LACK of
support.  That doesn't seem constructive here.

If there is an SDP interworking problem between SIP and H.248, then an
intermediary would have to step in to perform the translation between
SIP SDP and H.248 SDP.  Generally, this would fall upon the MGC.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, September 21, 2005 12:41 PM
To: [email-masked]
Subject: [Megaco] T.38 MGC Transitioning Method

How are people using SDP to advertise support for T.38oUDPTL as a latent
capability (the UDPTL port is not active) in conjunction with the MGC
Transitioning Method of T.38 (04/2004)? With the example call flow in
Appendix III.2.1, the Media Gateway does not advertise support for T.38
at the time the call is established. Step 4 hints that a second session
description with the T.38 port set to zero COULD be used,

	m=image 0 udptl t38

However, this is not required and wouldn't seem to play well in terms of
H.248-SIP interworking.

Has anyone leveraged RFC 3407 syntax in conjunction with H.248,

        m=audio 3456 RTP/AVP 0  
        a=sqn: 0  
        a=cdsc: 1 audio RTP/AVP 0
        a=cdsc: 2 image udptl t38  

Joe Stone

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Joe Stone \(joestone\)" <[email-masked]>
Date: Tue, 4 Oct 2005 09:06:39 -0700

> stream.  Each m= line would have to appear in its own v= section, per

This does not involve having the MG prepare to use either stream. That
would be analogous to the T.38 Autonomous Transitioning Method. In the
case of the T.38 Autonomous Transitioning Method, the MG would return
two session descriptions each with a non-zero port (i.e., both the RTP
and UDPTL ports are active). I had posed the question regarding how
support for T.38 as a latent capability (i.e., the UDPTL port is not
active) is advertised with the T.38 MGC Transitioning Method. With the
T.38 MGC Transitioning Method, the MGC must explicitly instruct the MG
to switch from one transport to the other. There's no need for the MG to
prepare to use the UDPTL stream. 

> support.  That doesn't seem constructive here.

I agree, however, this is allowed by the T.38 standard and groups within
the industry have latched onto this "loophole" and made it an integral
part of their solution. 

> SIP SDP and H.248 SDP.  Generally, this would fall upon the MGC.

I don't disagree, but if we can agree on common strategies across
multiple SDP-based control protocols (Megaco/H.248, MGCP, SIP, ...) we
can minimize the interworking requirements on the MGC. At the least, we
can avoid strategies with known conflicts (such as the use of port zero
to advertise a latent capability).

This brings me back to the use of RFC 3407 syntax and T.38. I take it
that no one is currently leveraging RFC 3407 syntax to advertise T.38 as
a latent capability in conjunction with Megaco/H.248. Does anyone see
this as a good idea? A really bad idea? In case you're not familiar with
RFC 3407 syntax, it's of the form (refer to the last three lines),

        v=0  
        o=- 25678 753849 IN IP4 128.96.41.2 
        s=-  
        c=IN IP4 128.96.41.2 
        t=0 0  
        m=audio 1296 RTP/AVP 18 96 97
        a=rtpmap:96 RED/8000
        a=fmtp:96 97/97
        a=rtpmap:97 PCMU/8000
        a=gpmd:97 vbd=yes
      > a=sqn: 0  
      > a=cdsc: 1 audio RTP/AVP 18 96 97
      > a=cdsc: 4 image udptl t38

This is an example with G.729 as the audio codec and G.711u as the VBD
codec with a single level of redundancy per RFC 2198. If both MGs were
to advertise support for T.38 as a latent capability at the time the
call was established, the MGC would instruct the MGs to switch to T.38
upon being notified of the fax stimulus. If one MG or the other failed
to advertise T.38 as a latent capability, the MGs would autonomously
switch to VBD mode upon detecting the fax stimulus (assuming that V.152
was successfully negotiated).

Joe Stone