Subject: RE: [Sip-implementors] Meaning of SDP 'm' line in INVITE transact ion

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 02:22:22 -0500

(forwarded to sip since there is an open issue here, and also mmusic since
its really an SDP issue)

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:[email-masked]]
> Sent: Friday, February 02, 2001 3:11 PM
> To: [email-masked]
> Subject: [Sip-implementors] Meaning of SDP 'm' line in INVITE 
> transaction
> 
> 
> Dear All,
> 
> I am a bit confused with description of media nagotiating by SIP.
> I refer to rfc2543bis-2.
> 
> * The first case *
> 
> Example 16.3 of the spec.:
> 
> SDP in INIVTE  contains (from Bell): 
> 
> 	m=audio 3456 RTP/AVP 0 3 4 5
> 
> 200 response contains (from Watson):
> 	
> 	m=audio 5004 RTP/AVP 0 3
> 
> and note: "(...)Watson's list of codecs may or may not be a subset
> of the one offered by Bell"

This is an inconsistency in the spec. The spec also says, in the appendix on
SDP, that the SDP offered in the response needs to be a subset offered in
the request. It turns out that it doesn;'t make a huge difference,  since
the caller can compute the intersection if the called party offers something
larger than the subset. Indeed, for the bidirectional case, they are really
equivalent.

The interesting issue that arises is with DTMF. Lets say we have a UA which
can send DTMF, but can't receive it. It also uses PCMU for audio. Now, if it
puts the DTMF codec in the SDP in the INVITE, since the media stream is
bidrectional, it has committed itself to also being able to receive DTMF,
which it can't. However, if it doesn't include the DTMF codec, listing only
PCMU, and the response is a subset, there is no way the called party (say, a
voicexml server), can indicate that it can receive DTMF. Based on this, one
might argue that the following would be reasonable:

INVITE
m=audio 5004 RTP/AVP 0

200 OK
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event

this would mean that the subset would be used for bidrecitonal codecs, and
the response could contain additional codecs that the entity wanted to
receive only.

An alternative is to define an attribute that allows codecs within a stream
to be unidirectional:

INVITE
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event
a=direction:77 sendonly

200 OK
m=audio 5004 RTP/AVP 0 77
a=rtpmap:77 telephone-event
a=direction:77 recvonly

This is yet another SDP extension. There are many recognized limitations of
SDP, and thus the reasoning behind SDP-ng, which will address this case.

So, what should we do here?

I'm inclined, in the interests of KISS, to:

1. stick with the subset mechanism and correct the inconsistencies in the
flows
2. for this DTMF case, simply say that implementing DTMF codec means being
able to send and receive, if you want to use it as part of a bidreictional
stream.

Comments?

> 
> My questions:
> 
> 1. Would Watson reply with e.g.:
> 
> 	m=audio 5004 RTP/AVP 7 8

No, it would never do this. In this case, they have no codecs in common.

> 
> 2. How would it be possible to decode on one UDP port (5004) more
>    then one media stream simultaneosly ( i mean 0 and 3 on 5004) ?

The RTP contains a payload type number (with values of 0 or 3) in each
packet. So, the sender can change encoding on the fly, as needed. This is
useful for applciation adaptation, and also for using rfc2833 tones in the
media stream.

> 
> 
> * The second case *
> 
> B.1 of the spec:
> 
> SDP in INIVTE  contains: 
> 
> 	m=audio 49170 RTP/AVP 0
> 
> 200 response contains:
> 	
> 	m=audio 57920 RTP/AVP 0 1
> 
> Question: Why UAS added codec with payload 1 ?

Again, inconsistency.

> 
> 
> Generally: If 200 response contains codecs that are not understood
> by caller, session probably fail because ACK cannot change session
> description. Is it true ? Correct me, if not.

Correct.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Piotr S. Kossowski" <[email-masked]>
Date: Fri, 16 Mar 2001 19:53:30 +0100

Dear All,

See comments below.

> > Question: Why UAS added codec with payload 1 ?

Well...

This inconsistency could be removed in easy way, I suppose:

Either: from section 16.3 of rfc2543bis-02 (Two-Party Call)
remove sentence "(..)Watson’s list of codecs may or may not be a subset
of the one offered by Bell, as each party indicates the data types it is 
willing to receive." and put this kind of information into appendix B.

Or: add to the sentence a clarifying info in brackets: "however, the sets 
MUST(SHOULD?) have intersection)" that is a consequence of appendix B.

Comments ?

Regards, Piotr