Subject: Re: RTP packet size and use of ptime in SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2000 15:57:58 -0500

This rightly belongs on rem-conf, not on sip.

[email-masked] wrote:
> 
> Hi,
> 
> Questions in brief:
> 
>           1. How much audio should there be in an RTP packet?

Its flexible; there is a tradeoff between packet overheads (the more
data, the less the overhead) and delay (the more data you put in the
packet, the more delay before it can be sent). 

> 
>           2. Does anyone know of an implementation which changes
>              packet size mid stream (i.e. without another INVITE)?

Actually, rfc1890 says receivers should be allowed to receive anywhere
up to 200ms of data in a single packet:

>   constraints, a higher packetization delay may be appropriate. A
>    receiver should accept packets representing between 0 and 200 ms of
>    audio data. T

> 
>           3. Does anyone know of an implementation which refuses
>              an INVITE with a ptime it doesn't like? Does this seem
>              like a reasonable thing to do?

You don't need to do a re-INVITE to change packetization delays,
actually. See the above. Why would you want to do this?

>         The AVP RFC says: 20ms is the "default packetisation interval",
>           but implementations should accept anything from 0 to 200ms.
> 
>           The intent seems to be "send any packet size you want, up
>           to 200ms. If you can't decide what packet size you'd
>           like to send, 20ms isn't a bad choice." (Right?)

This is for sample based codecs. For frame based codecs, you should be
prepared to receive any number of frames in a packet, up to the rounded
up integer of 200 ms divided by the frame duration (so for g.723.1 is 7
frames). I don't think there is a recommendation of the default
packetization interval.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Stephen Casner <[email-masked]>
Date: Thu, 20 Jan 2000 17:24:50 -0800 (Pacific Standard Time)

> up to 200ms of data in a single packet:

More than "allowed", a receiver should be "prepared".

> I don't think there is a recommendation of the default
> packetization interval.

There is in the last column of Table 1.  But really this is only a
suggestion.
							-- Steve

---

From: [email-masked]
Date: Fri, 21 Jan 2000 17:11:23 +0100 (MET)

Jonathan> Actually, rfc1890 says receivers should be allowed to
    Jonathan> receive anywhere up to 200ms of data in a single packet:

 > More than "allowed", a receiver should be "prepared".

What do receivers do to predict and limit resource consumption for
incoming RTP, especially for sample-based codecs?

If I accept an incoming 8kHz mulaw call, I seem to have no way of
knowing whether that means I'll be getting 10 packets/s or 100
packets/s or, sanity aside, 1000 packets/s. 10 and 100 are both
reasonable, but there's a huge difference in resource use, which gets
interesting in a gateway.

Matt

(Aside: it's interesting that RFC 1890 put in the 200ms limit to keep
buffer sizes bounded, but didn't put in anything to help keep other
resource consumption, such as CPU, bounded.)

---

From: "Doug Sauder" <[email-masked]>
Date: Fri, 21 Jan 2000 14:55:56 -0500

> incoming RTP, especially for sample-based codecs?

I think the answer is this: you make reasonable assumptions, complete your implementation, then test for interoperability.  If problems arise, you make the changes and test again.

> interesting in a gateway.

We are fortunate, in that we will probably have to interoperate with fewer than a dozen vendors products in a very controlled environment.  In a situation where the environment isn't so controlled, it's probably not so easy.  Nevertheless, being able to interoperate with the most popular products probably gets you 99% interoperability.

I think it's okay to make certain reasonable assumptions about what you receive: it doesn't mean blatant disregard for the standards.  We will follow the standards very closely with regard to what we send.  RTP covers a lot of different application areas, but most implementations are focused on only one area.  In our case, we are focused on IP telephony, and some features of the standard that make sense in the case of an MBONE multicast often make no sense for us.

> resource consumption, such as CPU, bounded.)

As an example of a reasonable assumption, with mu law encoding, a 200ms packet size would be > 1600 bytes, which is more than the MTU on an Ethernet.  While 200ms might make sense with GSM or some low bandwidth encoding, it makes no sense for mu law, where the packet would be fragmented.

--
Doug Sauder
Software engineer
Broadsoft, Inc.