Subject: Re: SIP: Forked request

From: "Scott Petrack"<[email-masked]>
Date: Sun, 29 Mar 1998 04:00:49 +0200

> [.... 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).

Are you saying that a single unicast INVITE might result in multiple
returned OK responses and that the caller should ACK each one? I always
assumed that a client which sends a unicast INVITE request will only
receive at most a single unicast OK response, even if the INVITE gets
forked around creation by some proxy.  Is this mistaken?

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).

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

[email-masked] on 03/27/98 09:02:14 PM

To:   [email-masked]
cc:   [email-masked], [email-masked] (bcc: Scott Petrack)
Subject:  Re: SIP: Forked request

>On Mar 27, 12:46pm, Henning Schulzrinne wrote:
>> Subject: SIP: Forked request
>> Problem: What happens if a forked request produces multiple
>> 2xx responses if several people ``pick up the phone''?
>>
>> Suggested resolution:  Proxy should send a BYE to the late comers.
>
>That is dirty.  There should be a way to solve it through by forking
>multiple "probes", then following on with a real invite.
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).  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.
Cheers,
     Mark