Subject: [Sipping] Ptime behavior for iLBC codec for Audio

From: Shruti Thakral <[email-masked]>
Date: Tue, 16 Sep 2008 23:31:03 +0530

Hi,

My query is regarding ptime behavior for iLBC codec sent in SDP.
Does ptime have to be a multiple of the mode (20/30) for iLBC? And, if it is not, I believe it should be ignored. Is this correct?

We are facing certain situations in which we cannot provide a ptime conducive to the multiple theory to the peer. Should this be avoided under all circumstances? Or since ptime is only a suggestive parameter, things can be made simpler by using the same ptime handling policy for all codecs (iLBC, as well, non-iLBC)?

In RTP, ptime is just a suggestive media parameter. Ideally ptime should be a multiple of mode value in case of iLBC. This would have been the thumb rule for the ideal world where ptime would have been followed religiously. However, probably to keep things simpler, and avoid confusions in case of multiple codecs (iLBC and non-iLBC), such a definition was only provided for mptime in RFC 3952 as quoted below:

maxptime:The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time
SHALL be calculated as the sum of the time the media present
in the packet represents. The time SHOULD be a multiple of
the frame size. This attribute is probably only meaningful
for audio data, but may be used with other media types if it
makes sense. It is a media attribute, and is not dependent
on charset. Note that this attribute was introduced after
RFC 2327, and non updated implementations will ignore this
attribute.

This was, however, not imposed on the ptime for iLBC as quoted below:

ptime: Defined as usual for RTP audio (see SDP RFC)

Thanks

Shruti
Aricent Technology Holdings

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP