Send Megaco mailing list submissions to megaco <at> ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/megaco or, via email, send a message with subject or body 'help' to megaco-request <at> ietf.org You can reach the person managing the list at megaco-owner <at> ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Megaco digest..." Today's Topics: 1. about reserve group and reserve value (Neal Zhu) 2. about the difference between H248 and MGCP (Neal Zhu) 3. Re: about reserve group and reserve value (Tom-PT Taylor) 4. Re: about the difference between H248 and MGCP (Tom-PT Taylor) 5. Re: about the difference between H248 and MGCP (jijo) ---------------------------------------------------------------------- Message: 1 Date: Wed, 31 Aug 2005 13:47:51 +0000 From: "Neal Zhu" <nealzhu <at> hotmail.com> Subject: [Megaco] about reserve group and reserve value To: megaco <at> ietf.org Message-ID: <BAY22-F13E27CBBAA130425D36398AEA10 <at> phx.gbl> Content-Type: text/plain; charset=gb2312; format=flowed in rfc 3525,there is a sample of call flow: MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 { Context = $ { Add = A4444, Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 ; in ms }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 } } } } } } MG1 -> MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 10003 { Context = 2000 { Add = A4444, Add=A4445{ Media { Stream = 1 { Local { v=0 o=- 2890844526 2890842807 IN IP4 124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 a=ptime:30 a=recvonly } ; RTP profile for G.723.1 is 4 } why here the reserve group is set as OFF for caller? So only G.723 is report by MG1. if MG2 can only support G.711.call will fail.but in fact both caller mg and callee mg support G.711. I think that it is better to set reservegroup as ON for caller and set reservegroup as OFF for callee .it is correct?? thanks, Neal _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn ------------------------------ Message: 2 Date: Wed, 31 Aug 2005 13:52:46 +0000 From: "Neal Zhu" <nealzhu <at> hotmail.com> Subject: [Megaco] about the difference between H248 and MGCP To: megaco <at> ietf.org Message-ID: <BAY22-F6E3FC7A23DA845C7B6B54AEA10 <at> phx.gbl> Content-Type: text/plain; charset=gb2312; format=flowed In RFC 3435 2.6 Use of Local Connection Options and Connection Descriptors As indicated previously, the normal sequence in setting up a bi- directional connection involves at least 3 steps: 1) The Call Agent asks the first gateway to "create a connection" on an endpoint. The gateway allocates resources to that connection, and responds to the command by providing a "session description" (referred to as its LocalConnectionDescriptor). The session description contains the information necessary for another party to send packets towards the newly created connection. 2) The Call Agent then asks the second gateway to "create a connection" on an endpoint. The command carries the "session description" provided by the first gateway (now referred to as the RemoteConnectionDescriptor). The gateway allocates resources to that connection, and responds to the command by providing its own "session description" (LocalConnectionDescriptor). 3) The Call Agent uses a "modify connection" command to provide this second "session description" (now referred to as the RemoteConnectionDescriptor ) to the first endpoint. Once this is done, communication can proceed in both directions. When the Call Agent issues a Create or Modify Connection command, there are thus three parameters that determine the media supported by that connection: * LocalConnectionOptions: Supplied by the Call Agent to control the media parameters used by the gateway for the connection. When supplied, the gateway MUST conform to these media parameters until either the connection is deleted, or a ModifyConnection command with new media parameters (LocalConnectionOptions or RemoteConnectionDescriptor) is received. * RemoteConnectionDescriptor: Supplied by the Call Agent to convey the media parameters supported by the other side of the connection. When supplied, the gateway MUST conform to these media parameters until either the connection is deleted, or a ModifyConnection command with new media parameters (LocalConnectionOptions or RemoteConnectionDescriptor) is received. * LocalConnectionDescriptor: Supplied by the gateway to the Call Agent to convey the media parameters it supports for the connection. When supplied, the gateway MUST honor the media parameters until either the connection is deleted, or the gateway issues a new LocalConnectionDescriptor for that connection. In determining which codec(s) to provide in the LocalConnectionDescriptor, there are three lists of codecs that a gateway needs to consider: * A list of codecs allowed by the LocalConnectionOptions in the current command (either explicitly by encoding method or implicitly by bandwidth and/or packetization period). * A list of codecs in the RemoteConnectionDescriptor in the current command. * An internal list of codecs that the gateway can support for the connection. A gateway MAY support one or more codecs for a given connection. Codec selection (including all relevant media parameters) can then be described by the following steps: 1. An approved list of codecs is formed by taking the intersection of the internal list of codecs and codecs allowed by the LocalConnectionOptions. If LocalConnectionOptions were not provided in the current command, the approved list of codecs thus contains the internal list of codecs. 2. If the approved list of codecs is empty, a codec negotiation failure has occurred and an error response is generated (error code 534 - codec negotiation failure, is RECOMMENDED). 3. Otherwise, a negotiated list of codecs is formed by taking the intersection of the approved list of codecs and codecs allowed by the RemoteConnectionDescriptor. If a RemoteConnectionDescriptor was not provided in the current command, the negotiated list of codecs thus contains the approved list of codecs. 4. If the negotiated list of codecs is empty, a codec negotiation failure has occurred and an error response is generated (error code 534 - codec negotiation failure, is RECOMMENDED). 5. Otherwise, codec negotiation has succeeded, and the negotiated list of codecs is returned in the LocalConnectionDescriptor. i have a doubt that in step 5,the callee mg returns the negotiated list of codecs.it is not a single codec .so in step 3),mdcx is only send to the first endpoint. but for the second endpoint ,how it decide to use which single codec ?for a call ,only a unique codec sould be choosed . thanks, Neal _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ------------------------------ Message: 3 Date: Wed, 31 Aug 2005 10:16:57 -0400 From: "Tom-PT Taylor" <taylor <at> nortel.com> Subject: Re: [Megaco] about reserve group and reserve value To: Neal Zhu <nealzhu <at> hotmail.com> Cc: megaco <at> ietf.org Message-ID: <4315BBD9.4060000 <at> nortel.com> Content-Type: text/plain; charset=GB2312 You're really talking about policy here rather than a protocol issue. In real life, your policy is probably realistic. On the other hand, the example shows a case where the MG is given responsibility for managing its resources. The response is what might happen if the MG is short on bandwidth but has enough memory and processing power. Neal Zhu wrote:

in rfc 3525,there is a sample of call flow: MEGACO/1 [123.123.123.4]:55555 Transaction = 10003 { Context = $ { Add = A4444, Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, nt/jit=40 ; in ms }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 a=ptime:30 v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 } } } } } } MG1 -> MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 10003 { Context = 2000 { Add = A4444, Add=A4445{ Media { Stream = 1 { Local { v=0 o=- 2890844526 2890842807 IN IP4 124.124.124.222 s=- t= 0 0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 a=ptime:30 a=recvonly } ; RTP profile for G.723.1 is 4 } why here the reserve group is set as OFF for caller? So only G.723 is report by MG1. if MG2 can only support G.711.call will fail.but in fact both caller mg and callee mg support G.711. I think that it is better to set reservegroup as ON for caller and set reservegroup as OFF for callee .it is correct?? thanks, Neal _________________________________________________________________ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn _______________________________________________ Megaco mailing list Megaco <at> ietf.org https://www1.ietf.org/mailman/listinfo/megaco

------------------------------ Message: 4 Date: Wed, 31 Aug 2005 10:22:28 -0400 From: "Tom-PT Taylor" <taylor <at> nortel.com> Subject: Re: [Megaco] about the difference between H248 and MGCP To: Neal Zhu <nealzhu <at> hotmail.com> Cc: megaco <at> ietf.org Message-ID: <4315BD24.6020308 <at> nortel.com> Content-Type: text/plain; charset=GB2312 You can end up with multiple codecs quite reasonably -- for instance, G.711, G.711 voice-band data, and RFC 2833 events, and perhaps RFC 2198 redundancy for good measure (I've just been rewriting the data-related part of RFC 2833bis). Neal Zhu wrote:

In RFC 3435 2.6 Use of Local Connection Options and Connection Descriptors As indicated previously, the normal sequence in setting up a bi- directional connection involves at least 3 steps:

...>

i have a doubt that in step 5,the callee mg returns the negotiated list of codecs.it is not a single codec .so in step 3),mdcx is only send to the first endpoint. but for the second endpoint ,how it decide to use which single codec ?for a call ,only a unique codec sould be choosed . thanks, Neal _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ _______________________________________________ Megaco mailing list Megaco <at> ietf.org https://www1.ietf.org/mailman/listinfo/megaco

------------------------------ Message: 5 Date: Wed, 31 Aug 2005 20:57:41 +0530 From: jijo <jijoj <at> axestechnologies.com> Subject: Re: [Megaco] about the difference between H248 and MGCP To: Tom-PT Taylor <taylor <at> nortel.com> Cc: megaco <at> ietf.org Message-ID: <4315CC6D.30107 <at> axestechnologies.com> Content-Type: text/plain; charset=GB2312 Hi, That true, But the Call Agent does a modify to first endpoint with media info selected from the list of media parameter send by the second endpoint. So the first endpoint will try to establish media connection to the second endpoint using the media info rcieved in the MODIFY. so i think still it works. Thanks Jijo Tom-PT Taylor wrote:

You can end up with multiple codecs quite reasonably -- for instance, G.711, G.711 voice-band data, and RFC 2833 events, and perhaps RFC 2198 redundancy for good measure (I've just been rewriting the data-related part of RFC 2833bis). Neal Zhu wrote:

In RFC 3435 2.6 Use of Local Connection Options and Connection Descriptors As indicated previously, the normal sequence in setting up a bi- directional connection involves at least 3 steps:

...>

i have a doubt that in step 5,the callee mg returns the negotiated list of codecs.it is not a single codec .so in step 3),mdcx is only send to the first endpoint. but for the second endpoint ,how it decide to use which single codec ?for a call ,only a unique codec sould be choosed . thanks, Neal _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ _______________________________________________ Megaco mailing list Megaco <at> ietf.org https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________ Megaco mailing list Megaco <at> ietf.org https://www1.ietf.org/mailman/listinfo/megaco

------------------------------ _______________________________________________ Megaco mailing list Megaco <at> ietf.org https://www1.ietf.org/mailman/listinfo/megaco End of Megaco Digest, Vol 16, Issue 23 **************************************