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

---

From: Gunter Weiss <[email-masked]>
Date: Fri, 29 Aug 2003 23:02:17 +0200

Hello Christer,

thanks for your reply. I know it could be confusing but in general
it is also confusing. 
The best at all would be to have an agreed Payload Type for 
DTMF relay a'la RFC 2833 with hin the range of 97 to 128.
Then there are still numbers reserved for dynamic PT's.
DTMF relay especially in domains with compressed codecs is
a typical feature to be provided.
Well that's my personal feeling!

But now to your answers/questions/comments - see inline [GW]:

"Christer Holmberg (KI/LMF)" wrote:
> [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. 
[GW]
Are you sure on that? 

> 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 $
> ...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.
[GW]
I'm not sure that SDP would allow such a choose parameter??

> 
> 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...
[GW]
let me put it this way. Assuming a Gateway with a DSP. A DSP will have default
value when you configure it although it can be overidden during a Call Setup phase!
But let's assume the MG must always adapt to what the MGC is saying.
I hope all the smart phones and SIP clients can adapt too!  

> [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.
[GW]
I meant that normally if a MG replies not with only one media format (PT)
there must be a the ReserveValue set to true otherwise it would only 
return the select/ configured one. Or am I wrong??
The reason for considering this was, that in my oppinion the Dynamic PT
is a more specific description, what the resource reserved/allocated
for the request of the MGC is able to handle too.
I'm also not convinced to consider ReserveValue when talking about
DTMF relay , but I wanted to know the generall opinion from the 
megaco community!

> >    a=rtpmap:96 telephone-event/8000
[GW]
When you say it's wrong then you just assume that the MGC will always
trigger a negotiation? 
This brings me to another point : 
If the MGC will not send anything about DTMF relay (telephony events)
to an MG - do you think that the MG is allowed to relay or does it
has to send such events then always inband??

> >      a=cpar: a=rtpmap:96 telephone-event/8000
[GW]
This was analog RFC 3407 a possible way to tell the MGC that the MG
can even more with the resource than what was just requested??
I'm not sure that this is a practicle way?

> Ericsson Finland
Best Regards,
	Gunter

---

From: Gunter Weiss <[email-masked]>
Date: Fri, 29 Aug 2003 23:02:17 +0200

Hello Christer,

[GW]
Are you sure on that? 

[GW]

[GW]

[GW]

[GW]

[GW]

Best Regards,
	Gunter