Subject: Re: [Megaco] Megaco Digest, Vol 68, Issue 8

From: "Ginotra, Rajiv" <[email-masked]>
Date: Thu, 24 Dec 2009 10:38:11 +0530

Hi Anupama,

I have found some good information in ITU-T Specs which might be useful
for the below cases, check this out:

Case 1:
According to H.248.1 V3
"A Stream Descriptor specifies a single bidirectional media stream and
so a single session description must not include more than one media
description "m = " line). A Stream Descriptor may contain additional
session descriptions as alternatives. Each media stream for a
termination must appear in distinct Stream Descriptors. When multiple
session descriptions are provided in one descriptor, the "v = "lines are
required as delimiters; otherwise they are optional in session
descriptions sent to the MG."

Case 2:
If a Local or Remote Descriptor contains multiple groups of properties,
and ReserveGroup is "True", then the MG is requested to reserve
resources so that it can decode or encode the media stream according to
any of the alternatives. 

For instance, if the Local Descriptor contains two groups of properties,
one specifying packetized G.711 A-law audio and the other G.723.1 audio,
the MG reserves resources so that it can decode one audio stream encoded
in either G.711 A-law format or G.723.1 format. The MG does not have to
reserve resources to decode two audio streams simultaneously, one
encoded in G.711 A-law and one in G.723.1. The intention for the use of
ReserveValue is analogous.

Regards,
Rajiv

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, December 24, 2009 1:30 AM
To: [email-masked]
Subject: Megaco Digest, Vol 68, Issue 8

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/megaco

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Megaco mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Megaco digest..."

Today's Topics:

   1. Handling of multiple "m=" lines received with same
media-type
      at Gateway (Anupama Saini)

----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Dec 2009 17:55:26 +0530
From: Anupama Saini <[email-masked]>
Subject: [Megaco] Handling of multiple "m=" lines received with same
	media-type at Gateway
To: <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi All

I wish to discuss what is the expected behaviour of a Media Gateway (MG)
when multiple "m=" lines with "audio" media each (as shown below) are
received from the Media GW Controller (MGC).

Case 1:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
m=audio $ RTP/AVP 2
a=ptime:10
a=silenceSupp: off - - - -
}},

Case 2:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
v=0
c=IN IP4 $
m=audio $ RTP/AVP 2
a=ptime:10
a=silenceSupp: off - - - -
}},

Case 1 is when two m= lines are received in the same session description
and
Case 2 is when we have concatenated 2 session descriptions via "v="
delimiters.

As per my understanding, the SDP RFC 2327 does not disallow such
multiple
"m=" lines even if they all contain the same media type.. But I am not
sure
how should the Gateway treat the request.  

Since the ReserveGroup is ON in both these cases, one can say that the
gateway is supposed to reserve resources to support any of the codecs
specified in the "m=" lines. 

Ques1: Is that to be done in the above cases as well? That is, shall the
MG
reserve resources for the "heaviest" codec here.. In this case, payload
2
(G.726-32)?

Ques 2: What should be done with the media attributes given after the
second
"m=" line, like 'ptime' and 'silenceSupp'? 

Even if we reserve the resources for codec '2', the Gateway will create
the
termination here first with codec 8 (G.711a).. What should it do with
the
information of additional attributes specified in the second media
description? Should it store this info somewhere so that if later on a
Modify comes from MGC to change codec to '2', then the MG should take
care
to change ptime to 10 and silencesuppression as off?..

Your suggestion on the above scenario is solicited.

Thanks in advance,

Anupama

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/megaco/attachments/20091223/3f9479
b8/attachment.html>

------------------------------

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

End of Megaco Digest, Vol 68, Issue 8
*************************************

---

From: Anupama Saini <[email-masked]>
Date: Mon, 28 Dec 2009 20:58:21 +0530

Hi Rajiv

Thanks for your response.

As you pointed out, H.248.1 V3 clearly says that there must not be 2 "m="
lines in the same session description. Therefore case 1 will not be valid..

For the 2nd case, I still have a doubt regarding the use of attribute lines
"a=" given with the second (alternative) media stream.
>From what you have quoted below, we can see that for the specific example in
case 2, GW should reserve resources such that it is able to support a call
with either G.711a (8) or G.726-32(2). 
But at the first attempt it will create a termination with codec G.711a. My
doubt is that, if later on a Modify Request comes to change the codec to
G.726-32, and no new values of 'ptime' and 'silenceSupp' are given, then
should the GW take care to use ptime and silenceSupp as "10ms" and "off"
respectively, as were specified in the original Add Request, or is it OK to
ignore what was originally received and use the default options now?

Thanks,
Anupama

-----Original Message-----
From: Ginotra, Rajiv [mailto:[email-masked]] 
Sent: Thursday, December 24, 2009 10:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Megaco Digest, Vol 68, Issue 8

Hi Anupama,

Case 1:
According to H.248.1 V3

Case 2:

Regards,
Rajiv

-----Original Message-----

Today's Topics:

Message: 1

Hi All

Case 1:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
m=audio $ RTP/AVP 2
a=ptime:10

Case 2:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
v=0
c=IN IP4 $
m=audio $ RTP/AVP 2
a=ptime:10

 

Thanks in advance,

Anupama

---

From: "Bhattacharjee, Arindam (Arindam)" <[email-masked]>
Date: Tue, 29 Dec 2009 10:44:25 -0600

Anupama,
Ptime & silencesupp attributes are not clearly defined in SDP. 
Silsupp is defined in RFC 3108 which is for ATM bearer connections & being used in IP as well.
We have silsupp attribute defined individually for codecs also like ptype 13 for g711 or g726 & annexa for g729.

About ptime, we have another parameter maxptime, so packets can be sent within ptime to maxptime range. 

So this settings  can be different in different implementations,

As a thumb rule, use the default settings for TX steam if there is confusion ( or unspecified) in SDP about these parameters.
Have enough buffer to accommodate bigger ptime on RX & RX side should be able to process SIDs if sent from the peer.

This ptime/SID has impact on bandwidth & latency, so these can be adjusted based on SPDF implementations as well.

-Arindam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anupama Saini
Sent: Monday, December 28, 2009 10:28 AM
To: 'Ginotra, Rajiv'; [email-masked]
Subject: Re: [Megaco] Handling of multiple "m=" lines received with same media-type at Gateway

Hi Rajiv

Thanks,
Anupama

-----Original Message-----
From: Ginotra, Rajiv [mailto:[email-masked]] 
Sent: Thursday, December 24, 2009 10:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Megaco Digest, Vol 68, Issue 8

Hi Anupama,

Case 1:
According to H.248.1 V3

Case 2:

Regards,
Rajiv

-----Original Message-----

Today's Topics:

Message: 1

Hi All

Case 1:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
m=audio $ RTP/AVP 2
a=ptime:10

Case 2:
 
LocalControl {
Mode = SendReceive,
ReservedValue = on,
ReservedGroup = on
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 8
v=0
c=IN IP4 $
m=audio $ RTP/AVP 2
a=ptime:10

 

Thanks in advance,

Anupama

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 30 Dec 2009 12:33:18 +0100

That's incorrect Arindam:

the SDP attribute silenceSupp is applicable for non-ATM bearers too!

See RFC 3108 clause 5.6, and also H.248.39: 

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.248.39-200605-I
!!PDF-E&type=items
H.248.39 : Gateway control protocol: H.248 SDP parameter identification
and wildcarding 

6.15.7		Silence suppression attribute
The "silenceSupp" attribute is defined in clause 5.6.3.2/RFC 3108. This
attribute may be used for enabling and disabling of silence suppression
mode for voice codec types without embedded silence suppression support
(e.g., ITU-T Recs G.711 or G.726). This attribute may be also used for
non ATM bearer types like RTP/UDP/IP.
The "silenceSupp" attribute provides five optional sub-fields for
parameterization of the silence suppression function. Their usage may
depend on the ephemeral H.248 Termination type, e.g., VoIP may only use
the <silenceSuppEnable> sub-field, whereas VoATM may use additional sub
fields (see explicit statement in clause 5.6/RFC 3108).
 
Thus, applicable for H.248 IP Streams like e.g. G.711-over-RTP etc 

-Albrecht

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BHATTACHARJEE Arindam
> Sent: Dienstag, 29. Dezember 2009 17:44
> To: Anupama Saini; 'Ginotra, Rajiv'; [email-masked]
> Subject: Re: [Megaco] Handling of multiple "m=" lines 
> received withsame media-type at Gateway
> 
> Anupama,
> We have silsupp attribute defined individually for codecs 
> also like ptype 13 for g711 or g726 & annexa for g729.
> 
> About ptime, we have another parameter maxptime, so packets 
> can be sent within ptime to maxptime range. 
> 
> As a thumb rule, use the default settings for TX steam if 
> there is confusion ( or unspecified) in SDP about these parameters.
> Have enough buffer to accommodate bigger ptime on RX & RX 
> side should be able to process SIDs if sent from the peer.
> 
> This ptime/SID has impact on bandwidth & latency, so these 
> can be adjusted based on SPDF implementations as well.
> 
> -Arindam
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anupama Saini
> For the 2nd case, I still have a doubt regarding the use of 
> attribute lines "a=" given with the second (alternative) media stream.
> From what you have quoted below, we can see that for the 
> specific example in case 2, GW should reserve resources such 
> that it is able to support a call with either G.711a (8) or 
> G.726-32(2). 
> But at the first attempt it will create a termination with 
> codec G.711a. My doubt is that, if later on a Modify Request 
> comes to change the codec to G.726-32, and no new values of 
> 'ptime' and 'silenceSupp' are given, then should the GW take 
> care to use ptime and silenceSupp as "10ms" and "off"
> respectively, as were specified in the original Add Request, 
> or is it OK to ignore what was originally received and use 
> the default options now?
> 
> Thanks,
> Anupama
> 
> I have found some good information in ITU-T Specs which might 
> be useful for the below cases, check this out:
> 
> Case 1:
> According to H.248.1 V3
> "A Stream Descriptor specifies a single bidirectional media 
> stream and so a single session description must not include 
> more than one media description "m = " line). A Stream 
> Descriptor may contain additional session descriptions as 
> alternatives. Each media stream for a termination must appear 
> in distinct Stream Descriptors. When multiple session 
> descriptions are provided in one descriptor, the "v = "lines 
> are required as delimiters; otherwise they are optional in 
> session descriptions sent to the MG."
> 
> Case 2:
> If a Local or Remote Descriptor contains multiple groups of 
> properties, and ReserveGroup is "True", then the MG is 
> requested to reserve resources so that it can decode or 
> encode the media stream according to any of the alternatives. 
> 
> For instance, if the Local Descriptor contains two groups of 
> properties, one specifying packetized G.711 A-law audio and 
> the other G.723.1 audio, the MG reserves resources so that it 
> can decode one audio stream encoded in either G.711 A-law 
> format or G.723.1 format. The MG does not have to reserve 
> resources to decode two audio streams simultaneously, one 
> encoded in G.711 A-law and one in G.723.1. The intention for 
> the use of ReserveValue is analogous.
> 
> 
> Regards,
> Rajiv
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> If you have received this digest without all the individual 
> message attachments you will need to update your digest 
> options in your list subscription.  To do so, go to 
> 
> Click the 'Unsubscribe or edit options' button, log in, and 
> set "Get MIME or Plain Text Digests?" to MIME.  You can set 
> this option globally for all the list digests you receive at 
> this point.
> 
> 
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Megaco digest..."
> 
> 
> Today's Topics:
> 
>    1. Handling of multiple "m=" lines received with same media-type
> I wish to discuss what is the expected behaviour of a Media 
> Gateway (MG) when multiple "m=" lines with "audio" media each 
> (as shown below) are received from the Media GW Controller (MGC).
> 
>  
> 
> Case 1:
>  
> LocalControl {
> Mode = SendReceive,
> ReservedValue = on,
> ReservedGroup = on
> },
> Local {
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 8
> m=audio $ RTP/AVP 2
> a=ptime:10
> Case 1 is when two m= lines are received in the same session 
> description and Case 2 is when we have concatenated 2 session 
> descriptions via "v="
> delimiters.
> 
>  
> 
> As per my understanding, the SDP RFC 2327 does not disallow 
> such multiple "m=" lines even if they all contain the same 
> media type.. But I am not sure how should the Gateway treat 
> the request.  
> 
>  
> 
> Since the ReserveGroup is ON in both these cases, one can say 
> that the gateway is supposed to reserve resources to support 
> any of the codecs specified in the "m=" lines. 
> 
> Ques1: Is that to be done in the above cases as well? That 
> is, shall the MG reserve resources for the "heaviest" codec 
> here.. In this case, payload
> 2
> (G.726-32)?
> 
>  
> 
> Ques 2: What should be done with the media attributes given 
> after the second "m=" line, like 'ptime' and 'silenceSupp'? 
> 
> Even if we reserve the resources for codec '2', the Gateway 
> will create the termination here first with codec 8 
> (G.711a).. What should it do with the information of 
> additional attributes specified in the second media 
> description? Should it store this info somewhere so that if 
> later on a Modify comes from MGC to change codec to '2', then 
> the MG should take care to change ptime to 10 and 
> silencesuppression as off?..
> 
>  
> 
>  
>

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 30 Dec 2009 12:45:56 +0100

The "ptime" issue is independent of H.248, located in SDP (RFC 4566 and
RFC 3264 legacy SDP Offer/Answer) itself.
See
draft-garcia-mmusic-multiple-ptimes-problem
http://www.watersprings.org/pub/id/draft-garcia-mmusic-multiple-ptimes-p
roblem-03.txt
 
There are multiple possible solutions discussed.
I'm in favour of Method 11 (B.11), using the "Revised SDP Offer/Answer"
(-> ietf-mmusic-sdp-capability-negotiation), more precisely:
=> the SDP SYNTAX at H.248 interface
=> the SEMANTICS of the revised OFFER/ANSWER procedures (at H.248) are
still under discussion, see ITU-T SG16 Q.3 work item "H.248.SDPMAPPER"

/Albrecht

> received with same media-type at Gateway
> 
> 
> Hi Rajiv
>