Subject: attrib "ptime" for RTP codings in SDP

From: Wing Man Kwok <[email-masked]>
Date: Thu, 12 Aug 1999 09:42:08 -0400

All,

On page 123 in the SIP spec RFC2543, section 16.3, there is an INVITE
example with an SDP message body as follows:

         v=0
         o=bell 53655765 2353687637 IN IP4 128.3.4.5
         s=Mr. Watson, come here.
         c=IN IP4 kton.bell-tel.com
         m=audio 3456 RTP/AVP 0 3 4 5

According to the "m=" line, this means that the sender can support RTP audio
coding 0, 3, 4 and 5.  The receiver may pick none, one or more of the
codings from the list.

My questions are:

1.  what is the value of the "ptime" (packet time) attribute of each coding
that the "m=" line implies?
2.  if each coding has a different ptime that the sender can support, how
should the sender specify the ptime value for each coding?

Regards,

Wing Man Kwok

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Aug 1999 22:23:09 -0400

> should the sender specify the ptime value for each coding?

ptime is of limited usefulness in SDP. Its a per-media attribute, which
means it applies to the entire stream, not just a particular encoding
for that stream. In any case, it is an optional, advisory attribute
only. From RFC2327:

>  a=ptime:<packet time>
>        This gives the length of time in milliseconds represented by the
>        media in a packet. This is probably only meaningful for audio
>        data.  It should not be necessary to know ptime to decode RTP or
>        vat audio, and it is intended as a recommendation for the
>        encoding/packetisation of audio.  It is a media attribute, and is
>        not dependent on charset.

In truth, an RTP implementation should be prepared to accept almost any
reasonable packetization delay. According to section 4.2 of the revised
version of rfc1890:

> A receiver SHOULD accept packets representing
>    between 0 and 200 ms of audio data. (For framed audio encodings, a
>    receiver SHOULD accept packets with 200 ms divided by the frame
>    duration, rounded up.) This restriction allows reasonable buffer
>    sizing for the receiver.

(This is also in the original RFC1890) As a result, there shouldn't be a
need to negotiate packetization delays. This is in line with the general
philosophy of being gracious on reception.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen