Re: Handling of multiple "m=" lines received with same 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/20091223/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