Subject: [SIP] BYE at the callee through proxies

From: Dvir Oren <[email-masked]>
Date: Fri, 21 Jul 2000 00:41:29 +0300 (IDT)

I don't understand to whom a callee should send its
BYE to.  Should it do a user lookup on the From 
SIP URL?  What happens if there are any proxies
that need to be informed along the way?

For the caller - this is simple.  It receives
the Record-Route, which is then translated to
Route on the ACK, and can be saved for the BYE
(Though this may be implementation difficult
since after sending the ACK, it should have removed
the first Record-Route, though it needs it for the 
BYE).

But the callee theoretically doesn't have this
information.  By the time it receives the ACK,
there will be no Route information.  It can,
save the Record-Route information from the
200 Success, and then turn it into Route 
(without reversing the order), though I don't
see this in the RFC.

It seems like the only thing a callee knows
is either the From SIP URL (what happens if
the URL is incorrect, or the hostname there is
not known at the callee?), in which case it will
have to do a user lookup to find how to reach the URL,
and hopefully it will travel through the same procies,
though not necessarily.  Or it has saved the Contact
that the caller gave it (if it gave a Contact), in
which case the BYE will definitely not travel
through the proxies.  Or it can try to use the 
Record-Route information, which will
contain the wrong user!

Can anybody tell me how is the callee supposed to know
to whom to send the BYE to?

-- 
Dvir Oren               <[email-masked]>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 21 Jul 2000 09:57:44 +0100

> BYE to.

The Contact address -- this is now mandated in the bis draft.

> Should it do a user lookup on the From 
> SIP URL?

I guess in the absence of a Contact address, this is probably
the best it can do.  (I'm assuming that by "user lookup" you're
talking about the rules in 1.4.2.)

> What happens if there are any proxies

No problem, the Record-Route mechanism works just fine.

> the first Record-Route, though it needs it for the 

I don't understand this.  Basically, the client should
be maintaining some sort of state on the Call-Leg, and
include the Record-Route seen in the 200 (or whatever)
with this state.

The server should do similar (it will see the Record-Route
in the initial INVITE).

> (without reversing the order), though I don't

See paragraph 4 of section 6.35.2 of the most recent bis
draft.

> through the proxies.

It will if Record-Route was specified, and the callee
appended the Contact header value to the Route header
list, as detailed at the end of 6.35.2.

> Or it can try to use the Record-Route information,
> which will contain the wrong user!

Yes, but that is handled by the paragraph 4 mentioned
above.

HTH,

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Jul 2000 02:42:37 -0400

> talking about the rules in 1.4.2.)

No, no. When Record-Route is there you will be sending to one of the
addresses in the record-route list.

Dvir's question is coming up because RFC2543 doesn't specify how the UAS
builds a Route header. It only talks about UAC. The bis draft explains
the process for UAS, 6.35.2, which needs better wording but gets the
idea across.

The route, in the end, is based on Contact in the INVITE + Record-Routes
in the INVITE.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Dvir Oren <[email-masked]>
Date: Sun, 23 Jul 2000 12:01:20 +0300 (IDT)

> the process for UAS, 6.35.2, which needs better wording but gets the

The main problem with the bis, as far as I see it, is that I can't
easily compare it to the RFC.  There is no TOC to compare new
sections, and changes in text inside the bis can't be compared at all.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Jul 2000 09:09:52 -0400

> sections, and changes in text inside the bis can't be compared at all.

I'm not sure which version you are looking at, but the PostScript and
PDF versions of the 2543bis document contain changebars indicating where
changes have been made. In addition, all versions, including the ASCII
versions, include a table of content (at the end, in the case of ASCII,
due to the limitations of nroff) and an annotated list of substantive
and clarification changes (ignoring the minor bug fixes).