Subject: RE: [Megaco] Question concerning Dynamic Payload Type negotiation /configuration

From: "Christer Holmberg (KI/LMF)" <[email-masked]>
Date: Fri, 29 Aug 2003 08:05:06 +0200

Hi,

Comments inline ([CHH])

>I have some basic questions on Dynamic PT negotiation within 
>H.248/SDP:
>--------------------------------------------------------------
>---------
>   How is it considered in a H.248 controlled network to negotiate
>   the Dynamic Payload type (used for DTMF relay a'la RFC2833)
>   between the two ends (Media Gateways) via the MGC.
>   In detail I'm interested to know, how will the first ADD request
>   from the MGC to the originating Gateway look like?
>   1.1
>   Will the MGC already send a dynamic payload in the session 
>   description
>   of the first Add request from MGC towards the Gateway?
>   e.g.:
>   MGC >> MG:
>   m=audio $ RTP/AVP 8 96
>   a=rtpmap:96 telephone-event/8000
> 
>   MG >> MGC:
>   m=audio 10036 RTP/AVP 8 96
>   a=rtpmap:96 telephone-event/8000

[CHH] This looks correct.

>   1.1.1: What will be if the Gateway has another default PT for 
>   let's say DTMF relay? Can it responsen than in the following way:
> 
>   MG >> MGC:
>   m=audio 10036 RTP/AVP 8 97
>   a=rtpmap:97 telephone-event/8000
> 
>   Or is it considered that the GW can always adapt the PT??

[CHH] That is an interesting question. It IS allowed, to my understanding, to use different PT in each media direction, for the same codec, but I am not sure H.248 allows you to override defined values. Also, I can't remember that the H.248 spec it would be forbidden to use the "$" wildcard for the payload type. But, in that case you would have to insert "$" in both the m= line and the rtpmap attribute.

m=audio $ RTP/AVP 8 $
a=rtpmap: $ telephone-event/8000

...but I am not sure that would work. Assume you have multiple rtpmap attributes, together with some fmtp attributes. How would the MG be able to map a specific fmtp attribute with a specific rtpmap attribute, since both only have "$" defined as payload type.

And, no matter if it's allowed or not, I think that having a "default" payload type value, as you define it, is maybe not a very good idea...

>    1.2 If the MGC will send already two PTs in the m line , 
>    will there be the ReserveValue set to true or is in this
>    case the ReserveValue not considered at all as the Dynamic PT is
>    a further specification, what the resource should be able 
>    to handle?
> 
>    MGC >> MG:
> 
>    MEGACO/1.0 [123.123.123.4]:55555
>    Transaction = 11 {
>     Context = $ {
>        Add = DS0/1/1
>        Add = $ {
>           Media {
>              LocalControl{
>                 Mode = ReceiveOnly,
>                 ReserveValue = true}; 
>              Local{
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 8 96
>    a=rtpmap:96 telephone-event/8000
>                   }
>    }}}}

[CHH] I am not sure what you mean. I don't think ReserveValue has anything to do with the fact is a payload type is dynamic or static.

>    1.3 Or is it not sent in the request from the MGC, but sent in the
>    response from the MG to the MGC?
>    e.g.
>    MGC >> MG:
>    m=audio $ RTP/AVP 8
> 
>    MG >> MGC:
>    m=audio 10036 RTP/AVP 8 96
>    a=rtpmap:96 telephone-event/8000

[CHH] This is wrong.

>    or another possible way to report the capabilities:
>    e.g.:
>    MGC >> MG:
>      m=audio $ RTP/AVP 8
> 
>    MG >> MGC:
>      m=audio 3456 RTP/AVP 8
>      a=sqn: 0
>      a=cdsc: 1 audio RTP/AVP 8 96
>      a=cpar: a=rtpmap:96 telephone-event/8000

[CHH] I'm lost... :)

Regards,

Christer Holmberg
Ericsson Finland

> 
> 
> If there are already scenarios on this topic please point me to it!
> 
> Thanks in advance,
> 	Gunter!
>  
> -- 
>                             Gunter Weiss,  VS/NGE,  VND
>     +--------V--------+     Competance Area Leader - Gateway Protocols
>     |  A L C A T E L  |     callto: +49-711-821-41613 faxto : .-40247
>     +-----------------+     mailto:[email-masked]
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
> 

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco