Subject: [Sip] SDP in 200 OK for INVITE and preconditions

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 11 Oct 2001 11:17:17 +0300

Hi:

I would like to get some advice on an issue that has been recently pointed out.

The 2543bis says clearly that the 200 OK for an INVITE must contain SDP. SDP is present in INVITE and 200 OK or in 200 OK and ACK, but always in 200 OK.

However, if preconditions are used (manyfolks), the SDP is already known by both parties before the 200 OK, usually in INVITE and 183. As such, one may think if the SDP is still needed in 200 OK for the INVITE when preconditions are used.

I checked out the manyfolks draft, and currently it is stated that the 200 OK for the INVITE is a "normal" one. By "normal" one I understand that it must contain SDP.

Therefore, I understand that from the SIP perspective, the SDP in the 200 OK does not contain any new information, and as such, one could think of saving a few bytes there (not so much if compression is used, but anyway). But I believe the SDP is strictly needed, as the signaling may have traversed a few proxies that depend on the SDP in the 200 OK for whatever reasons (opening holes in a firewall or whatever).

I would like to clarify if the SDP in the 200 OK for an INVITE is needed when preconditions are used. And I would like to identify scenarios where it might be needed.

In case the SDP is needed, perhaps the manyfolks draft could put a little bit of emphasis on this aspect. It would be nice to clarify also that the SDP in the 200 OK cannot be used to change the already agreed preconditions (otherwise the whole precondition negotiation is sent to the trash can).

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

_______________________________________________
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: William Marshall <[email-masked]>
Date: Thu, 11 Oct 2001 13:36:25 -0400 (EDT)

James,

Perhaps I passed over your comment too quickly in updating the
draft last month.  The quick answer is that the manyfolks 
draft took the exact wording from 100rel, which had the
same issue and has passed WGLC and is in the IESG queue.

It is certainly true that any working SIP implementation
needs to follow the revised rules for Record-Route given
in bis.  However, the headers are defined in 2543 and
(somewhat incomplete and/or incorrect) rules for their
use are given in 2543.  My intent in the manyfolks draft
is to not contradict any of the new bis procedures, and
to specify the minimum of corrections to 2543 procedures.

In this way any implementation true to 2543, when extended
with the manyfolks-resource procedures, will work as well
as it did before, and do resource reservation too.

An implementation that is tracking 2543bis, when extended
with the manyfolks-resource procecures, will not have to
deal with any conflicting MUSTs.  And it will work.

I certainly recognize this is a compromise position, and wish
the timing had worked out better.  However, the end state
of bis+manyfolks is a complete and correct specification.

Bill Marshall
[email-masked]

-----original message-----
From: "James Undery" <[email-masked]>
To: "William Marshall" <[email-masked]>, <[email-masked]>
Subject: RE: [Sip] SDP in 200 OK for INVITE and preconditions
Date: Thu, 11 Oct 2001 13:14:30 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of William Marshall
> Sent: 11 October 2001 13:07
> To: [email-masked]
> Subject: Re: [Sip] SDP in 200 OK for INVITE and preconditions
>
>
> There is an issue here with document dependencies, and I really
> don't want manyfolks to have a dependency on bis...

As I said in my last call comment I believe it does, because it
mentions Record Route which never worked (or was even implemented
properly) to my knowledge.

James