Subject: [SIP] re-INVITE without SDP

From: "Brett Tate" <[email-masked]>
Date: Wed, 21 Mar 2001 19:38:45 -0500

I am glad to see the issue 
"re-INVITE without SDP" has been marked 
closed, but please provide the flow 
details (since I don't recall the meeting 
or minutes were it was closed).

As an FYI, I guess that I should point 
out that re-INVITE-without-SDP suddenly has 
a different meaning from INVITE-without-SDP.  

This means that 3 new ways of SDP matching 
has been introduced for re-INVITEs. 
(implied-SDP means no-SDP so use 
call-leg's previously accepted SDP)

1) 
INVITE(SDP)
200(SDP)
ACK

2) 
INVITE 
200(SDP)
ACK(SDP)

3) 
re-INVITE(implied-SDP)
200(implied-SDP)
ACK

4) 
re-INVITE(implied-SDP)
200(SDP)
ACK

5) 
re-INVITE(implied-SDP)
200(SDP)
ACK(SDP) SDP does NOT have to match implied-SDP.

Methods 1 and 2 have been in the bis since 
August 1999.  Method 1 still works for re-INVITEs.

Since method 2 no longer applies to re-INVITE 
scenarios, methods 3-5 have been introduced.

I guess method 3 can be used for session-timer draft. 
I assume a UA having undergone a restart would 
use method 5 if it chose to allow a 
re-INVITE(implied-SDP) to re-establish a session.
However the sender of re-INVITE(implied-SDP) 
would have to be smart enough to perform 
method 5 instead of method 4.

Method 4 seems strange, but I guess it is valid 
since we now have a concept of implied-SDP.  
I'd actually like to see Method 4 be deemed a
protocol error.

I dislike the concept of an implied-SDP since 
it over complicates matters and removes the 
ability of a 3pcc to safely pull the parties 
off hold without using SIP extension drafts.

But if others prefer this added complexity, 
lets be sure to provide the extra flows in 
the bis or other appropriate locations.

I assume someone will let me know if any of the 
above flows or assumptions were incorrect. :)

-brett

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2001 08:54:58 +0200

Hi Brett,

> call-leg's previously accepted SDP)

So, what you mean is that a scenario could like this:

UA_1		UA_2
--------------------

----INVITE--------->
<---200 (SDP_2)-----
----ACK (SDP_1)---->

-re-INVITE (SDP_1)->
<---200 (SDP_2)-----
----ACK------------>

>re-INVITE(implied-SDP) to re-establish a session.

Isn't 5 against the rule that if the INVITE (in this case a re-INVITE,
but still) contains SDP, the ACK must not contain SDP?

>I'd actually like to see Method 4 be deemed a

I think 4 is ok, if this implied-SDP method is used.
 
>the bis or other appropriate locations.

Do you have another solution?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 22 Mar 2001 21:26:09 -0500

> So, what you mean is that a scenario could like this:

The two usages of SDP correlation that you 
presented above is what was already agreed 
upon and is in the bis.  Each of the numbered
methods was meant to be looked at individually 
to show SDP correlation.

I am mainly trying to point out the current 
solution for closing the open issue has 
resulted in the introduction of an implied-SDP.  
By implied-SDP, I mean the fact that no-SDP 
in re-INVITE now means 
"use my previously accepted SDP on this call-leg".

> but still) contains SDP, the ACK must not contain SDP?

The re-INVITE did not actually contain an SDP; 
it only contained an implied-SDP which maybe 
wasn't remembered.

If a UA has undergone a restart and receives a 
re-INVITE with implied-SDP, it has several
options.
1) Reply with 481.
2) Use method 5 if considered valid.
3) Use method 3 and then send re-invite with
   SDP and hope to not get implied-SDP in the
   200.
4) Reply with 200 with SDP and if not SDP in ACK
   send a re-invite with SDP to hope to not get
   implied-SDP in the 200.  This method not 
   preferred because media alignment might not 
   match the implied-SDP.

> Do you have another solution?

Allow the re-INVITE-without-SDP to mean the 
same thing as INVITE-without-SDP. I wish to 
communicate, and I'll provide my body (SDP) 
in the ACK.

I don't mind using the concept of the implied-SDP, 
but I think it needs to be clearly captured within 
the bis or other appropriate locations.

Can an implied-SDP be used in the following?

UA1                        UA2

 - INVITE (SDP-1a) ------->
<- 200 (SDP-2) -----------
 - ACK ------------------->
 - reINVITE (SDP-1b) ----->
<- 200 (implied-SDP) -----
 - ACK ------------------->