Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK?

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 2 Apr 2001 03:15:21 -0700

Hi,

Robert Sparks was saying at the bakeoff that UA's should put the set of
vocoders that they can _receive_ in the SDP. This not only seems to be more
in line with the SDP model but also cover a greater number of cases (such as
playing RFC2833 DTMF but not detecting it). 

Perhaps you would be able to re-iterate what problems the send and receive
approach solves that receive only does not ?

Cheers,

Robert.

-----Original Message-----
From:	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Monday, April 02, 2001 9:25 AM
To:	'Gonzalo Camarillo'; sip
Subject:	RE: [SIP] SDP: Sub-set or not in the 200 OK?

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Saturday, March 31, 2001 10:18 PM
> To: sip
> Subject: [SIP] SDP: Sub-set or not in the 200 OK?
> 
> 
> Hello,
> 
> There have been already several mails showing certain confusion about
> SDP usage in SIP.
> In the last IETF the conclusion was:
> For sendrecv flows (uni-directional flows are easy), the 
> caller puts in
> the INVITe the codecs that he can both send AND receive.
> 
> The open issue is what the callee returns:
> 1) a sub-set of the codecs listed in the INVITE that he can send AND
> receive.
> 2) all the codecs that he can send AND receive.
> 
> Note that caller and callee have reversed roles if the SDP from the
> client to the server is sent in the ACK instead of in the INVITE.
> 
> I would like to ask folks not to mix this open issue with another
> similar issue: I have a DSP that cannot change codecs 
> on-the-fly, and I
> want to pick up just one codec. Let us discuss this issue at 
> other time.
> 
> My proposal is to go for solution number 2. This gives a symmetrical
> negotiation. Besides, it covers more cases than solution number 1). It
> can happen that for a particular codec, the callee can send 
> AND receive
> it but the caller can just send it. Therefore, the caller does not
> include it in the INVITE. However, if the callee lists it in 
> the 200 OK,
> the caller will be able to send it.
> 
> Opinions?

I like it.

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

---

From: "dov" <[email-masked]>
Date: Mon, 2 Apr 2001 15:35:27 +0200

RE: [SIP] SDP: Sub-set or not in the 200 OK?Hi,

I agree with Robert that SIP-UAs shall send the set of vocoders that they can _receive_ in the SDP,
in order to allow SIP-UAs to receive Audio/Video streams, even if they can not transmit them.

This can be the case for SIP-UAs capable of receiving MP3 Audio or MPEG video streams, 
but do not have the Hardware and the CPU power (nor the license) to do encoding.

Best Regards,
Dov Ben-Asher.
General Manager,
Startek Technologies.
_____________________________________________
Email: [email-masked]         Web: www.ipness.com
Direct: +972 51 500017
Phone: +972 4 9887666        Fax: +972 4 9887667
_____________________________________________
  ----- Original Message ----- 
  From: Fairlie-Cuninghame, Robert 
  To: 'Jonathan Rosenberg' ; 'Gonzalo Camarillo' ; sip 
  Cc: 'Robert Sparks' 
  Sent: Monday, April 02, 2001 12:15 PM
  Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK?

  Hi, 

  Robert Sparks was saying at the bakeoff that UA's should put the set of vocoders that they can _receive_ in the SDP. This not only seems to be more in line with the SDP model but also cover a greater number of cases (such as playing RFC2833 DTMF but not detecting it). 

  Perhaps you would be able to re-iterate what problems the send and receive approach solves that receive only does not ? 

  Cheers, 

  Robert. 

  -----Original Message----- 
  From:   Jonathan Rosenberg [mailto:[email-masked]] 
  Sent:   Monday, April 02, 2001 9:25 AM 
  To:     'Gonzalo Camarillo'; sip 
  Subject:        RE: [SIP] SDP: Sub-set or not in the 200 OK? 

  I like it. 

  -Jonathan R. 

  ---

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Apr 2001 08:03:34 -0700 (PDT)

That's in line with the way I understand things.
I really don't know what send has to do with
anything. I can claim I'm going to send purple
elephants but when push comes to shove, the purple
elephants never seem to make it onto the wire.
The obnoxious thing for the receiver is that it
may have had to load its purple elephant receiver.
Unless the receiver can say that it doesn't want
to receive purple elephants, you're going to end
up with a situation where you can't communicate
at all, and that doesn't sound like it's headed
in the right direction.

I believe that Gonzalo's proposal still misses one
property which I have always thought is at the
root of all of this: it doesn't allow us to
propose several alternatives, but the the receiver
picks one (or a subset) which is what is actually
loaded into both the sender's and receiver's DSP.
This obviously requires a three way handshake if
you want the "this is what I can receive" model
Robert is speaking of here.

Maybe SIP too should look at Christian's proposal
for multiple SDP's (in MEGACO) when this is the
desired behavior.

		 Mike

Fairlie-Cuninghame, Robert writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
 > <TITLE>RE: [SIP] SDP: Sub-set or not in the 200 OK?</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2 FACE="Arial">Hi,</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">Robert Sparks was saying at the bakeoff that UA's should put the set of vocoders that they can _</FONT><I><FONT SIZE=2 FACE="Arial">receive</FONT></I><FONT SIZE=2 FACE="Arial">_ in the SDP. This not only seems to be more in line with the SDP model but also cover a greater number of cases (such as playing RFC2833 DTMF but not detecting it). </FONT></P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">Perhaps you would be able to re-iterate what problems the send and receive approach solves that receive only does not ?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">Cheers,</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">Robert.</FONT>
 > </P>
 > 
 > <P><A NAME="_MailData"><FONT SIZE=2 FACE="Arial">-----Original Message-----</FONT></A>
 > <BR><B><FONT SIZE=2 FACE="Arial">From:&nbsp;&nbsp; Jonathan Rosenberg [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT></B>
 > <BR><B><FONT SIZE=2 FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=2 FACE="Arial">Monday, April 02, 2001 9:25 AM</FONT>
 > <BR><B><FONT SIZE=2 FACE="Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=2 FACE="Arial">'Gonzalo Camarillo'; sip</FONT>
 > <BR><B><FONT SIZE=2 FACE="Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=2 FACE="Arial">RE: [SIP] SDP: Sub-set or not in the 200 OK?</FONT>
 > </P>
 > <BR>
 > <BR>
 > 
 > <P><FONT SIZE=2 FACE="Arial">&nbsp;</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">&gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; From: Gonzalo Camarillo [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; Sent: Saturday, March 31, 2001 10:18 PM</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; To: sip</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; Subject: [SIP] SDP: Sub-set or not in the 200 OK?</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; Hello,</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; There have been already several mails showing certain confusion about</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; SDP usage in SIP.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; In the last IETF the conclusion was:</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; For sendrecv flows (uni-directional flows are easy), the </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; caller puts in</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; the INVITe the codecs that he can both send AND receive.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; The open issue is what the callee returns:</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; 1) a sub-set of the codecs listed in the INVITE that he can send AND</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; receive.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; 2) all the codecs that he can send AND receive.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; Note that caller and callee have reversed roles if the SDP from the</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; client to the server is sent in the ACK instead of in the INVITE.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; I would like to ask folks not to mix this open issue with another</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; similar issue: I have a DSP that cannot change codecs </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; on-the-fly, and I</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; want to pick up just one codec. Let us discuss this issue at </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; other time.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; My proposal is to go for solution number 2. This gives a symmetrical</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; negotiation. Besides, it covers more cases than solution number 1). It</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; can happen that for a particular codec, the callee can send </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; AND receive</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; it but the caller can just send it. Therefore, the caller does not</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; include it in the INVITE. However, if the callee lists it in </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; the 200 OK,</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; the caller will be able to send it.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt; Opinions?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">I like it.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">-Jonathan R.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">---</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">Jonathan D. Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72 Eagle Rock Ave.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">Chief Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First Floor</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; East Hanover, NJ 07936</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
 > <BR><FONT SIZE=2 FACE="Arial"><A HREF="http://www.cs.columbia.edu/~jdrosen" TARGET="_blank">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PHONE: (973) 952-5000</FONT>
 > <BR><FONT SIZE=2 FACE="Arial"><A HREF="http://www.dynamicsoft.com" TARGET="_blank">http://www.dynamicsoft.com</A></FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2 FACE="Arial">_______________________________________________</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">This list is for continuing development of the SIP protocol.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">The sip-implementor's list is the place to discuss implementation,</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">and to receive advice on understanding existing sip.</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">To subscribe to it, send mail to </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">[email-masked] with &quot;subscribe&quot; in the body.</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Apr 2001 20:53:35 +0300

Hello,

I am going to try to answer all the mails of the thread so far.

Comments inline:

"Fairlie-Cuninghame, Robert" wrote:

> Robert Sparks was saying at the bakeoff that UA's should put the set
> of vocoders that they can _receive_ in the SDP. This not only seems to
> be more in line with the SDP model but also cover a greater number of
> cases (such as playing RFC2833 DTMF but not detecting it).
> 
> Perhaps you would be able to re-iterate what problems the send and
> receive approach solves that receive only does not ?

OK, first of all, we are just dealing with sendrev streams. This is just
a clarification.

Following your suggestion, the caller lists the codecs he can receive in
the INVITE. The callee now does not know if a bi-directional stream can
be established, because he does not know which codecs the caller is able
to send. 

Example: both caller and callee can receive codecs 1 and 2, but not send
them. The INVITE would contain codecs 1 and 2, and the 200 OK will also
contain both codecs. The INVITE-200 OK-ACK is successful, but the
session cannot be established.

If both systems list the codecs that they can send AND receive, if the
INVITE-200 OK-ACK is successful (that is, the 200 OK contains at least
one codec that appeared int he INVITE), both parties are sure that the
session can take place.

>but do not have the Hardware and the CPU power (nor the license) to do encoding.
 
If you want to receive a video stream, your should establish a recvonly
stream and receive whatever you want. The open issue has to do with
sendrecv streams.

Michael Thomas wrote:
> anything.

It has to do with bi-directional streams. We want to negotiate a
sendrecv stream. Therefore, we have to be sure that both parties can
send AND receive.

> I can claim I'm going to send purple

If the receiver does not want to receive purple elephants (or codec
number 1, for instace), it will just not list it in the 200 OK. Then,
the caller will not send elephants of any kind. It will stick to what
the callee has listed in the 200 OK.

> loaded into both the sender's and receiver's DSP.

I knew it!!!!! :o)  I quoute from my first mail:

Victor A Paulsamy wrote:

> This holds good *only* for sending DTMF tones. Otherwise, this would mean
> two media streams encoded *differently* (one in each direction) in a
> session. Is my understanding correct?

No. What you want to do can be done using the SDP fid attribute (I will
be releasing the new version of the draft today or tomorrow). Here we
are dealing with plain SDP.

> I like it.

I also think, as we discussed in the last SIP meeting, that this is the
way to go. This way, when an implementation lists in the 200 OK at least
one codec that was listed in the INVITE, it is ensured that the session
will be established properly.

Of course that we do not cover corner cases when one application can
send a set of codecs and receive a different set of codecs. That's why
we have extensions such as the fid stuff.

Best 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]

---

From: "Victor A Paulsamy" <[email-masked]>
Date: Mon, 2 Apr 2001 15:50:40 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Gonzalo Camarillo
Sent: Monday, April 02, 2001 1:54 PM
To: Fairlie-Cuninghame, Robert
Cc: 'Jonathan Rosenberg'; sip; 'Robert Sparks'; dov; Michael Thomas;
Victor A Paulsamy
Subject: Re: [SIP] SDP: Sub-set or not in the 200 OK?

Gonzalo Camarillo wrote:

>can happen that for a particular codec, the callee can send AND receive
>include it in the INVITE. However, if the callee lists it in the 200 OK,

>are dealing with plain SDP.

Let me give an example. Using codec '0' the caller can only send and the
callee can send and receive.

The caller sends out codec 3, 4, 5 in the INVITE. The callee responds with
0, 3, 4, 5 in the 200 OK.
If the caller choses to send its media stream using codec '0' (since it's
included in 200 OK), it has to use *another codec*
to receive the media stream as it cannot receive using codec '0'. This would
give rise to two codecs, one for transmission and another for reception.

This fits the model of transmitting DTMF tones, where PCM codecs will be
used to transmit it rather than speech codecs.

Warm regards,

--victor

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Apr 2001 00:53:27 +0300

Victor A Paulsamy wrote:

> give rise to two codecs, one for transmission and another for reception.

Actually that's why I am proposing to let the 200 OK contain the list of
codecs that the callee can send AND receive (as opposed to just a
sub-set of the codecs that were present in the INVITE). We both agree.

Regards,

Gonzalo

---

From: aravindan shanmugam <[email-masked]>
Date: Tue, 3 Apr 2001 07:48:19 -0700 (PDT)

--- Gonzalo Camarillo
> session cannot be established.
The callee will check if he can support either codec 1
or 2 before sending 200 OK with his codec. The caller
is supposed to check if he can support either of the
listed codecs before responding with ACK. So if there
is no match in supported codec INVITE-200 OK-ACK
should not be successful.

> one codec that appeared int he INVITE), both parties

Aravindan

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/