Subject: RE: [Megaco] RTP profiles clarification

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 17 Oct 2002 10:30:17 -0400

A first point is that since these are questions about a document produced by
the AVT Working Group, if you don't get a satisfactory answer on this list
you should try the AVT list.

Second point: fmtp parameters are those specified in the MIME registration
of the codec type.  For background on this, look at
draft-ietf-avt-profile-new-12.txt section 3.1, and
draft-ietf-avt-rtp-mime-06.txt (especially the latter).  The IANA registry
of payload types is at http://www.iana.org/assignments/media-types/audio/.
RFCxxxx in the IANA registry is probably meant to point to
draft-ietf-avt-rtp-mime-06.txt.

You can use a dynamic payload type for any codec that has a registered MIME
type, which, thanks to the rtp-mime draft cited above, includes all of the
codecs which have been assigned static payload types.  These days you are
encouraged to use dynamic payload types for everything.

Your G.726, G.728, GSM-EFR and G.729 annex difficulties have been resolved,
because the required MIME types to distinguish them have been registered.  I
note an "annexb" parameter for the G729, G729D, and G729E types.  See the
above references.  You are out of luck on G.727: I don't think a
packetization has been defined, and certainly no MIME type has been
registered.  You would have to submit the necessary documentation to the AVT
WG if you want it done.

On G.723.1: I think the implication of the specification in
draft-ietf-avt-profile-new-12.txt is that the use of silence insertion and
the use of 6.3 vs. 5.6 kbit/s do not have to be signalled: your codec should
automatically pick these up.

I should note that you haven't considered the b= line in your examples.

> -----Original Message-----
> From: Rasko Pavlovic [mailto:[email-masked]] 
> Sent: Thursday, October 17, 2002 4:06 AM
> To: [email-masked]
> Subject: [Megaco] RTP profiles clarification
> 
> 
> Hi there,
>  
> I need some help in clarifying static and dynamic profiles. 
> So the story
> goes:
> 1. G711 A-low is defined as RTP AVP 8
>  
> 2. G711 u-low is RTP AVP 0
>  
> 3. G726 as far as I know there is no RTP AVP for this codec. 
> So, this one should be carried over as dynamic. But one thing 
> that is not defines is how to carry over rate parameter since 
> there are 4 algorithms  for G726 with 16, 24,32,40 kbps. I 
> think syntax should be something like: v=0 c=IN IP4 $ m=audio 
> $ RTP/AVP 96 a=rtmap:96 G726 a=fmtp:96 rate=16[24 32 40] Is 
> there any already adopted syntax or is there anybody working 
> on defining this ?
>  
> 4. G727 same question as for G726
>  
> 5. G729E, G729A, G729AB . G729 is RTP/AVP 18. We need syntax 
> for defining annex to be used. There were several approaches 
> but I think the most common is: v=0 c=IN IP4 $ m=audio $ 
> RTP/AVP 97 a=rtmap:97 G729 a=fmtp:97 annexE=yes ( in case we 
> support both A and B annexes a=fmtp:97 annexA=yes annexB=yes )
>  
> 6. G723.1A with rates 5.3 kbps and 6.3 kbps. No RTP/AVP 
> defined. v=0 c=IN IP4 $ m=audio $ RTP/AVP 98 a=rtmap:98 
> G723.1 a=fmtp:98 annexA=yes rate=5.3[6.3]
>  
> 7.G728 defined as RTP/AVP 15
>  
> 8. GSM EFR. No RTP/AVP defined.
> v=0
> c=IN IP4 $
> m=audio $ RTP/AVP 99
> a=rtmap:99 GSMEFR
> Any comments, proposals or already adopted solutions on those issues ?
> ----------------------------------------------------------
> Rasko PAVLOVIC
> Daisy Technologies d.o.o.
> Stegne 21c; 1000 Ljubljana; Slovenia
> fax: +386 (0)1 2342 770
> e-mail:  [email-masked] 
> <mailto:[email-masked]> 
> web: 
> http://www.daisy-tech.com <http://www.daisy-tech.com/> 
> --------------------------------------------------------- 
>  
> _______________________________________________
> 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: Troy Cauble <[email-masked]>
Date: Thu, 17 Oct 2002 13:34:28 -0400

>encouraged to use dynamic payload types for everything.
Just curious.  Who's encouraging this and why?

-troy

---

From: Troy Cauble <[email-masked]>
Date: Thu, 17 Oct 2002 13:34:28 -0400

-troy