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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 2 Apr 2001 03:24:30 -0400

> -----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: "Christian Huitema" <[email-masked]>
Date: Tue, 3 Apr 2001 08:47:20 -0700

Michael,

There are several issues with SDP, and with the way it is used in SIP.
Most of these issues have their root in the first usage of SDP: document
the encoding of multicast sessions, for which negotiation does not make
any sense. In the multicast case, the SDP describes the encodings used
by the source, and the receiver is indeed supposed to "load its purple
elephant receiver" -- or decline to attend the multicast conference. 

In the dominant view of the early 90's, "unicast was a special case of
multicast." Well, it is not. In the unicast case, or even with the small
group case, in which we expect senders and receivers to somehow
negotiate a set of appropriate codecs -- codecs that are available at
all ends of the connection, and that are compatible with the path's
bandwidth, delay, and loss rate. In fact, we may want to allow several
codecs in a single session, so that senders and receivers freely
alternate between them if the link conditions vary. To make matter a bit
more complex, we have overloaded our concept of codec to also allocate
payload types to things like FEC.

There are two basic ways to solve this problem. One is to adopt a
convention on how we use SDP today, and another is to design an
alternative encoding that enables negotiation. Since the latter is not
in the SIP WG charter, we have to concentrate on the former, and we have
to make simplifying assumption. In fact, we probably want to make one
simplifying assumption: codec symmetry, the fact that announcing support
for a specific payload type implies both a capability to send and a
capability to receive. This assumption is well grounded in reality; the
main limiting factor in codec availability tends to be the IPR strings
attached to some algorithms, which does not differentiate between send
and receive.

If we assume symmetry, then we don't have to decide whether announcing
several payload types for a media means send or receive: it means both.
As a consequence, we get the negotiation capability: one party proposes
a list of payload types; the responding party selects a subset of that
list; both party use this subset; the sending of the ACK is a
confirmation that the subset has been accepted. If the link conditions
change, and the initial selection appears inadequate, we can always
issue a re-invite and negotiate another subset.

The last practical question is the number of payload types allowed in
the resulting selections. Do we have to commit to exactly one, one plus
FEC, or many simultaneous? This is not an issue for the responder, who
can pick a subset of one in the proposed set, but it is an issue for the
sender, who may have the contradictory goals of proposing several
choices and using only one alternative. The classic way to solve this in
SDP is to define an SDP attribute, such as:
	a:pick-only-one-payload-type-please
I believe that the solutions that I outlined, to assume symmetry and
perhaps to define an attribute that guides the negotiation, are well in
the domain of "implementation agreements" and could be tested during a
next bay-cough(tm).

-- Christian Huitema

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 8:04 AM
> To: Fairlie-Cuninghame, Robert
> Cc: 'Jonathan Rosenberg'; 'Gonzalo Camarillo'; sip; 'Robert Sparks'
> Subject: RE: [SIP] SDP: Sub-set or not in the 200 OK?
> 
> 
> 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:
>  > 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.
>  >
>  > 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?
>  >
>  >
>  >
>  >
>  >
>  > > From: Gonzalo Camarillo
[mailto:[email-masked]]
>  > > negotiation. Besides, it covers more cases than solution number
1).
> It
>  > <!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:Gonzalo.Camarillo
@l
> mf.ericsson.se</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;&nb
sp
> ;&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;&nb
sp
;&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;
&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bs
> p;&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;
&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bs
> p;&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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 4 Apr 2001 01:52:49 -0400

> From: aravindan shanmugam [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 10:48 AM
> To: Gonzalo Camarillo; 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?
> 
> 
> > 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.
> > 
> The callee will check if he can support either codec 1
> or 2 before sending 200 OK with his codec. 

You are missing the point. IF the semantics in the SDP in the INVITE are
"these are the codecs I can receive",the callee may be able to send codecs 1
and 2, but that doesn't mean that a session can be established, because we
don't know if the caller can SEND 1 and 2.

The caller
> is supposed to check if he can support either of the
> listed codecs before responding with ACK.

That is incorrect. ACK is always sent, without SDP, if there was SDP in the
INVITE.

I hope by now that Gonzalo has repeated the relevant points in this thread
enough that we can come to some agreement. I still believe his proposal is a
sound one, and that the issue of "I can support only one codec at a time",
is a separate issue.

-Jonathan R.

---