Subject: RE: [SIP] SIP and soft hand-off

From: "Roy, Radhika R, ALARC" <[email-masked]>
Date: Mon, 17 Apr 2000 09:15:09 -0400

Hi, Rohan:

Pl. see my comments below <RRR>.

Thanks,
Radhika R. Roy
AT&T

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Friday, April 14, 2000 11:38 PM
To: Roy, Radhika R, ALARC
Cc: [email-masked]; [email-masked]
Subject: RE: [SIP] SIP and soft hand-off

At 05:39 PM 4/14/00 , Roy, Radhika R, ALARC wrote:
>Hi, Everyone:
>
>My comments are as follows:
>
>1. We are extending SIP to support mobility in the application layer. So,
>SIP WG is the right place. The SIP WG is the only group that knows what to
>do the SIP protocol in the application layer.

Hi,

Who is the "we" here?  To be specific, has this been formally included as a 
topic for the SIP WG?  If so, I doubt that anyone assumed soft-handoff 
would be considered as part of the scope of "mobility".

<RRR> "We" means the members who are interested for extension of SIP to
support mobility as some discussion was held based on the internet draft in
the last IETF meeting. Yes, "soft-handoff" may not be a part of SIP mobility
if it does not affect the application (i.e., SIP) layer resources.

thanks,
-rohan

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Provin Gurung" <[email-masked]>
Date: Mon, 17 Apr 2000 10:57:37 -0400

Hi,
 I have a question regarding the behavior of proxy on receiving a CANCEL.
Consider, a forking Proxy received an INVITE and it forked and forwarded the
INVITE to multiple servers downstream, Now along comes a CANCEL from an
upstream client.  The proxy is supposed to fork and send the CANCEL to the
branches which have not yet responded.

How should the proxy react,
(a) if it already received a 2xx response from one of the downstream
branches, (This would be if the final response from the proxy to the
upstream client and the CANCEL crossed over each other.)
- I guess it should be 481 (Transaction not found)

(b) The proxy has not received  2xx nor 6xx from any branches.
Should the proxy send back a 2xx for the CANCEL  immediately and not care
how the downstream servers respond to the CANCEL that is forked by this
proxy, or should it wait till the unfinished branches respond to the forked
CANCEL and then depending on this result send back a CANCEL, i.e. the proxy
send back a 200 CANCEL upstream if the proxy receives a 2xx for all the
forked CANCEL from all it's branches, or maybe proxy the 2xx for INVITE, if
one of the branches respond with 200 for INVITE  ( cross over for the forked
INVITE and forked CANCEL in one of the proxy) and resonpond say 481 for the
CANCEL.

If the proxy responds immediately with 2xx for CANCEL, it is possible that
the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE
(Taking into consideration , that if a Proxy receives a 2xx for INVITE from
one of the branches, after it has sent a 2xx for CANCEL upstream, it still
forwards the 2xx for the CANCEL to the upstream client). How does the UA
handle this case.

Sorry for not keeping it short, I tried to look up the rfc but could not
find it discussing the above scenario.

Thanks in advance,
Provin

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy, Radhika R, ALARC
> Sent: Monday, April 17, 2000 9:15 AM
> To: Rohan Mahy

---

From: Igor Slepchin <[email-masked]>
Date: Thu, 20 Apr 2000 14:53:22 -0400

> - I guess it should be 481 (Transaction not found)

It should send back a 200 OK; no error occurred in this case. 481 is
sent when the proxy receives a CANCEL for a transaction it doesn't know
anything about. Note that the CANCEL still needs to be proxied even in
the latter case.

> proxy, 

Yes. CANCEL requests are hop-by-hop.

> the initiating UAC receive both a 2xx for the CANCEL and 2xx for INVITE

Absolutely. The spec actually says that the UACs must be prepared to
handle this.

> find it discussing the above scenario.

See sections 4.2.5, 12.4 in 2543bis.

---
Igor Slepchin