Subject: RE: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invi te response]

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Dec 2000 14:51:39 -0500

My perception of what was agreed to was not "an INVITE without SDP takes a
party off of hold", but rather, "a re-INVITE can have no SDP in the INVITE
request", for the reason, as I stated, that a normal INVITE can have no SDP
in it. Whether the implied semantics of re-INVITE with no SDP is "taking
someone off hold", is worth discussing. 

Anyway, if we had some general model of the sort where "the last SDP you
received is the active one from the other participant", as Dave has
suggested, then the semantics would, in fact, translate to taking the party
off hold. However, as Anders has correctly pointed out, its not the absence
of SDP in INVITE that does this (since the "previous" SDP still is one with
a held media stream), but rather the updated SDP in ACK. In this case, the
statement you should make is "SDP in an ACK, following a re-INVITE with no
SDP, following reinvite transaction that put a call on hold, takes the party
off hold". A mouthful, to be sure, but thats what you are really saying.

-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

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 1:17 PM
> To: Henning Schulzrinne
> Cc: Jonathan Rosenberg; 'Gethin Liddell'; Sip Mail List
> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the
> re-invite response]
> 
> 
> Henning: Thanks for the response.
> 
> The following is text from what I thought was the 
> decision June 23.  The thread was 
> "[SIP] Hold & then re-INVITE without media".
> http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html
> 
> +++++++++++++++++++++++++++++
> "Brett Tate wrote:
> > 
> > I think you already answered my question, but maybe this
> > will provide some clarity.
> > 
> > For the following question, assume A originally
> > sent the INVITE containing an SDP
> > with connection address 0.0.0.0 to B; B replied with 200;
> > A replied with an ACK.  Can an INVITE without SDP
> > indicate to B that A is no longer "holding B" and will
> > provide the complete SDP in the ACK?
> > 
> > A --------------- Invite (no SDP) ----------------------------> B
> >   <-- 200 (SDP with connection address not 0.0.0.0) ---
> >     --- Ack (SDP with connection address not 0.0.0.0) -->
> 
> This should work. This behavior (no SDP in INVITE, but SDP in ACK) is
> allowed, actually. Its main use is for the first INVITE, for interop
> with H.323v1 amongst other things. However, if you can do 
> something in a
> first INVITE, it is allowed in a re-INVITE, so there you go.
> 
> -Jonathan R."
> ++++++++++++++++++++++++++ 
> 
> 
> During the Advanced Media Testing at the last 
> bakeoff, the topic was again raised because 
> some products supported it, and others did not.  
> With Robert Sparks organizing the Advanced 
> Media Testing, it was reiterated by Robert Sparks 
> and myself and dissussed with those present that 
> a re-INVITE without SDP indicates a request to 
> communicate just as an INVITE without SDP 
> would mean prior to a call being established or held.  
> 
> It was documented again August 16, "[SIP] Bakeoff 
> #5 Advanced Scenarios: Media Changes 
> summary for one group"
> http://lists.bell-labs.com/pipermail/sip/2000q3/002168.html
> The following is a snippit.
> ++++++++++++++++++++++++++++
> "It was decided that session hold and retrieval did 
> not need to be tested.  However the importance of an
> INVITE without SDP to pull a held party off of hold 
> was reiterated for its use by third party call controllers." 
> ++++++++++++++++++++++++++++
> 
> 
> For reference, the following text is from 
> September 4, rfc2543bis-02 section 4.2.1:
> +++++++++++++++++++++++
> "The INVITE method indicates that the user or 
> service is being invited to participate in a session.  
> The message body MAY contain a description of 
> the session to which the callee is being invited.  
> For two-party calls, the caller indicates the type 
> of media it is able to receive and possibly the 
> media it is willing to send as well as their 
> parameters such as network destination.  A 
> success response MUST indicate in its message 
> body which media the callee wishes to receive 
> and MAY indicate the media the callee is going 
> to send.
> 
> The caller MAY choose to omit the request 
> body (i.e., not send a session description) or 
> send a session description that does not list 
> any media type.  This indicates that the caller 
> does not know its desired media characteristics 
> until the call has been accepted.  In this case, the 
> UAS SHOULD still return a session description 
> in its informational (1xx) or success (2xx) 
> response, containing those media streams and 
> codecs it supports."
> ++++++++++++++++++++++++
> 
> The above text implies an INVITE without 
> SDP indicates a request for any session 
> description that the receiver wishes to allow,
> and the sender will provide SDP in the ACK.  
> This should translate into having the same 
> meaning in a re-INVITE case.  If the receiver 
> is not the one that put the call on hold, the 
> receiver then should not really want to keep 
> the call on hold.  Thus it would pass back SDP 
> to allow the call to go non-hold (along with any 
> other media changes it might want to allow).  
> If for some strange reason the receiver wants 
> to keep the call on hold, a hold SDP can be 
> returned in 200 response.  And thus it would 
> now be responsible to pull the call off of hold.
> 
> Henning:  
> 
> What does a re-INVITE without SDP mean?  
> Why would a re-INVITE without SDP have 
> a different meaning from an INVITE without 
> SDP?  Just wondering, when was this 
> discussed and agreed upon since I thought 
> the news group and working group agreed 
> upon the opposite?
> 
> Thanks for a response.
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Dec 2000 17:21:32 -0500

I think it's easiest if an INVITE without SDP simply means "no change".
I.e., it has no influence on any media stream. If you didn't have a
media stream before, you don't have one afterwards. If you had some
before, they stay as is. I'm not clear why you would want to need or use
this for removing somebody from sending no media, since a re-INVITE with
the old, pre-hold media does this just fine.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 18:25:34 -0500

> the old, pre-hold media does this just fine.

Thanks for the response.  

Yes, if the UA uses the same SDP before and after 
hold, then there is no problem.  However you
get into the fun persisting SDP over restart issue to
allow the session to be re-established; and many UA's
do not use the same port before and after hold.

BroadSoft uses INVITE without SDP to avoid the 
SDP-change-loop when acting as a 3pcc to 
pull the subscribers off of hold.  This has been 
successfully tested with other vendors.

We can also transfer off of hold, but it seems to be 
unnecessary message overhead when using 
re-INVITE-without-SDP to mean the same as 
INVITE-without-SDP works better and was 
thought to have been previously agreed upon.

If a re-INVITE without SDP does not mean the 
same thing as an INVITE without SDP, please 
explicitly state how they differ within 
section 4.2.1 or elsewhere in rfc2543.

Without using a re-INVITE without SDP, what 
is suggested for A to query if B is willing to 
change codecs or add other streams to an 
existing call without having to try and fail?

Thanks.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Dec 2000 19:07:19 -0500

> successfully tested with other vendors.

We need to find a much better way of doing this. This is definitely
broken.

> section 4.2.1 or elsewhere in rfc2543.

They do not differ according to what I stated. If you invite initially,
the other side had no media, so "no SDP" still means no media.

Generally, I don't like "no SDP" as it breaks, as you point out, the
idempotency of requests. I would much prefer treating changes as media
additions and deletions, i.e., start with SDP with zero m lines and send
new SDP with media (m lines) later once you know the details. That seems
much cleaner.

For a regular (no 3pcc) call, what's the problem with just sending the
new ports when you want to allow media again?

> existing call without having to try and fail?

OPTIONS is exactly meant for querying for capabilities. I have no idea
what semantics "no SDP" should have in querying.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 19:26:24 -0500

> someone off hold", is worth discussing.

Thanks for the response.  Can someone add this
topic to the discussion list for the IETF?

> off hold". A mouthful, to be sure, but thats what you are really saying.

Thanks for the clarification.

The main reason that I say that the INVITE without
SDP instead of ACK with SDP is used as a
request to pull off hold is because many SIP
devices respond to a hold SDP with a hold SDP.
At the bakeoff, those same products tended to
continue to responded with hold SDP to an
INVITE-without-SDP even though they were
not the UA that originally requested the hold.
This is fine, if that SIP UA intends to now be
responsible to pull the session off hold.

For those UA's that respond to hold SDP with
non-hold SDP, the INVITE without SDP has
tended to work; thus they might work with call
setup of the 3pcc-01 draft.  However the 3pcc
would have to include all possible codecs in
the original INVITE-to-hold of figure 1 to avoid
restricting the two parties to a particular codec
based upon Figure 1's flow.  Using REFER
to get "A" to trigger an INVITE or using a transfer
after the original hold to "A" would allow "A" to
populate the SDP however it wishes, and it would
allow "A" to hear/see provisional and failure
responses.

---

From: "Brett Tate" <[email-masked]>
Date: Sat, 2 Dec 2000 18:01:26 -0500

Thanks for the response.

I agree that it is broken if two vendors are 
interpreting differently what the re-INVITE 
without SDP means.  However I have 
attempted to get it cleared up in the news 
group and at bakeoffs.  I thought that the 
news group and the advanced SIP media 
companies were in agreement.  I just now 
found out that we all were not.

> the other side had no media, so "no SDP" still means no media.

Let me restate what September rfc2543-02 
section 4.2.1 says concerning would the receiver 
of an INVITE without SDP.

to send."

"The caller MAY choose to omit the request 

The above indicates that an INVITE without SDP 
incates a request to commicate and the receiver 
indicates the media types, characteristics, 
and locations for communition before the caller 
does.  Notice that a full SDP (all codecs, eccetera) 
is supplied in a 200 response just as if it sent the 
INVITE.  To me (and at least previously other major 
SIP players) a re-INVITE-without-SDP 
and INVITE-without-SDP had the same meaning
and indicate a request to communicate. The
no-hold-SDP in ACK would show that the sender 
no longer has the receiver on HOLD, and receiver 
can send media accorging to the ACK's SDP.

> new SDP with media (m lines) later once you know the details. That seems

This is fine, but I assume that more vendors support 
no SDP than partial SDP since partial SDP violates 
rfc2327.  But of course, I could be wrong.  :)  

When I first posted "[SIP] Hold & then re-INVITE without 
media" in June, I thought that some might argue for partial 
SDP instead of no SDP.  However, no one did.  What is
the benefit of controller supplying partial SDP over no 
SDP since both UA's should be able to pass completely 
new SDP's when coming off of hold?

> new ports when you want to allow media again?

Nothing, except that hold currently is defined as 
changing the connection address to 0.0.0.0 
instead changing the port to 0.

If you are asking what is wrong with using a 
different port before/after hold, nothing excluding 
3pcc.  That is why I did not want a special request 
for 3pcc.  Instead, I just wanted to explicitly 
mention the re-INVITE-without-SDP and 
ACK-with-non-hold-SDP should be expected 
by those UA's that pass back hold-SDP after 
receiving hold-SDP.  Based upon Jonathan's
quote "if you can do something in a first INVITE, 
it is allowed in a re-INVITE", I did not feel any
changes actually needed to be made to the 
specification.  I only ask for it as a means to
highlight what I thought Rosenberg, Sparks, 
news group, others, and myself had already 
agreed that rfc2543bis section 4.2.1 allowed.

> what semantics "no SDP" should have in querying.

According to Section 4.2.1, INVITE-without-SDP 
basically means the same thing as OPTIONS
but corresponds to this particular session and 
works with fewer messages.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 03 Dec 2000 10:19:32 -0500

I believe that the simple set of rules should be

- always send SDP in INVITE and 200

- if you don't know the media yet, don't include m lines. That is
perfectly legal according to RFC 2327:

  "Zero or more media descriptions (see below)"

- Use the normal "0.0.0.0 means hold" (I had mis-spoken about ports)

- if you want to find out what the other side can do, but without
changing things, use OPTIONS (this is needed anyway, since you need to
find the whole set; no-SDP doesn't cover this)

This is much closer to the spirit of soft-state and
always-send-full-state that underlies other Internet protocols. Clearly,
the spec needs to spell this out more explicitly. This is also much
simpler since it integrates hold and normal media changes/additions into
one mechanism, rather than two.

Whether we need to address what end system should do if senders don't
conform is a separate issue.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs