Subject: Re: Forking and unwanted/unexpected 200 responses for INVITE (was Re: 183, BCP & forking)

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 20 Nov 1999 19:17:59 -0800 (PST)

--- Jonathan Rosenberg <[email-masked]> wrote:
<... snip>
>   This actually causes a forking situation since phone B's
> > 200 response for INVITE could cross on the wire with the CANCEL.
> > Thus 200 responses for INVITEs could be received from both B and C.
> > 
> > Here are four solutions dealing with forking:
> > 
> > 1) Phone A (or SIP end node for phone A) would have to send ACK
> > and BYE for unwanted or unexpected 200 responses for INVITE.
> > I think that this solution best fits the current SIP draft.
> 
> I expect this to be the behavior in 99% of the cases.
> 

I agree, it makes sense to let the UAC make the selection. But, this
may not be desirable to Users who dont want to be bothered with making
selections after they placed the call.
  
> > 
> > 2) Allow proxy servers to send BYEs.  People have mentioned that
> > this causes problems concerning the CSeq and encryption.
> 
> Yes, this definitely causes problems.
> 

I dont know what the Cseq  and encryption problems are. Can you elaborate?

I imagine, if the proxy has knowledge of user profile (i.e., preferences), 
and the proxy is empowered to make a selection on behalf of the user, the 
proxy might do almost as good a job as the UAC. This might actually be a
good approach to pursue in a lot of situations. 

Jonathan - what other problems are you alluding to?

> > 
> > 3) Allow a CANCEL to trigger a BYE from C if C has sent a 200
> > response for the corresponding INVITE.  This action is not specified
> > in the SIP draft, but I have not heard a reason against
> > this solution (although I assume someone could inform me).
> 
> The difficulty is that this fundamentally changes the semantics of
> CANCEL. CANCEL does not mean hang up, it means "terminate search".
> Consider a typical case. Forking proxy P sends 2 INVITES. It gets a 200
> OK to one, and then sends CANCEL to the other. Unfortuantely, this
> CANCEL, downstream from the proxy, gets forked again and reaches the UA
> which responded with that 200 OK. Now, according to your proposal, this
> would cause the call to be hung up. This is not the desired behavior in
> this case.

I fully agree with Jonathan. This is a total change of CANCEL semantics.
Whoever (Proxy or UAC) generated the CANCEL could send BYE instead.
  
> 
> Handling of multiple 200 OK is best left to the UA, since it can hang up
> with the additional 200 OKs, as you mention above. Or, it might even
> initiate a conference call. However, only the UA can know which to do.
> 

Interesting. Are you suggesting that conference calling (with callee's home
phone no., mobile phone no. and work no.) could be a free by-product of 
call forking? And, the caller gets to decide whether to do conference 
calling or select a line, after he/she hears from all callee locations? 
This is clearly something a proxy cannot decide on behalf of the UAC.
 
> 
> > 
> > 4) Allow the proxy server to drop unwanted or unexpected 200 responses
> > for INVITEs.  I would not like this solution since I assume not receiving
> > an ACK could still allow it to remain in the call.
> 
> This isn't guaranteed to work, since only a stateful server can do this.
> If a proxy, after receiving a 200 OK, goes stateless, and then receives
> another 200 OK, it will be forwarded. In any case, I'd rather let the
> end systems decide on the right behavior.
> 

Assuming you have a stateful proxy that is tracking the responses, I guess,
it is a way to not acknowledge the unexpected/unwanted 200 responses.
It would work. 
I agree, this is at the cost of giving grief to the callee UAS and 
certainly not a recommended practice.
   
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> 

regards,
suresh
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 1999 15:15:38 -0500

> selections after they placed the call.

I does't need to be exposed to end users. The phone can automatically
send BYE for the unwanted 200's, completely unbeknowenst to the actual
user.

> I dont know what the Cseq  and encryption problems are. Can you elaborate?

The CSeq space is defined to be unique within the Call-ID, To, and From.
A proxy that tries to send a BYE needs to have the same value of the
Call-ID, To, and From as the INVITE. This means both a proxy and a UA
will need to select CSeq numbers from the same space. As these are often
chosen in increasing order, there is a very likely possibility that a UA
sends a re-INVITE with the same CSeq as a BYE sent by the proxy. This
totally fouls things up, since now there are two requests with the same
To,From,Call-ID and CSeq, but with different methods. These cannot be
ordered correctly, and the result will be inconsistent call state across
all parties.

There is also a security problem. In the current model, the requests are
signed by the UA. Thus, we can use things like PGP to sign requests, as
a person can easily build up a keyring of keys from other users they
talk to. However, if we assume a UA only accepts signed requests, it
would need to accept BYE requests signed by proxies. There are lots of
proxies, and there is no way a user can be expected to have keys (and
trust) all of them that might appear on a call path.

We've been through this discussion before, and consensus was clear that
proxies cannot send BYE.

> This is clearly something a proxy cannot decide on behalf of the UAC.

Yes, the caller (or his UA) gets to decide. Note that the conference
call is not "free". The result of multiple 200 OK is N point to point
conversations, where N is the the number of 200 OK. Using call control,
the calling party can turn those into a conference call if they like.

-Jonathan R.