Payload types
Payload types
|
PT encoding name |
audio (A) |
clock rate |
channels |
PT |
encoding name |
video (V) |
Clock rate (Hz) |
|
|---|---|---|---|---|---|---|---|---|
|
0 PCMU |
A |
8,000 |
1 |
24 |
unassigned |
V |
||
|
1 reserved |
A |
8,000 |
1 |
25 |
CelB |
V |
90,000 |
|
|
2 reserved |
A |
8,000 |
1 |
26 |
JPEG |
V |
90,000 |
|
|
3 GSM |
A |
8,000 |
1 |
27 |
unassigned |
V |
||
|
4 G723 |
A |
8,000 |
1 |
28 |
nv |
V |
90,000 |
|
|
5 DVI4 |
A |
8,000 |
1 |
29 |
unassigned |
V |
||
|
6 DVI4 |
A |
16,000 |
1 |
30 |
unassigned |
V |
||
|
7 LPC |
A |
8,000 |
1 |
31 |
H.261 |
V |
90,000 |
|
|
8 PCMA |
A |
8,000 |
1 |
32 |
MPV |
V |
90,000 |
|
|
9 G722 |
A |
8,000 |
1 |
33 |
MP2T |
AV |
90,000 |
|
|
10 L16 |
A |
44,100 |
2 |
34..71 |
unassigned |
|||
|
11 L16 |
A |
44,100 |
1 |
72..76 |
reserved |
N/A |
N/A (N/A = Not Applicable) |
|
|
12 QCELP |
A |
8,000 |
1 |
77..95 |
unassigned |
|||
|
13 CN |
A |
8,000 |
1 |
96..127 |
dynamic |
|||
|
14 MPA |
A |
90,000 see RFC |
Dynamic assignment of mapping between a payload type and an encoding is defined by SDP or H.323/H.245 mechanisms; these start with 96 - but can use lower numbers, if more than 32 encodings are needed - see RFC 3551. RFC 3551 says no new static assignments are to be made. |
|||||
|
15 G728 |
A |
8,000 |
1 |
|||||
|
16 DVI4 |
A |
11,025 |
1 |
|||||
|
17 DVI4 |
A |
22,050 |
1 |
|||||
|
18 G729 |
A |
8,000 |
||||||
|
19 reserved |
A |
|||||||
|
20..23 |
Unassigned A |
|||||||
Slide Notes
[RFC 3551] H. Schulzrinne and S. Casner, ‘RTP Profile for Audio and Video Conferences with Minimal Control’, Internet Request for Comments, vol. RFC 3551 (INTERNET STANDARD), Jul. 2003 [Online]. Available: http://www.rfc-editor.org/rfc/rfc3551.txt Links to an external site.
Transcript
[slide92] And initially the packet types were predefined, so we said 0 means it's PCM mu-law coded, whereas 8 said it was PCM A-law coding, etc. This also told us whether the packet contains audio, or whether it contained video, and it tells us what the clock rates were. Now somebody realized, of course, hey, oops, we have a problem there, right? Because how big is that packet type field? [flash back to previous slide] Well, it's only from bits 9 to 15. [back to slide 92] Very quickly it had all of these. The problem is someone said, whoops, we've got a problem, because we're running out of these packet type fields, and they said we should stop assigning packet types. And instead we should make it so that we have a range of them that are dynamic. And now we just negotiate what 126 means. And if we each agree upon this is the CODEC to be used if we both say it's 126, boom, we're set. Instead of having to assign one to every new CODEC that comes along, in which case we soon run out of numbers. Now what's the advantage of putting the packet type in every RTP packet that we send? Well, think about, I'm a mobile and I'm moving along from one building to another. I can send GSM encoded audio, or let's say G.711 coded audio. Let's say I send PCM, I send this as PCM µ-law coded. This has the advantage that it has a low data rate. This needs a higher data rate and all of them have to be delivered. This has some error protection. Why set up that I'll use both of those kinds of CODECs when I agree to set up my session? Well, if I, yes? That's right. So if I'm in a place where I've got plenty of bandwidth, I simply send PCM µ -law coded audio. If I move out of the building and I only have cellular coverage, what do I do? I'm sending that, and I only send the GSM coded audio, but I didn't have to negotiate anything new with the other party that I was talking to. I just simply changed which are the ones I'm currently sending. And since the receiver agreed to receive both kinds of them when we set up the session, it doesn't matter. They can play them both out. So there's a very cool piece of software that was developed here a number of years ago by a student in the second year of the class called Minisip. And it's a complete SIP user agent, but it's designed to be able to have pluggable CODECs. So now it made it really easy to add in new CODECs. And what's also cool is I could have many CODECs loaded at the same time and have data from all of these different CODECs all arriving. And what did it do? It transcoded everything to very, very high sample rate audio, filling the appropriate things in from each of the CODECs coming in. So I could have all of those streams combined and play it out at whatever the maximum sample rate I could play audio out of my device. So it was very cool. We'll see it comes back later for security.