Subject: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 19:08:53 -0400

Issue:

A and B are in a SIP call. A re-invite's B, but includes no SDP in the
INVITE. This triggers B to generate an offer, in the 2xx. A doesn't like the
offer. How does it reject it? When an offer is sent in an INVITE, it is
easily rejected with a 488. But, when the offer is sent in a 2xx, its not
easy to reject. For an initial INVITE, you reject it by ACKing and then
sending BYE. Thats not great, but works OK. For a re-INVITE, you don't want
to BYE, you want to get back to the last-known-good SDP. 

So, the issue is: what to do?

Points of discussion:

One proposal is to ACK the 2xx, disabling all the streams. THen, re-INVITE
with the old SDP, in an attempt to re-instantiate it. However, this
re-INVITE may fail. Also, it results in a transitional period where you have
no media, which is not good.

Another, more outlandish proposal, is to define a NACK that works like ACK,
but says "nah, forget about it". This isn't backwards compatible though.

Dave Oran had suggested that you need something, somewhere, to say "please
go back to where we were before". Whether this is a header in the ACK, or
whether this is in the SDP, it needs to be somewhere. You want to avoid
these transitional periods where the state is bad. You need a way to go
back.

There seemed to be agreement that this was reasonable, but its not clear how
to do it exactly. More discussion is needed.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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: Vijay Gurbani <[email-masked]>
Date: Thu, 23 Aug 2001 10:21:55 -0500

Jonathan:

Comments inline:

Jonathan Rosenberg wrote:
> INVITE. This triggers B to generate an offer, in the 2xx. A doesn't like 
> the offer. How does it reject it? When an offer is sent in an INVITE, it 
> is easily rejected with a 488. But, when the offer is sent in a 2xx, its 
> not easy to reject. For an initial INVITE, you reject it by ACKing and 
> then sending BYE. Thats not great, but works OK. For a re-INVITE, you 
> don't want to BYE, you want to get back to the last-known-good SDP.
> 
> re-INVITE may fail. Also, it results in a transitional period where you 
> have no media, which is not good.
> 
> Another, more outlandish proposal, is to define a NACK that works like 
> ACK, but says "nah, forget about it". This isn't backwards compatible 
> though.
> 
> There seemed to be agreement that this was reasonable, but its not clear 
> how to do it exactly. More discussion is needed.

Adding a NACK will break backwards compatibility, so that rules it out.
Adding a new header, while better than adding NACK, still means more code
to add and one more header to keep track of.

I like the first approach -- ACK the 2xx, disabling all media streams.  The
disadvantage it has over the new header option is that more signaling is
needed in the form of a re-INVITE.  However, I do not understand your 
concern on the re-INVITE failing?  If the session was established 
successfully, and a subsequent attempt to renegotiate it failed, why will 
the re-INVITE fail if the same SDP as the successful session was being used 
in the re-INVITE?

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Kim Liu <[email-masked]>
Date: Thu, 23 Aug 2001 13:59:10 -0400

> to do it exactly. More discussion is needed.

Mmm.  I would probably say it needs to be in the SDP,
probably as an attribute.  The attribute should indicate
what the desire behavior is in failure cases, perhaps on
a per media stream basis.  The behavior could be to fall
back to the previous state, to go on hold pending further
renegotiation, or to hang up/send a BYE if the stream 
cannot be established.  (The last might be useful only
in a handful of cases.)

Having it on a per media stream would allow for
re-INVITEs where the audio stream was marked to
fall-back if there was a problem with negotiating
the audio stream, but for the video stream to 
go on hold if there was a problem with the video
stream.  

Being able to indicate to go on hold rather than
falling back to the previous media stream state
might be important in cases where the media
stream is going down/changing immediately due 
to outside reasons, and that trying to re-establish
an RTCP stream to the prior state could result
in a network unreachable condition -- some 
endpoints might interpret that as an indication
to hang up the call.  If the call should be
hung up if the new SDP cannot be accepted
and because the old one is already known to
be no longer useable, then that could be indicated
by the explicit "Send BYE" as opposed to the
"fall back" or "go on hold."

Kim

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 23 Aug 2001 15:11:24 -0400

How can it happen that B provides an offer that is not acceptable to A
provided the UA complies with the first paragraph of B.4 in bis-04?  If
B does want to change, it should issue the re-INVITE.  A can reject this
media with a 488 and the session remains as it was.  Am I missing
something here?  (I'll admit, I don't know of a scenario off hand where
a UA would re-INVITE without SDP to see what the other side will respond
with.)

regards,
Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Kim Liu
> Sent: Thursday, August 23, 2001 1:59 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx
>
>