Subject: RTP payload types in draft-ietf-avt-profile-new-08.txt

From: Scott Keagy <[email-masked]>
Date: Thu, 20 Apr 2000 03:03:03 -0700

Steve et al,

Have you considered assigning more RTP payload types to options of G.723
and G.729 with and without VAD support? G.723.1 5.3k vs. 6.3k ? As it
is, vendors must choose to support all or no options of these codecs to
ensure interoperability. Cisco's current SIP implementation, which
appears mostly compliant with the IETF draft, leaves room for
interoperability issues with other vendors because it can support
subsets of these codec types.

(I summarized the details below)

-Scott Keagy

=======================================================
 Scott Keagy, CCIE #3985
 Senior Networking Consultant
 SK Networks, Inc.         mailto:[email-masked]
=======================================================

##################################################################
IOS version:    12.1(1)T      (c3640-p7-mz_121-1_T.bin)
Feature:            SIP/2.0 user agent

Problem Description:

Cisco's interpretation of RTP payload types may not be consistent with
other vendors, which may impact SIP interoperability.

For example, "draft-ietf-avt-profile-new-08.txt" (Jan 14, 2000)
indicates RTP PT=4 corresponds with G.723.1, including the 5.3kbps,
6.3kbps, and Annex A VAD options.

Cisco may indicate a media capability of G.723.1 to other vendors, when
it really only means G.723.1 @ 6.3kbps without Annex A. Other vendors
may justifiably assume that the Cisco router supports all options of
G.723.1, and send RTP packets with G.723.1 @5.3kbps and Annex A VAD.
This scenario would fail if the router is not configured for all of the
options of G.723.1. Cisco is over- advertising media capabilities. But
there is no method for Cisco to only advertise certain options of these
codecs- it's either all or nothing. The RTP payload types should
accomodate this.

A similar problem exists with the G.729 payload type for RTP.

!!The following IOS configuration for codecs........

voice class codec 1
 codec preference 1 g711alaw
 codec preference 2 g711ulaw
 codec preference 3 g723ar53
 codec preference 4 g723ar63
 codec preference 5 g723r53
 codec preference 6 g723r63
 codec preference 7 g726r16
 codec preference 8 g726r24
 codec preference 9 g726r32
 codec preference 10 g728
 codec preference 11 g729br8
 codec preference 12 g729r8

!!Results in this capabilities advertisement (from a SIP INVITE)....

m=audio 20864 RTP/AVP 8 0 65535 65535 65535 4 2 65535 65535 15 65535 18

!!Note the 65535 for codecs that Cisco does not deem to be included as
standard RTP PTs.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Apr 2000 10:05:30 -0400

I agree that having separate names for the different rates would be a
good idea. Note, however, that RTP no longer assigns fixed numerical
payload type values to codecs but relies on SDP or similar protocols to
map names to numbers. Thus, Cisco's implementation seems to take a
short-cut (to put it politely) in that regard, but Steve might be in a
position to educate his colleagues....

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Apr 2000 16:00:51 +0100

The codecs in question have static payload type assignments in the revised
a/v profile. It may be worth specifying SDP parameters, such that these
codecs - with the revised parameters - can be mapped to a dynamic payload
type.

Colin

---

From: Simao Campos <[email-masked]>
Date: Thu, 20 Apr 2000 12:36:41 -0400

Dear all, 

Please note that for G.723.1, the same payload type is used for both
bitrates and for the silence removal (SID) mode, since the bitrate is
indicated in the first two bits of the bitstream. 

To avoid further confusion, you might consider amending
draft-ietf-avt-profile-new-??.{txt,ps} to include a diagram showing
the bit packaging for the G.723.1 modes. Please find attached such a
description, in ASCII format. I hope you find it useful.

Cheers,
Simao.

---

From: Scott Keagy <[email-masked]>
Date: Thu, 20 Apr 2000 10:47:10 -0700

Simao,

I agree that it is possible for a receiver to determine which version of
G.723.1 it is receiving, but the RTP payload type leaves ambiguity for
*advertising* which versions of G.723.1 a machine supports.

As an example, I indicated that Cisco routers do not necessarily support all
options of G.723.1  (or all options may not be configured), but they will
advertise in a SIP INVITE that they support G.723.1. The receiver of such an
invite will assume by the IETF draft that all options are supported, which
leads to confusion during the media establishment:

1) Cisco router's SIP INVITE: "I understand G.723.1"
2) Other vendor's 200 OK: "Great, G.723.1 it is"
3) (session established, other router sends G.723.1 @5.3k w/ Annex A)
4) Cisco router complains: "Wait, actually I  meant G.7236.3k w/o Annex A)

It would be better to avoid the ambiguity up front than to deal with this as
an error condition after the media is already established.

-Scott

Simao Campos wrote:

>   ------------------------------------------------------------------------
>                       Name: pack-g723.1.txt
>    pack-g723.1.txt    Type: Plain Text (text/plain)
>                   Encoding: base64

---

From: Scott Keagy <[email-masked]>
Date: Thu, 20 Apr 2000 11:04:50 -0700

So should an SDP advertisement for all G.723.1 options look like this?

 m=audio 20864 RTP/AVP 4 4 4 4
 a=rtpmap 4 G723/5.3
 a=rtpmap 4 G723/6.3
 a=rtpmap 4 G723/5.3/A
 a=rtpmap 4 G723/6.3/A

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Apr 2000 22:21:30 +0100

> m=audio 20864 RTP/AVP 4 4 4 4

If it's acceptable to have implementations which only support some
varients, then a scheme like this makes sense (although the chosen 
payload type number should be different for each).

Colin

---

From: Orion Hodson <[email-masked]>
Date: Thu, 20 Apr 2000 22:46:14 +0100

There is no need to specify support for 5.3 and 6.3 kbit/s on the
grounds of capability in advertisements.  The summary on page 3 of ITU
Recommendation G.723.1 (03/96) states: "Both rates are a mandatory
part of the encoder and decoder.  It is possible to switch between the
two rates at any frame boundary".  Applications that do not support
both modes should simply not advertise G.723.1.  There is a policy
issue regarding bandwidth usage or acceptable audio quality.  A
clarification of preferred formats would be useful; the default
(first) encoding type in SDP probably suffices with the 5.3/6.3
mode explicitly advertised.

Support for G.723.1 Annex A is optional, but the consequences of
mis-advertisement are minor when the contents of the annex are
considered.  Annex A describes a voice activity detection (VAD)
algorithm and a comfort noise generation (CNG) algorithm.  VAD can be
removed from consideration as there is no information transmitted from
the sender to receiver about what type of VAD algorith is employed.
The VAD algorithm is specified because there are useful measures in
the encoding stages for judging whether a period is silence or not.

When CNG is active an additional frame type, 4 bytes small, is sent to
describe the sound of silence at the end of talkspurts and as the
power spectrum of the silence changes above a threshold.  If the
sender supports CNG and the receiver does not, the receiver will
discard these frames when it inspects frame type present in the first
octet of each frame (which it has to do because a G.723.1 encoder is
permitted to change between 5.3 and 6.3 kbit/s at any frame boundary).
A receiver might not support CNG, but know that a CNG frame is 4 bytes
and therefore be able to fragment compound CNG+audio packets.  In
terms of cost CNG data computation is neglible relative to the
encoding process and the amount of wasted bandwith is small under
normal circumstances.

G.729 is different because the frame type is not included within each
frame and several distinct frame types exist between the original
recommendation and it's annexes (audio at 6.4, 8, and 11.8 kbit/s, and
CNG).  Distinct payload identifiers must be advertised and negotiated
for each of the available encodings as receivers cannot decode the
data otherwise.

- Orion.

Orion Hodson =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Research Student
Networked Multimedia Research Group      Tel: ++(0)20 7679 3704
Department of Computer Science           Fax: ++(0)20 7387 1397
University College London, Gower Street, London,  WC1E 6BT,  UK     
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

---

From: Scott Keagy <[email-masked]>
Date: Thu, 20 Apr 2000 15:15:22 -0700

Two questions:

1) Does SDP allow any RTP payload type to be dynamically defined,
   or only those in the "dynamic" range 96-127 ?

2) If SDP can re-redefine the payload types, then isn't this an inefficient

    way of using SDP & RTP for standard codecs ? The RTP payload field is
not
    adding value in this scheme, and extra lines are required in the SDP
description.
    (yeah SDP bandwidth is neglible compared to media, but it's the thought
that counts).

(Also, point noted by Orion re: G.723 & G.729; these questions of RTP
payload
    and SDP usage are still relevant in the case of G.729).

-Scott

---

From: Simao Campos <[email-masked]>
Date: Fri, 21 Apr 2000 10:55:37 -0400

Henning,

I have attached now as plain text. Also re-sending to rem-conf, in
case someone also missed it.

Regards,
Simao.

------------------
> From: Henning Schulzrinne <[email-masked]>
> Sender: [email-masked]
> To: Simao Campos <[email-masked]>
> Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt
> Date: Fri, 21 Apr 2000 10:46:55 -0400
> 
> Your email attachment was empty.
> -- 

PACKETIZATION FOR G.723.1 AT 6.3 KBIT/S

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | * |                      LPC                      |ACL0       |
   |   |                                               |           |
   |0 0|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5|
   |   |                    0 1 2 3 4 5 6 7 8 9 0 1 2 3|           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    3               4                   5                   6       
    2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | |ACL|    ACL2     |ACL|        GAIN0          |     GAIN1     |
   | | 1 |             | 3 |                       |               |
   |6|0 1|0 1 2 3 4 5 6|0 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7|
   | |   |             |   |                    0 1|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    6           7                   8                   9           
    4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       |   GAIN2               |   GAIN3               | GRID  |
   |       |                       |                       |       |
   |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3|
   |    0 1|                    0 1|                    0 1|       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            1                   1                   1              
    9       0                   1                   2              
    6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |*|  MSBPOS                 |POS0                           |POS|
   |*|                         |                               | 1 |
   |0|0 1 2 3 4 5 6 7 8 9 1 1 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1|0 1|
   | |                    0 1 2|                    0 1 2 3 4 5|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    1   1                   1                   1                  
    2   3                   4                   5                  
    8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |POS1                   |POS2                           |POS3   |
   |                       |                               |       |
   |2 3 4 5 6 7 8 9 1 1 1 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1|0 1 2 3|
   |                0 1 2 3|                    0 1 2 3 4 5|       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    1                   1                   1                   1  
    6                   7                   8                   9  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   |PSIG0      |PSIG1    |PSIG2      |PSIG3    |
   |                   |           |         |           |         |
   |4 5 6 7 8 9 1 1 1 1|0 1 2 3 4 5|0 1 2 3 4|0 1 2 3 4 5|0 1 2 3 4|
   |            0 1 2 3|           |         |           |         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTES: 
(*)  Bits 0 and 1 are always "0 0" for the G.723.1 operation at 6.3
     kbit/s.
(**) Bit 96 is set to '0'

PACKETIZATION FOR G.723.1 AT 5.3 KBIT/S

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | * |                      LPC                      |ACL0       |
   |   |                                               |           |
   |1 0|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5|
   |   |                    0 1 2 3 4 5 6 7 8 9 0 1 2 3|           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    3               4                   5                   6       
    2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | |ACL|    ACL2     |ACL|        GAIN0          |     GAIN1     |
   | | 1 |             | 3 |                       |               |
   |6|0 1|0 1 2 3 4 5 6|0 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7|
   | |   |             |   |                    0 1|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    6           7                   8                   9           
    4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       |   GAIN2               |   GAIN3               | GRID  |
   |       |                       |                       |       |
   |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3|
   |    0 1|                    0 1|                    0 1|       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            1                   1                   1              
    9       0                   1                   2              
    6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |POS0                   |POS1                   |POS2           |
   |                       |                       |               |
   |0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3 4 5 6 7|
   |                    0 1|                    0 1|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    1   1                   1                   1                  
    2   3                   4                   5                  
    8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |POS2   |POS3                   |PSIG0  |PSIG1  |PSIG2  |PSIG3  |
   |       |                       |       |       |       |       |
   |8 9 1 1|0 1 2 3 4 5 6 7 8 9 1 1|0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
   |    0 1|2                   0 1|       |       |       |       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NOTE: 
(*) Bits 0 and 1 are always "1 0" respectively for the G.723.1
    operation at 5.3 kbit/s.

PACKETIZATION FOR G.723.1 SID FRAMES

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | * |                      LPC                      |GAIN       |
   |   |                                               |           |
   |0 1|0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2|0 1 2 3 4 5|
   |   |                    0 1 2 3 4 5 6 7 8 9 0 1 2 3|           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 17:52:10 -0400

This is not an SDP issue so much as an RTP issue. The new rfc1890 says:

> This profile reserves payload type numbers in the range 96-127
>    exclusively for dynamic assignment. Applications SHOULD first use
>    values in this range for dynamic payload types. Those applications
>    which need to define more than 32 dynamic payload types MAY bind
>    codes below 96, in which case it is RECOMMENDED that unassigned
>    payload type numbers be used first. However, the statically assigned
>    payload types are default bindings and MAY be dynamically bound to
>    new encodings if needed. Redefining payload types below 96 may cause
>    incorrect operation if an attempt is made to join a session without
>    obtaining session description information that defines the dynamic
>    payload types.

so, you are allowed to do this, although mostly as a last resort.

>     (yeah SDP bandwidth is neglible compared to media, but it's the thought

Huh? Of course you still need to have this. The payload type is needed
in the RTP to allow for the type to vary on the fly during the session.
This is essential for useful application of comfort noise codecs and of
the avt-tones mechanisms, both of which cause an on the fly change. You
still need the number in SDP so the other side knows what codec is
associated with which RTP payload type number.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Scott Keagy <[email-masked]>
Date: Mon, 24 Apr 2000 13:22:48 -0700

Thanks for the clarification-

I overlooked  tones & comfort noise.

The only issues I have left are vendor-specific :^)

-Scott