Subject: RTP packet size and use of ptime in SIP

From: [email-masked]
Date: Thu, 20 Jan 2000 18:56:38 +0100 (MET)

Hi,

Questions in brief:

	  1. How much audio should there be in an RTP packet?

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

	  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?

Detail:

	The RTP RFC says: packet size is not specified, but all 
	    examples have 20ms packets

	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?)

	The SDP RFC has a "ptime" parameter which may be ignored:

          "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."

Conclusion: 

         Most SIP/RTP implementations (will) use constant-sized
	 packets. They'll get on well with header compression 
	 schemes (e.g. RFC 2508).

	 A few implementations will also pay attention to ptime.
	 (Does anyone apart from me do this?)

         A few implementations might do something else entirely.
	 There's a paper suggesting variable packet sizes (i.e. 
	 packet size varies unpredictably from packet to packet) as 
	 a means for concealing packet loss:

	        http://noc.aic.net/inet98/6e/6e_3.htm 

Comments?

Matt

----
Matthias Läng                          http://www.ericsson.se/cslab/~mml
Ericsson Computer Science Laboratory
Stockholm

---

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

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

>           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). 

>              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

>              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?

>           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: [email-masked]
Date: Fri, 21 Jan 2000 16:10:52 +0100 (MET)

> actually. See the above. Why would you want to do this?

I don't. What I'm mainly concerned about is someone sending me an
INVITE with a ptime I am unable to support.

To make this easier to understand, here's a scenario: I have a gateway
which supports many concurrent calls. The gateway has limited
resources, e.g. my ethernet controllers can send N UDP packets per
second maximum. For the example, let's assume N = 1000.

I already have several calls in progress, and they're consuming 900 of
those 1000 UDP packets/s. If someone sends me an INVITE with a ptime
of 5 ms, I have two choices:

      1. Ignore the requested ptime, and use larger packets to avoid
         giving myself capacity problems

      2. Return 480 "Temorarily Not Available", knowing that I'll be
         able to handle a 5ms packet call eventually.

I don't think there's anything in SIP or SDP which says one of these
is preferable. #1 seems the lesser of two evils.

This maybe also affects attempts to reserve network bandwidth.

Matt