Handling of multiple "m=" lines received with same media-type at Gateway

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

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