Subject: [MMUSIC] How to put multiple ptimes in SDP?

From: FrankYuan <[email-masked]>
Date: Mon, 01 May 2006 14:30:37 -0500

Hi All,
When our sipServer interops with H323,  there is problem.

The incoming H323 SETUP (fast start) has different ptimes for each 
payload (codec),  but SDP only defines ptime for a media stream not for 
each codec.

Normally G723 use ptime=30, and the other use ptime=20.

What the ptime should we use  if G723(30)  and G711(20)  are in the same 
SDP medium?

Is it possible to add  a=fmtp:payload  ptime=nn for each payload type 
for example?

So far I could not find any drafts or RFCs to address this issue.

-- 
Thanks

Frank Yuan

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 May 2006 12:34:17 +0100

On 1 May 2006, at 20:30, FrankYuan wrote:
> payload (codec),  but SDP only defines ptime for a media stream not  
> for each codec.
>
> What the ptime should we use  if G723(30)  and G711(20)  are in the  
> same SDP medium?

You would omit the "a=ptime:" attribute, since those are the default  
values. There is no need for signalling in this case.

> Is it possible to add  a=fmtp:payload  ptime=nn for each payload  
> type for example?

No.

> So far I could not find any drafts or RFCs to address this issue.

There seems to be a common misconception that "a=ptime:" is  
mandatory, and must be signalled when two codecs use different  
packetisation intervals. In fact, the only purpose of "a=ptime:" is  
to recommend (not to require) that the sender uses a non-default  
packetisation interval when encoding a media stream. From RFC 2327:

        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"

and from the RTP/AVP profile [RFC 3551, section 4.2]:

    For packetized audio, the default packetization interval SHOULD have
    a duration of 20 ms or one frame, whichever is longer, unless
    otherwise noted in Table 1 (column "ms/packet").  The packetization
    interval determines the minimum end-to-end delay; longer packets
    introduce less header overhead but higher delay and make packet loss
    more noticeable.  For non-interactive applications such as lectures
    or for links with severe bandwidth constraints, a higher
    packetization delay MAY be used.  A receiver SHOULD accept packets
    representing between 0 and 200 ms of audio data.  (For framed audio
    encodings, a receiver SHOULD accept packets with a number of frames
    equal to 200 ms divided by the frame duration, rounded up.)  This
    restriction allows reasonable buffer sizing for the receiver.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 May 2006 14:07:48 +0200

Hi,

As this discussion pops up again and again I think that is might be time 
to fix it for people that really want to indicate a specific amount of 
media for a packet. There is a draft:
http://www.ietf.org/internet-drafts/draft-xu-mmusic-sdp-codec-param-01.txt

That contains a proposal for this together with some other things. I 
think the general requirements for the the ptime replacement is pretty 
good. I personally don't like the solution. I personally think a single 
attribute for recommended amount of media time in the payload should be 
defined. example: a=rptime:<pt> <value, values, or range>

I am also quite questioning on the per payload transport addresses. This 
is in my opinion not in line with the structure of the media block 
structure and how it relate to RTP sessions etc.

So I think people should review this draft and provide feedback on this 
topic to possibly make some progress here.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]