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

From: "Culpepper, Bert" <[email-masked]>
Date: Thu, 15 Mar 2001 09:59:45 -0600

Hi,

comments below...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 2:22 AM
> To: 'Piotr S. Kossowski'; [email-masked]'; 
> [email-masked]'
> Subject: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line 
> in INVITE
> transact ion
> 
> 
> 
> (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 believe the above can be achieved without any SDP extension. 
For the case a UA supports multiple codecs differently, it can 
use multiple media descriptions.  For example, the case above 
can be signaled as:

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

> 
> I'm inclined, in the interests of KISS, to:
> 
> 1. stick with the subset mechanism and correct the 
> inconsistencies in the
> flows

I don't see any harm in allowing a response to contain a superset 
of the codecs offered in a request.  A requestor can simply not 
send any media it doesn't support.

> 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.

I believe being able to send and receive is a "given" if you 
advertise your capabilities in a bidirectional stream :)

Regards,
Bert

> 
> 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
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 19 Mar 2001 14:11:21 -0600

Hi,

Jonathan - I missed your point previously, I think a means to indicate
separate attributes for alternate codecs will be useful.

I don't have a preference on how it's done.  However, when reading the SDP
and SIP specs I don't understand the presence of multiple payload types in a
media description to mean "only send and/or recv one of these payloads
during the session".  But that it indicates the UA can handle any of the
payload types during the session, and that it can handle the encoding format
changing among the payload types during the session without further SDP or
SIP signaling.  (This might be irrelevant, it's Monday.)

Gonzalo - I believe an example (such as this) would be beneficial in your
draft.  I expect that two different implementations might represent
Jonathan's example differently.  For example, do you use one fid value for
the two payload types or do you use two fid values, a different fid value
for each payload type?  I'm not clear on how to indicate in a response that
I prefer DTMF tones over PCMU but that I only want one, not both (if the
requestor supports both but didn't indicate supporting both in the request).

Regards,
Bert

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 3:58 PM
To: Jonathan Rosenberg
Cc: 'Culpepper, Bert'; 'Piotr S. Kossowski'; [email-masked]';
[email-masked]'
Subject: Re: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in
INVITE transact ion

Hello,

Jonathan Rosenberg wrote:

> No, this has a different meaning. Multiple m lines in SDP imply "parallel"
> streams. What we want here are alternatives.

This is addressed by:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fid-00.txt

If you guys want me to add an example about this before going to final
call let me know.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]