Subject: [Sip] Open Issue #342: SDP in 488

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Jan 2002 00:56:29 -0500

My notes indicate that there had been agreement on the list some time 
back to
allow 488 and 606 to contain SDP, formatted in the same way as an OPTIONS
response (which is also not defined at this time), in order to figure out
exactly what the capabilities were, which would help explain why the 
request was
rejected. This never made it into bis, and the spec says nothing about 
this at
this time.

Do we want to add it in?

My proposal is NO. If it hasn't been missed yet, its a sign its not that 
critical.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Terry L Anderson <[email-masked]>
Date: Wed, 02 Jan 2002 10:54:39 -0500

Actually I think that this IS in bis-05.  22.41 near the end states:

"If the warning is caused by the session description, the status response
SHOULD include a session description similar to that included in OPTIONS
responses..."

And 606 (and presumably 488) "...MAY contain a list of reason in a
Warning..."
So I have assumed that the normal response to an INVITE with unacceptable
payloads would be a 488 or 606 with Warning  and therefore SHOULD contain the
OPTIONS Response-like body.

If this is not clear in -05,  I favor adding more to make it clearly
encouraged.

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 02:57:44 -0500

> SHOULD include a session description similar to that included in OPTIONS

Good find. I had missed it. Its clearly in the wrong place...

> If this is not clear in -05,  I favor adding more to make it clearly

My aim is to try and remove things from the spec, especially things that 
seem to have never been used. To date, this functionality seems not to 
have been missed.

There is another complication, which is that if we specify that you need 
to return SDP in a 488/606, and an OPTIONS response, then we need to 
specify how to format that SDP. That would either be a new spec in 
mmusic, or more likely, the simcap spec in mmusic. That introduces 
another dependency, plus its not entirely clear to me yet that simcap is 
quite on target for this.

-Jonathan R.

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 03 Jan 2002 10:14:37 -0500

Below

> seem to have never been used. To date, this functionality seems not to

It would be missed if removed.  We use it.

> quite on target for this.

I thought it was specified, although perhaps you believe it needs more
detail.  In bis-04 section 8 and the example in 20.8 seemed clear enough to
me.  Of course much of this is gone in bis-05 (removed along with the reset of
the SDP discussion) although the body (and payload list) is still present in
the example in 11.2 and 11 suggests codecs as one of the types of things that
can be discovered with OPTIONS.

I take it you want to remove the body from OPTIONS response as well then and
remove the word "codec" from the description in 11.

I always felt codec negotiation was the most valuable use of OPTIONS (and
488/606 response).  Otherwise finding a common codec is a trial and error
process.  It is common for gateways to support only symmetric payloads and
single audio codec at a time (with telephone-event possibly added).  If there
is no way to query the other end for a list of supported codecs it is
difficult to find one in common.

I admit that removing the SDP details from the SIP spec makes this more
difficult but I thought that the phrase in bis-04 section 8 (and earlier bis):

    "The response MAY contain a message body indicating the capabilities of
the end
   system (rather than properties of any existing call)."

was clear enough (that any payload list should be all those supported rather
than those desired for a single call) and never mentioned SDP.  It seems to me
that this or some other non-SDP specific description could be sufficient.  Of
course, it would be nice to have a way to specify restrictions like symmetric
codecs required or one codec at a time, etc. but removing even the list makes
life even worse.

--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 12:55:46 -0500

>>another dependency, plus its not entirely clear to me yet that simcap
>>is quite on target for this.
>>
> 
> me.  

Its just an example. Examples don't specify normative text.

Of course much of this is gone in bis-05 (removed along with the
> reset of

Well, I was hoping for 488, I need to remove it from OPTIONS to in order 
to avoid the dependencies, but I am not so hopeful.

> difficult to find one in common.

Thats not true at all. This is why simcap was developed.

> than those desired for a single call) and never mentioned SDP. 

My experiences with SIP/SDP is that you'd be amazed how easily it is for 
people to come up with all kinds of creative interpretations of text 
that is not extremely explicit and direct. The fact is, if we want to 
have OPTIONS 488/606 indicate capabilities with SDP, we need to have an 
explicit way of how that is done, period.

Since I suspect that I won't be able to convince people to remove this, 
I guess i need to go through simcap with a fine tooth comb and make sure 
its up to snuff.

-Jonathan R.

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 04 Jan 2002 16:37:26 -0500

See below

> Its just an example. Examples don't specify normative text.

True but I thought it illustrated the intent of the sentence in section 8
which is normative.

> Thats not true at all. This is why simcap was developed.

I agree simcap helps, but I don't see how to use this in SIP without
488/OPTIONS.
simcap gives a way to know whether later reINVITEs to other codec are likely
to succeed (e.g, indicate capability of telephone-event without starting it
initially), but say UA1 sends an INVITE with m line using 18 but a=cdsc's
indicating support for 0 and 4.  If UA2 cannot support 18 but CAN support 0
and/or 4, what does it do? It must 488/606 the call.  Should UA2 then INVITE
with m line of 0 or should the new INVITE still come from UA1?  I assume UA1
and so UA2 must still inform UA1 of its capabilities by sending a body in
488/606.  Doing this with cdsc rather than m lines is certainly clearer, but
UA2 still needs to send a body.

--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jan 2002 17:13:32 -0500

>>>detail.  In bis-04 section 8 and the example in 20.8 seemed clear
>>>enough to me.
>>>

No, an example is just not sufficient.

>>>If there
>>>is no way to query the other end for a list of supported codecs it
>>>is difficult to find one in common.
>>>
> initially),

Right. See my post on another thread; this was my misunderstanding of 
simcap.

> but say UA1 sends an INVITE with m line using 18 but
> a=cdsc's
> indicating support for 0 and 4.  If UA2 cannot support 18 but CAN
> support 
> and/or 4, what does it do? It must 488/606 the call. 

Or, it could possibly return 0 or 4 in the m line. This is one 
possibility I have proposed in a separate thread.

> Should UA2 then
> INVITE

Despite the fact that other approaches may make the 488 unneeded, I 
think I buy the argument that generally being able to declare 
capabilities in OPTIONS response and 488/606 is a good thing. I am in 
the process of figuring out where such a specification would live.

So, let us consider this issue closed.

-Jonathan R.