Subject: [Megaco] RTP profiles clarification

From: "Rasko Pavlovic" <[email-masked]>
Date: Thu, 17 Oct 2002 10:06:01 +0200

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

---

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,
>  
> 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 ?
>  
> 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]
>  
> web: 
> http://www.daisy-tech.com <http://www.daisy-tech.com/>

---

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

The AVT people have provided such encouragement, for a start.  Here is a
relevant passage from draft-ietf-avt-profile-new-12.txt. 

   This specification establishes the policy that no additional static
   payload types will be assigned beyond the ones defined in this
   document. Establishing this policy avoids the problem of trying to
   create a set of criteria for accepting static assignments and
   encourages the implementation and deployment of the dynamic payload
   type mechanisms.

 I know it doesn't go quite as far as what I said, and I can't find
supporting information in the SDP draft.  I'm reporting what I think I've
heard, and perhaps I was wrong.

> From: Troy Cauble [mailto:[email-masked]] 
> Sent: Thursday, October 17, 2002 1:34 PM
> To: [email-masked]
> Subject: Re: [Megaco] RTP profiles clarification
> 
> 
> Tom-PT Taylor wrote:
> 
> >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.
> >
> >  
> >
> Just curious.  Who's encouraging this and why?
> 
> -troy
>

---

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

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 21 Oct 2002 15:00:57 +0200

When a dynamic payload type is used, does the payload type field of the RTP
header contain the dynamic payload type, or the static payload type to which
it is mapped?  For example:

m=audio 7204 RTP/AVP 96
a=rtpmap:96 G726-32/8000

Does the RTP header contain 96 or 2, which is the static payload type for
G726-32?

If the answer is 96, does this mean that the other subscriber in the call
must also associate dynamic payload 96 with G726-32?

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Thursday, 17 October, 2002 7:50 PM
	To:	'Troy Cauble'; [email-masked]
	Subject:	RE: [Megaco] RTP profiles clarification

	The AVT people have provided such encouragement, for a start.  Here
is a
	relevant passage from draft-ietf-avt-profile-new-12.txt. 

	   This specification establishes the policy that no additional
static
	   payload types will be assigned beyond the ones defined in this
	   document. Establishing this policy avoids the problem of trying
to
	   create a set of criteria for accepting static assignments and
	   encourages the implementation and deployment of the dynamic
payload
	   type mechanisms.

	 I know it doesn't go quite as far as what I said, and I can't find
	supporting information in the SDP draft.  I'm reporting what I think
I've
	heard, and perhaps I was wrong.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Oct 2002 09:11:28 -0400

The RTP header must contain the declared payload type (i.e. 96).  The remote
end will have to respect this if it accepts the stream.  If the stream is
receive-only, it's also possible that the remote end declares a receive-only
stream of its own using a different payload type number for the same codec.
See RFC 3264 (Offer-Answer Model).

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Oct 2002 09:11:28 -0400