Subject: Re: SIP: Forked request

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Mar 1998 02:29:30 -0500 (EST)

Scott Petrack wrote:
>> [.... forked requests with multiple OK responses....]
>>It seems we might need an ACK to indicate to the later callee what
>>happened (I assume the proxy already relayed the first response back
>>to the caller).
>
>Or are you saying that the proxy should fork ACKs just like it forked
>INVITEs?  This might lead to trouble if the OKs contain media descriptions
>but don't get back to the caller ( but it could be managed by a clever
>proxy which alters media descriptions on the fly and puts in place an RTP
>mixer or a unicast/multicast translator).

In this case, I don't think the ACK is really acknowledging the call;
there would need to be some kind of header field which says "Oops;
forget about it, the line has already been picked up". This pretty
much seems like a BYE, though, not an ACK.

An issue with sending a BYE from the proxy is that later on down the
road, the BYE may also fork and arrive at the original callee too. Thus, both 
recipients will think the call has been terminated.

One possible fix would be that recipients always include a Location:
header in their response indicating their SIP URL. When the duplicate
response arrives at a forking proxy, it sends a BYE to the SIP URL in
the Location field, not the SIP URL in the To: field. This should (will
it?) make the BYE be directed to the specific party who sent the second
ACK.

Clearly the *natural* behavior would be to create a multiparty call,
but I just don't see any reasonable way to accomplish this.

Another possible mode of operation is for the forking proxy not to forward
back a 200 OK as soon as it gets one. Instead, it can wait some amount
of time, and if it gets multiple 200 OK's, it can return a 3XX Multiple
Choices to the caller listing those choices. It can then send a BYE 
to the callee's canceling the original call.

I do agree with Scott that their should be multiple possible
behaviors at a proxy, allowing for an administrator to define new
services. However, we need to be sure that SIP has everything it
needs to be able to accomplish a reasonable behavior in this scenario.

-Jonathan R.

>
>Surely what happens in a forked request must be a matter of local
>preference -- what the callee wants his/her proxy to do. Each of the
>solutions offered so far is reasonable in certain circumstances, and
>doesn't require the spec to be altered.
>
>The only open protocol issue I see is if there needs to be some indication
>in the INVITE message that this is a forked INVITE.  I think that this
>might be nice for unicast INVITEs, but I'm not sure that it's necessary.
>
>Scott

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 31 Mar 1998 12:36:18 -0500

Mark Handley wrote:
> to the caller).  Under these circumstances, it should probably be up
> to the callees to decide the correct course of action, and handle this
> using call-transfer functionality if necessary.

Jonathan Rosenberg wrote:
> [....]

I feel that the caller (not callee) should decide if he/she wants to
talk to a single person or to everyone who answered the call - only the
caller knows the intention of the call, after all. To allow this, the
proxy should propagate all 200 OK responses back to the caller and then
the caller decides whether to ACK those responses or to send a BYE. It
doesn't seem to be a very big change to caller software since it needs
to handle duplicate responses anyway (e.g., duplicate UDP packets). It
would also be nice if the caller could decide to which of the callees to
talk. I realize that all this looks very much like a multicast response
to a unicast request so maybe we could borrow some details of multicast
functionality.

However, I agree that creating a multiparty call is the natural behavior
in most cases. One option here is for the proxy to send a BYE with an
Also field set to the address of the original caller to all callees
after the first one. This way, the later callee sends an INVITE back to
the caller and, since INVITES to ongoing calls are accepted silently,
joins the call without even notifying the caller. The proxy could also
be configurable to recognize some local addresses (e.g., sysadmin) as
"reply-first".

> to the callee's canceling the original call.

This sounds like a natural thing to do. And if the proxy gets an
additional 200 OK after it timed out and forwarded the first 200 OK to
the caller, it could still forward the second 200 OK and let the caller
decide what to do.

---
Igor Slepchin