Subject: [Megaco] Megaco Stack-Disable SDP

From: Amit Singh <[email-masked]>
Date: Thu, 01 Sep 2005 15:59:19 +0530

Hi All

I am Testing Megaco stack on Linux Platform.
  How to disabel SDP in ABNF.( when request sending from MG to MGC.)

Amit Singh

Software Engineer

[email-masked] wrote:

>Send Megaco mailing list submissions to
>	[email-masked]
>
>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
>	[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. 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" <[email-masked]>
>Subject: [Megaco] about reserve group and reserve value
>To: [email-masked]
>Message-ID: <[email-masked]>
>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" <[email-masked]>
>Subject: [Megaco] about the difference between H248 and MGCP
>To: [email-masked]
>Message-ID: <[email-masked]>
>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" <[email-masked]>
>Subject: Re: [Megaco] about reserve group and reserve value
>To: Neal Zhu <[email-masked]>
>Cc: [email-masked]
>Message-ID: <[email-masked]>
>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>    
>>
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Wed, 31 Aug 2005 10:22:28 -0400
>From: "Tom-PT Taylor" <[email-masked]>
>Subject: Re: [Megaco] about the difference between H248 and MGCP
>To: Neal Zhu <[email-masked]>
>Cc: [email-masked]
>Message-ID: <[email-masked]>
>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>    
>>
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Wed, 31 Aug 2005 20:57:41 +0530
>From: jijo <[email-masked]>
>Subject: Re: [Megaco] about the difference between H248 and MGCP
>To: Tom-PT Taylor <[email-masked]>
>Cc: [email-masked]
>Message-ID: <[email-masked]>
>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
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>End of Megaco Digest, Vol 16, Issue 23
>**************************************
>
>
>  
>
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: jijo <[email-masked]>
Date: Thu, 01 Sep 2005 17:31:08 +0530

Hi Amit,

If you don't want SDP, then better don't build any local media information

Thanks
Jijo
Amit Singh wrote:

>------------------------------------------------------------------------
>