Subject: [Sip] iLBC and early media

From: David Benoit <[email-masked]>
Date: Wed, 10 May 2006 14:38:34 -0300

Hello,

I have come across an interesting problem with iLBC.

If I have a UAC that wants to make a call and offer to receive iLBC, I
would have something like the following in an SDP:

...
m=audio 29996 RTP/AVP 0 97 98 3 101
a=rtpmap:0 pcmu/8000
a=rtpmap:97 ilbc/8000
a=fmtp:97 mode=20
a=rtpmap:98 speex/8000
a=rtpmap:3 gsm/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

The iLBC mode (20 or 30) can't be determined until the answering SDP
arrives.  When I receive an early media RTP packet (as per RFC 3960) with
the iLBC payload type, the only way I can determine the mode is to guess
based on the packet size.  This is made slightly more complicated because
RFC 3952 allows multiple frames of audio to be sent in the same packet.

While it seems that this is possible, it also seems to go against the
intent of the offer/answer model as described in RFC 3264 whereby an
endpoint advertises what it is willing to accept.  With iLBC, we aren't
able to limit what we can accept and must be willing to guess at what the
answer SDP will actually contain.

Have I missed a detail?  Am I expected to guess?  Is there something
better I can do?

David
-- 
[email-masked] | phone: 902-832-2649  fax: 902-832-1015
 "Complex problems have simple, neat and wrong solutions" - H. L. Menken

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 10 May 2006 16:26:12 -0400

On Wed, 2006-05-10 at 14:38 -0300, David Benoit wrote:
> arrives.

I'm not up on how SDP works, so I do not see where this problem comes
from.  Naively, it looks like any RTP with payload type 97 must be iLBC
as well as mode=20 (whatever that is).  Is the problem that the answerer
can reject the mode=20 specification?  (Presumably by omitting it in the
answer.)

If that is the case, there is an implicit requirement that the offerer
must not only be willing to accept RTP with any specified encoding, it
must also be willing to accept RTP with an encoding that would be
generated by omitting any omittable modifiers.

This looks like the critical standard:

RFC 3264, section 6.1:

   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

Dale