Subject: Proxy questions

From: Shail Bhatnagar <[email-masked]>
Date: Wed, 10 Nov 1999 14:23:34 -0500

I have some doubts/questions about the behavior of the proxy. I 
apologize in advance if they have been addressed in the spec and I 
have overlooked .

1. How should a stateful proxy handle a BYE if he is in the following
state :
(a) Final response has been received on some branches ( non-200 and
non-6xx)

(b) No response has been received on some other branches.

(c) Provisional response has been received on another set of branches.

2. The spec says that :
"a BYE request is forwarded like a an INVITE request"

Let us assume that a stateful proxy sets up a call between 2 parties.
The 2 parties talk and now :

Originator of INVITE sends BYE to the Contact he received in
the 200. This Contact happens to be the stateful proxy. Is the proxy
supposed to remember the contact address of the client ( which he
got from some location service while forwarding the INVITE in the first
place) or just treat this as a new request and not worry about any
prior information about this client. 

3. Finally some questions about a user agent :
(a) UA sends INVITE, never gets any response and decides to end the
call. Should he send CANCEL or BYE or nothing ?

(b) UA sends INVITE, receives provisional response and decides to
end the call. Should he send CANCEL or BYE ?

-- 
Best regards,
Shail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 16:52:28 -0500

> 1. How should a stateful proxy handle a BYE if he is in the following

Proxy handling of BYE has nothing to do with call state whatsoever. 

> (a) Final response has been received on some branches ( non-200 and

forward the BYE to the next address in the Route header. If none is
present, use a location service on the request-uri, just as if it were
an INVITE.

> (b) No response has been received on some other branches.

forward the BYE to the next address in the Route header. If none is
present, use a location service on the request-uri, just as if it were
an INVITE.
> (c) Provisional response has been received on another set of branches.

forward the BYE to the next address in the Route header. If none is
present, use a location service on the request-uri, just as if it were
an INVITE.

> the 200. 

No - you are forgetting about record routes. If the proxy received the
BYE, its because it was record routing. In this case, the BYE arrives
with one more Route header, which is the value copied from the Contact
header in the 200 OK to the INVITE.

This Contact happens to be the stateful proxy. Is the proxy
> prior information about this client.

see above rule.

> call. Should he send CANCEL or BYE or nothing ?

This was discussed during the meeting. Its up to the implementation. 

> end the call. Should he send CANCEL or BYE ?

Also up to the implementation.

-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

---

From: Shail Bhatnagar <[email-masked]>
Date: Wed, 10 Nov 1999 17:22:11 -0500

> header in the 200 OK to the INVITE.

Jonathan, Are you saying that a proxy will receive a BYE only if 
record-route is used ? I can think of a scenario when proxy receives
a BYE even though no record-route was used. Am I wrong in my 
thinking ?

         Firewall
UA1 ------ Proxy ------ UA2

UA1 send INVITE and firewall proxy forwards it to UA2 without 
a Record-Route header. UA2 returns a 200 with a Contact header
containing the address of the firewall proxy. Won't the proxy 
see the BYE ?

-- 
Best regards,
Shail

---

From: Shail Bhatnagar <[email-masked]>
Date: Wed, 10 Nov 1999 17:25:16 -0500

Jonathan Rosenberg wrote:

> present, use a location service on the request-uri, just as if it were

Does this mean that even a BYE request can potentially be forked 
because location service can return 300 Multiple choices ??

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 17:35:20 -0500

> containing the address of the firewall proxy. Won't the proxy

But why? Contact is supposed to be used for the user agent, not the
proxy. If you want this proxy firewall to get BYEs, use record route.
Then, you won't have any problems, since the Route header will tell the
proxy where to forward the packet. 

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Nov 1999 17:37:05 -0500

> because location service can return 300 Multiple choices ??

Yes. Any request can be forked. The response is the best one received,
as defined in the spec. If you don't want to do this (forking the BYE is
not that useful here), use Record-Route in the proxy, rather than having
the UAS insert a Contact header pointing to the proxy. Granted, you
*can* do that, but then you should make sure your forwarding logic in
the proxy/firewall can get the BYE to the right place.

-Jonathan R.

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 11 Nov 1999 09:25:22 -0500

Jonathan, Thanks for your quick responses. So, to summarize our 
exchanges :
(a) Since Contact is a MUST in INVITE and 200, either the BYE will go
directly to the user agent ( without record-route).
     
OR

(b) With Record-Route it will come to the proxy.

OR

(c) If the caller decides to send a BYE before receiving a 200 
from the callee, the BYE would be handled by the "originating" proxy,
just as the corresponding INVITE was handled.

Regards,
Shail

Jonathan Rosenberg wrote:

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Nov 1999 10:04:53 -0500

> just as the corresponding INVITE was handled.

Not just the originating, but all proxies that might receive this
INVITE. Note that this might result in the BYE not being routed along
the same path as the INVITE. In unusual cases, this could cause
inconsistent call state, if the BYE never reaches a host that got the
INVITE. This was discussed during the meeting. There are solutions, and
the problem can be avoided altogether by sending CANCEL until a 200 OK
comes, and after that, sending BYE.

-Jonathan R.