Subject: RE: [SIP] Forking proxy behavior with multiple 200s

From: "Bratakos, Maroula" <[email-masked]>
Date: Fri, 30 Mar 2001 09:42:12 -0800

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 9:32 PM
> To: Bala Santhanam
> Cc: [email-masked]; Shriram Natarajan
> Subject: Re: [SIP] Forking proxy behavior with multiple 200s
> 
> 
> Bala Santhanam wrote:
> > 
> > Hi,
> > 
> > What should a forking proxy do with consecutive 200 OKs 
> coming from two
> > different addresses? Can the proxy generate an ACK and BYE 
> the rest of the
> > [200] responses after accepting the first arriving 200 response?
> 
> Nope; a proxy MUST send ALL 200 OK (INVITE) upstream.  The idea here
> is that the proxy is not the arbiter of multiple responses to 
> a request
> (even though it may have forked the request).  The final 
> arbiter is the
> UAC, which may ACK and BYE the subsequent responses.
>  
> - vijay

Isn't it advisable for a forking proxy to CANCEL all remaining requests that
it forked after it receives a 200 OK from one of the forked branches?
Wouldn't this imply that there is no need to forward all 200 OKs upstream,
only the first one?  This is according to Bis-02, section 12.4.

-Maroula Bratakos

---

From: Henry Chen <[email-masked]>
Date: Fri, 30 Mar 2001 12:15:28 -0600

"Bratakos, Maroula" wrote:

> Isn't it advisable for a forking proxy to CANCEL all remaining
> requests that it forked after it receives a 200 OK from one of the
> forked branches?  Wouldn't this imply that there is no need to forward
> all 200 OKs upstream, only the first one?  This is according to
> Bis-02, section 12.4.
>

But you can not cancel a 200 OK.

Henry

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 30 Mar 2001 13:47:12 -0500

> Isn't it advisable for a forking proxy to CANCEL 
> all remaining requests that it forked after it 
> receives a 200 OK from one of the forked branches?  
> Wouldn't this imply that there is no need to 
> forward all 200 OKs upstream, only the first one?  
> This is according to Bis-02, section 12.4.

The proxy should let the originating UA 
decide how handle second 200.  The proxy 
should not hijack the originator's CSeq 
numbering (especially if the proxy didn't 
Record-Route).

The bis no longer covers anything dealing with 
remote-ringback effects on forking.  It is an 
open issue that will be addressed in a 
remote-ringback document. 

Deciding to CANCEL a branch of a 
forked call depends on why forking was performed.
If someone calls [email-masked], the 
INVITE should be forked to all registered numbers 
for the family.  It is now the originating UA's 
decision about how to handle the subsequent 
call-legs that resulted from forking.  The extra 
call-legs can be conferenced, released, held, etc.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.