Subject: [AVT] [MMUSIC] packetisation time question

From: <[email-masked]>
Date: Wed, 18 Jun 2008 16:31:32 +0100

All, seeking help with a question on SDP offer-answer for ptime.

In the context of a bidirectional unicast connection using SDP
offer/answer, we have a need for negotiation of one of at least two
packetisation times for the same codec within a single media offer. One
of the packetisation times is preferred and the other a fallback. This
may be required in the presence of other offered codec formats for which
only one packetisation time is acceptable. 

We know there are difficulties arising because ptime is a media-level
attribute rather than a format-level attribute. RFC 3551 says receivers
should be prepared to receive agreed formats at up to 200ms/packet, and
RFC 4566 says "It should not be necessary to know ptime to decode RTP".
However in our application, packetisation times in both directions
should be minimised between endpoints which have sufficient transmit and
receive bandwidth to minimise round trip delay. Other endpoints with
bandwidth limitations, and provisioned with correspondingly longer
ptimes, can use only the higher packetisation time in both directions.
Also we're unsure of whether endpoints in the wild are typically
prepared to receive packets with any packetisation different from that
which they are sending.

Is there any well-established method to achieve this offer/answer
requirement to agree on symmetric ptimes, but with a prefered and a
fallback value as options?

As a concrete example, suppose we prefer to send and receive G.711 A-law
at 10ms packetisation, but we're prepared to fall back to send and
receive 20ms packetisation. We're also willing to receive G.729 but only
at 20ms packetisation.

If we offer

m=audio 57256 RTP/AVP 8 18
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=ptime:10
a=maxptime:20 

then we think we achieve the desired result for PCMA, but we might get
either 10ms or 20ms G.729 payloads.

A simple solution would seem to be something like the following but we
believe this is not legal and not likely to work with deployed RTP
systems, because ptime is not a format-level attribute:

m=audio 57256 RTP/AVP 8 101 18
a=rtpmap:8 PCMA/8000
a=rtpmap:101 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:8 ptime=10
a=fmtp:101 ptime=20
a=fmtp:18 ptime=20
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Bob Gilman <[email-masked]>
Date: Wed, 18 Jun 2008 14:13:50 -0600

Geoff-
This is the type of problem to be solved by the capability negotiation
work (ID-ietf-mmusic-sdp-media-capabilities-08) and media capabilities
work (ID-ietf-mmusic-sdp-media-capabilities-03).  Having said that,
your point that packetization times should really be format parameters
is interesting (I wouldn't want to packetize DTMF events at the same
rate as G.729.)
Here's your example using media capability negotiation.  The preferred
order of the offer is PCMA at 10ms, PCMA at 20ms, and G729 at 20ms.  The
default (for endpoints not understanding cap negotiation) is also PCMA
at 10ms.

Offer:
   m=audio 57256 RTP/AVP 8
   a=rtpmap:8 PCMA/8000
   a=ptime:10
   a=maxptime:10
   a=mcap:1 PCMA/8000
   a=mcap:2 G729/8000
   a=acap:1 ptime=10
   a=acap:2 ptime=20
   a=acap:3 maxptime=10
   a=acap:4 maxptime=20
   a=pcfg:1 m=1 a=m:1,3 pt=1:8
   a=pcfg:2 m=1 a=m:2,4 pt=1:101
   a=pcfg:3 m=2 a=m:2,4 pt=2:18

If the answerer cannot support 10ms PCMA, but can support 20ms packets,
then it would respond with

   m=audio 55122 RTP/AVP 101
   a=rtpmap:101 PCMA/8000
   a=ptime 20
   a=maxptime 20
   a=acfg:2 m=1 a=m:2,4 pt=1:101

and 20ms packets would be sent and received.  Perhaps it's a little
lengthy, but I think it does what you want.

BTW, we hope to have a new draft of the media capabilities draft,
with some significant extensions, around the end of June so it
can be considered at the July meeting.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Wed, 18 Jun 2008 14:05:14 -0700

Consider,
 
	a=mptime:10 20 20

Refer to,

http://www.ietf.org/internet-drafts/draft-garcia-mmusic-multiple-ptimes-
problem-02.txt

Joe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bob Gilman
Sent: Wednesday, June 18, 2008 3:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] [AVT] packetisation time question

Geoff-
This is the type of problem to be solved by the capability negotiation
work (ID-ietf-mmusic-sdp-media-capabilities-08) and media capabilities
work (ID-ietf-mmusic-sdp-media-capabilities-03).  Having said that, your
point that packetization times should really be format parameters is
interesting (I wouldn't want to packetize DTMF events at the same rate
as G.729.) Here's your example using media capability negotiation.  The
preferred order of the offer is PCMA at 10ms, PCMA at 20ms, and G729 at
20ms.  The default (for endpoints not understanding cap negotiation) is
also PCMA at 10ms.

Offer:
   m=audio 57256 RTP/AVP 8
   a=rtpmap:8 PCMA/8000
   a=ptime:10
   a=maxptime:10
   a=mcap:1 PCMA/8000
   a=mcap:2 G729/8000
   a=acap:1 ptime=10
   a=acap:2 ptime=20
   a=acap:3 maxptime=10
   a=acap:4 maxptime=20

BTW, we hope to have a new draft of the media capabilities draft, with
some significant extensions, around the end of June so it can be
considered at the July meeting.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

[email-masked] wrote:
> packetisation times for the same codec within a single media offer. 
> One of the packetisation times is preferred and the other a fallback. 
> This may be required in the presence of other offered codec formats 
> for which only one packetisation time is acceptable.
> 
> attribute rather than a format-level attribute. RFC 3551 says 
> receivers should be prepared to receive agreed formats at up to 
> 200ms/packet, and RFC 4566 says "It should not be necessary to know
ptime to decode RTP".
> should be minimised between endpoints which have sufficient transmit 
> and receive bandwidth to minimise round trip delay. Other endpoints 
> with bandwidth limitations, and provisioned with correspondingly 
> longer ptimes, can use only the higher packetisation time in both
directions.

> As a concrete example, suppose we prefer to send and receive G.711 
> A-law at 10ms packetisation, but we're prepared to fall back to send 
> and receive 20ms packetisation. We're also willing to receive G.729 
> but only at 20ms packetisation.
> 
> If we offer
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Bob Gilman <[email-masked]>
Date: Wed, 18 Jun 2008 17:10:25 -0600

Joe-
Thanks for pointing out the work of multiple packet times.
The mptime attribute (method 4 of the draft referenced below) is simple
and convenient for conventional SDP, but the use of a ptime parameter in
the fmtp attribute (or the corresponding mfcap attribute) might be more
convenient, or at least less error-prone, in media capabilities
negotiation.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: Randell Jesup <[email-masked]>
Date: Sun, 29 Jun 2008 21:37:39 -0400

>fallback value as options?
...
>m=audio 57256 RTP/AVP 8 101 18

This was solved in the small case for iLBC with the fmtp parameter "mode".
iLBC allows for 20 or 30ms modes only.  The RFC for iLBC (forget the
number) says that you use "fmtp:99 mode=30" (or mode=20) in both offer and
answer.  If either side says 30, then both sides need to do 30.  If the
fmtp is missing, I think it defaults to 30.

Note that this doesn't speak to multiple frames in a packet (which is
really what "period" in SDP-speak is).  'period' is a somewhat
poorly-thought-out parameter, since it's merely a suggestion of what would
be nice, and as mentioned, different codecs might prefer different ptimes.
(and have different maxptimes, too).  The specified ptime might not even be
valid for all the codecs in the payload list - for example, if you have
ptime=30 and they select an iLBC payload with an fmtp mode=20, the ptime
request is going to be ignored (or at least rounded to 20 or 40).

Note: if this is for use with standard codecs (PCMA/U, G.729, etc) then
the schemes like the above can't guarantee to solve your problem, since 
if you're talking to any existing endpoint they can't be guaranteed to
understand your request.  The capability draft would mean that those that
don't understand it (and don't barf on it) will fall back to the default
lowest-common-denominator solution (which could be worse than today, note,
depending on what's selected as the base SDP).

If you make it part of the RTP packetization spec for a new codec, then you
can be assured (hopefully) that it will be understood.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)