Subject: RE: [SIP] re-INVITE without SDP

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2001 23:23:15 -0500

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 3:48 PM
> To: 'SIPbell-labs (E-mail)'
> Subject: RE: [SIP] re-INVITE without SDP
> 
> 
> > Why? THat was not the conclusion of the meeting.
> >
> > Re-invite without SDP is allowed. Re-invite without SDP must
> > have SDP in 200
> > OK, and then SDP in ACK, just as INVITE. The UAS can offer
> > whatever SDP it
> > likes in the 200 OK, just as in INVITE. Of course, as with any other
> > mid-call SDP offer, it should only add m lines to any
> > previous SDP used, or
> > mark unneeded m lines with port 0 to close. Standard stuff.
> > The SDP in the
> > ACK must match up with the SDP in 200 OK, just like INVITE.
> >
> > Hope that clarifies it.
> >
> 
> Thanks for the clarification Jonathan.
> 
> I completely agree that the above text is
> how things should work.  However your text
> does not match up with the minutes of the
> IETF 50 open issues BOF which mentioned
> "The re-INVITE without SDP means
> "no change, keep whatever you already have"".
> Your text implies that the following call
> flow should work, but the BOF minutes doesn't.
> 
> A                          B
>  --- INVITE (SDP-A) ------->
> <--- 200 (SDP-B) ----------
>  --- ACK ------------------>
>  --- INVITE (hold-SDP-A) -->
> <--- 200 (SDP-B) ----------  (message 5)
>  --- ACK ------------------>
>  --- INVITE --------------->
> <--- 200 (SDP-B) ----------  (message 8)
>  --- ACK (SDP-A2) --------->
> 
> (The SDP-A2 is SDP-A with a higher
> origin version and maybe a different
> connection address and/or port.)

This flow is fine, and it was my understanding 
that the result of the open issues bof was that its
fine. The golden rule is - you can do whatever you
would be able to do in an initial invite, subject to
the defined constraints of evolving SDP during a call
(only adding m lines).

> 
> Some implementations provide hold-SDP at
> message 5; this is fine if they don't want
> to listen while having been put on hold.
> However some of the same devices would
> provide hold-SDP at message 8 even though
> user B did not actually wish to remain on
> hold.
> 
> Is the above flow considered a valid call
> flow for re-INVITE-without-SDP?
> 
> If so, is it ok to encourage vendors of
> bis fully-compliant products to only provide
> hold-SDP in a 200 for re-INVITE-without-SDP
> if the UA wishes to keep/put the call on
> hold?

There are really two issues here, and I think they are getting
confused.

Issue 1, is: can we recommend constaints on what SDP needs to be offered
when receiving a re-INVITE with no SDP?

Issue 2, is: what is the reasonable response to a re-INVITE with held SDP.
Should it automatically be held SDP also?

As a general principle, I am uncomfortable answering "yes" to question 1.
This is what you had asked for initially when this hold discussion began -
that reinvite without SDP mean "come off hold", and there was a lot of
pushback against that. I appreciate why you want that, but I think it really
has to do with issue 2. The problem is that devices automatically respond
with 0.0.0.0 to a held SDP, when there is no particular reason for that to
be the case. In fact, there are useful service scenarios where this is not
what you want at all. Of course, a human user might choose to ask for stop
receiving media when put on hold, but I am not sure this should be the
automatic response.

So, if it is not the case that the response to a held SDP is also a held
SDP, we don't need a re-INVITE without SDP to trigger coming off hold any
longer.

Comments?

-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: "Bob Penfield" <[email-masked]>
Date: Wed, 28 Mar 2001 13:45:08 -0500

I am curious as to why this was an issue in the first place. If you must
send SDP in either the INVITE or the ACK whether it is an initial INVITE or
a re-INVITE, there really is no way to have a "re-invitation transaction"
without SDP.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: <[email-masked]>; "'SIPbell-labs (E-mail)'"
<[email-masked]>
Sent: Tuesday, March 27, 2001 11:23 PM
Subject: RE: [SIP] re-INVITE without SDP

---

From: "Rick Workman" <[email-masked]>
Date: Wed, 28 Mar 2001 18:08:15 -0500

Indeed, which means you can't have a SIP session without SDP described media,
e.g., an instant messaging session where the endpoints just exchange MESSAGE
requests. Is this really the intent?

We've had this discussion at least twice over the last year, and I'm still
trying to figure out why it's desirable to reply with SDP to an INVITE without
SDP. Apologies if I've missed the response to my earlier (Dec.) posting.

Rick Workman
Nortel Networks

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 29 Mar 2001 01:32:02 -0500

> requests. Is this really the intent?

I think that it was decided that the 
INVITE/200/ACK flow was intended to 
setup an out-of-signaling-path session.  
But I assume that it could be spoofed by 
providing a unique Content-Type, junk 
body, and send MESSAGE (or other requests) 
over the "signaling path".  However I 
assume that many people would hate for 
this to be anything but a proprietary 
usage of SIP.

I guess that you could use SIP to 
establish a SIP session. :)
If "sip" was registered with IANA, 
you could send an SDP with
"m=application <port> udp sip"
to setup an end-to-end exchange of SIP 
messages.

Since many wouldn't dare go 
down that route, define or reuse an
application protocol. Allow SIP to set 
it up with the help of SDP or maybe the 
registering of a contact with "method=".

> SDP. Apologies if I've missed the response to my earlier 

The bis states that it was added for 
interworking with H.323v1.  I'm not sure 
what other interworking protocols would 
require it.

If your question is more related why SDP 
instead of other content types, I assume 
it would be because SDP is the defacto 
standard as the session descriptor.  
But I assume it is fine to reply with 
other descriptors and the originator 
could release the call if it doesn't 
support the content-type (just as it 
would if it didn't support the codecs).
 
> "re-invitation transaction"

I never thought it was an issue either 
until noticing at the events formerly 
known as "bakeoffs" that most UA's 
replied to a re-INVITE to hold with a 
hold SDP.  And when a re-INVITE without 
SDP was sent to the held parties, most 
UA's replied with hold SDP even though 
the held user did not really wish to 
keep the call on hold.  Thus this issue 
was raised when trying to encourage the 
community to run the test-case if they 
wish to support INVITE/re-INVITE without 
SDP.