Subject: [Megaco] T.38 session name in examples

From: "RUIKAR RAHUL A" <[email-masked]>
Date: Sun, 11 May 2008 12:07:19 +0200

Just an observation about ITU-T Rec. T.38 (09/2005)
according to SIP RFC "s" line in SIP messages is mandatory, it is
missing in examples 
given in document. 
Though for H248 this attribute is optional but for messages
sent/received from/to SIP agent 
shall have session name attribute present.

Regards,
Rahul Ruikar
Alcatel-Lucent
Email: [email-masked]
Alcanet: 2721 4732
 
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 12 May 2008 17:07:55 -0400

This misconception continues to pervade, and it is worrisome.
 
The s= line (and other mandatory portions of the SDP specification) are
*NOT* optional in H.248.  They are only optional in the MGC->MG
direction.  In communications from the MG to the MGC, the SDP must be
conformant to RFC 2327.  
 
The text in Clause 7.1.8 is explicit that the exceptions to SDP are
valid only in the MGC->MG direction.  This is to allow the MGC to
provide over- or under-specified SDP.
 
Kevin

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of RUIKAR RAHUL A
Sent: Sunday, May 11, 2008 6:07 AM
To: [email-masked]
Cc: Schwarz Albrecht
Subject: [Megaco] T.38 session name in examples

Regards,
Rahul Ruikar
Alcatel-Lucent

---

From: "RUIKAR RAHUL A" <[email-masked]>
Date: Tue, 13 May 2008 05:09:32 +0200

Thanks for explanation.if "s" line is optional only in MGC->MG direction
and not in MG->MGC
but then I see that those attributes ( o,s,t ) are missing in reply from
gateway. 
Now I have following doubt regarding this,
1) Should MG send RFC 2327 conformant SDP to MGC in reply ( eg. adding
missing o,s,t lines )
2) or is it MGC which has to manage these missing attribute and add it
to SDP which is to be sent out to remote side.

Example From Page No. 78 and 79
 
MGC to MG1:
====================
MEGACO/1.0 [123.123.123.4]:55555
Transaction = 11 {
Context = $ {
Add = DS0/1/1 {
Events = 1 {al/on, ctyp/dtone }
}, ; SCN termination prepared to listen for tones
Add = $ {
Media {
Stream = 1 {
LocalControl { Mode = ReceiveOnly, ReserveGroup = True, ReserveValue =
True},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 18 0
v=0
c=IN IP4 $
m=image $ udptl t38
}; IP termination for audio } }}}}

Reply from MG1 -> MGC
=====================
 
MEGACO/1.0 [124.124.124.222]:55555
Reply = 11 {
Context = 2000 {
Add = DS0/1/1, ; SCN termination added
Add = RTP/1 {
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 18 0 ;MG1 supports both offered codecs
a=ptime:20
} ; IP termination added }}}}}

Regards,
Rahul Ruikar
Alcatel-Lucent

From: Kevin Boyle [mailto:[email-masked]] 
Sent: Tuesday, May 13, 2008 2:38 AM
To: RUIKAR RAHUL A; [email-masked]
Cc: Schwarz Albrecht
Subject: RE: [Megaco] T.38 session name in examples

 
 
Kevin

Regards,
Rahul Ruikar
Alcatel-Lucent

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 13 May 2008 09:36:08 +0200

Agree to Kevin, this was also made more explicit in the past in an IG
("In session descriptions sent from the MG to the MGC, the SDP must
comply with RFC 2327. "). See also H.248.1 V3 Amendment 1.
 
I may note that there are in the meanwhile many H.248 profile
specification which defining default values for the SDP o=, s= and t=
lines in MG-to-MGC directions.
 
Thus, the T.38 H.248 examples are incorrect in my understanding.
But implementers should implement the protocol, and not examples.
(T.38 was never officially reviewed by Q.3/16 wrt H.248 examples (as far
as I know)).

	From: RUIKAR RAHUL A 
	Sent: Dienstag, 13. Mai 2008 05:10
	To: Kevin Boyle; [email-masked]
	Cc: Schwarz Albrecht
	Subject: RE: [Megaco] T.38 session name in examples

	Thanks for explanation.if "s" line is optional only in MGC->MG
direction and not in MG->MGC
	but then I see that those attributes ( o,s,t ) are missing in
reply from gateway. 
	Now I have following doubt regarding this,
	1) Should MG send RFC 2327 conformant SDP to MGC in reply ( eg.
adding missing o,s,t lines )
	2) or is it MGC which has to manage these missing attribute and
add it to SDP which is to be sent out to remote side.

	MGC to MG1:
	====================
	LocalControl { Mode = ReceiveOnly, ReserveGroup = True,
ReserveValue =
	
	Reply from MG1 -> MGC
	=====================

	Regards,
	Rahul Ruikar
	Alcatel-Lucent

	 
	The s= line (and other mandatory portions of the SDP
specification) are *NOT* optional in H.248.  They are only optional in
the MGC->MG direction.  In communications from the MG to the MGC, the
SDP must be conformant to RFC 2327.  
	 
	The text in Clause 7.1.8 is explicit that the exceptions to SDP
are valid only in the MGC->MG direction.  This is to allow the MGC to
provide over- or under-specified SDP.
	 
	Kevin

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of RUIKAR RAHUL A
	Sent: Sunday, May 11, 2008 6:07 AM
	To: [email-masked]
	Cc: Schwarz Albrecht
	Subject: [Megaco] T.38 session name in examples

	according to SIP RFC "s" line in SIP messages is mandatory, it
is missing in examples 

	Regards,
	Rahul Ruikar
	Alcatel-Lucent

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 13 May 2008 10:59:09 -0400

I agree with Albrecht.  MGs must craft compliant SDP.  It is not the
MGC's responsibility to modify non-compliant SDP from an MG into
compliant SDP.
 
MGs that omit required lines are non-compliant to both RFC 2327 and
H.248.1.
 
Kevin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Schwarz Albrecht
Sent: Tuesday, May 13, 2008 3:36 AM
To: RUIKAR RAHUL A; [email-masked]
Subject: Re: [Megaco] T.38 session name in examples

 

	From: RUIKAR RAHUL A 

	 
	MGC to MG1:
	====================
	
	Reply from MG1 -> MGC
	=====================

	Regards,
	Rahul Ruikar
	Alcatel-Lucent

	 

	Kevin

	Regards,
	Rahul Ruikar
	Alcatel-Lucent

---

From: Christian Groves <[email-masked]>
Date: Wed, 14 May 2008 15:46:36 +1000

Hello Kevin and Albrecht,

There's been a few issues on the T.38 call flows. There's this one and 
the use of a non-defined property value. There's aren't really 
appropriate for the H.248 series implementors guide. I'll make sure the 
Q.14/16 Rapporteur is aware of the issues and see how he wants to handle 
them.

Regards, Christian

Kevin Boyle wrote:
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Schwarz Albrecht
> *Sent:* Tuesday, May 13, 2008 3:36 AM
> *To:* RUIKAR RAHUL A; [email-masked]
> *Subject:* Re: [Megaco] T.38 session name in examples
>
> (T.38 was never officially reviewed by Q.3/16 wrt H.248 examples (as 
> far as I know)).
>  
>
>     ------------------------------------------------------------------------
>     *From:* RUIKAR RAHUL A
>     *Sent:* Dienstag, 13. Mai 2008 05:10
>     *To:* Kevin Boyle; [email-masked]
>     *Cc:* Schwarz Albrecht
>     *Subject:* RE: [Megaco] T.38 session name in examples
>
>     <mailto:[email-masked]>
>     Alcanet: 2721 4732
>      
>
>     ------------------------------------------------------------------------
>     *From:* Kevin Boyle [mailto:[email-masked]]
>     *Sent:* Tuesday, May 13, 2008 2:38 AM
>     *To:* RUIKAR RAHUL A; [email-masked]
>     *Cc:* Schwarz Albrecht
>     *Subject:* RE: [Megaco] T.38 session name in examples
>
>     specification) are *NOT* optional in H.248.  They are only
>     optional in the MGC->MG direction.  In communications from the MG
>     to the MGC, the SDP must be conformant to RFC 2327. 
>      
>     are valid only in the MGC->MG direction.  This is to allow the MGC
>     to provide over- or under-specified SDP.
>      
>     Kevin
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *RUIKAR RAHUL A
>     *Sent:* Sunday, May 11, 2008 6:07 AM
>     *To:* [email-masked]
>     *Cc:* Schwarz Albrecht
>     *Subject:* [Megaco] T.38 session name in examples
>
>     <mailto:[email-masked]>
>     Alcanet: 2721 4732
>      
>
> ------------------------------------------------------------------------
>