SDP "ptime" attribute; RE: Handling of multiple "m=" lines received withsame media-type at Gateway

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

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of BHATTACHARJEE Arindam
> Sent: Dienstag, 29. Dezember 2009 17:44
> To: Anupama Saini; 'Ginotra, Rajiv'; [email protected]
> Subject: Re: [Megaco] Handling of multiple "m=" lines 
> received withsame media-type at Gateway
> 
> 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 protected] 
> [mailto:[email protected]] On Behalf Of Anupama Saini
> Sent: Monday, December 28, 2009 10:28 AM
> To: 'Ginotra, Rajiv'; [email protected]
> Subject: Re: [Megaco] Handling of multiple "m=" lines 
> received with same media-type at Gateway
> 
> 
> 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 protected]]
> Sent: Thursday, December 24, 2009 10:38 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: Megaco Digest, Vol 68, Issue 8
> 
> 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 protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Thursday, December 24, 2009 1:30 AM
> To: [email protected]
> 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 protected]
> 
> 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 protected]
> 
> You can reach the person managing the list at
> 	[email protected]
> 
> 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 protected]>
> Subject: [Megaco] Handling of multiple "m=" lines received with same
> 	media-type at Gateway
> To: <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> 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/20091
> 223/3f9479
> b8/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
> 
> 
> End of Megaco Digest, Vol 68, Issue 8
> *************************************
> 
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
>