Subject: RE: SIP Redirect Server

From: Eric Tremblay <[email-masked]>
Date: Thu, 18 Jun 1998 20:54:34 -0400

> -----Original Message-----
> From: Mark Handley [mailto:[email-masked]]
> Sent: 18 juin, 1998 20:03
> To: Eric Tremblay
> Cc: [email-masked]'
> Subject: Re: SIP Redirect Server 
> 
> 
> >Can a redirect server redirect other requests than INVITE?  
> 
> Yes, it can.  Especially with OPTIONS or REGISTER methods.
> 
> >Or must a
> >UAC be prepared to handle a 301/302 response when sending 
> BYEs?  I don't
> >think it should, but I want to make sure, because this might cause a
> >small problem.
> 
> I don't think it makes sense to redirect a BYE, ACK or CANCEL.  If the
> server doesn't have enough information to handle one of these
> requests, I would normally expect it to return 481 (Invalid Call-ID).
 
I have a problem with BYE in the following scenario:

user A (located at station1.mediatrix.com) invites user B (which is at
term2.isi.edu).  User A's "permanent address" (where he normally
registers) is  [email-masked], which is a
registrar/redirect server and user B's permanent address is
[email-masked] (for this scenario, we don't care if isi.edu is a proxy or
redirect).

The problem happens when User A invites user B with no "Location" header
and "From: sip:[email-masked]".  If user B wants to BYE
user A, the BYE has to go trough a redirect server
(redirect.mediatrix.com), unless the From header really points to the
CURRENT location of user A.

The point here is to know if it is ok to have the From header point to
the "permanent address" of a user instead of its "current address".  I
think it should always be the permanent address.  In this case, if a
user knows that his permanent address points to a redirect server, a
Location header should always be included in an Invite (or ACK) request
(so the remote user can send BYE requests).

This is not a problem with a proxy, but I wonder if we should state
something special to take care of this case with a redirect.

> Perhaps we should state this explicitly as a general rule for 3xx
> responses?

I think it depends on what you think the solution to the above problem
is.  Have the BYE redirected? (I don't like it).
Have the From header take the value of the Current location?  I don't
like that because this rules out any way to get the permanent address
from an invitation (so you can call back...).  Strongly suggest to add a
Location header to Invites or ACK requests?  Maybe...

> Mark

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: [email-masked]
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

---

From: Mark Handley <[email-masked]>
Date: Thu, 18 Jun 1998 21:17:31 -0400

>Location header to Invites or ACK requests?  Maybe...

When the callee sends a BYE, the situation may be complicated as you
say.  I agree I don't like BYEs being redirected in this scenario.
When the request is a unicast bidirectional call, and the From field
doesn't indicate a valid host to send the BYE to, I believe a Location
field _should_ be included.  "Valid host" in this sense does not
necessarily have to be the UA-client.  It can include appropriate
proxies, but those proxies shouldn't send redirects - they should be
able to forward the BYE, probably because they are a firewall that
also routed the outgoing call.

This rule doesn't necessarily apply to all SIP requests - there are
many uses of SIP where it doesn't make sense to send a BYE back to the
originator, such as when I invite you into a public multicast session.

We should definitely include text about the expectations of the callee
to get BYE messages back to the caller.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Jun 1998 15:14:12 -0400

> something special to take care of this case with a redirect.

The spec currently allows (changed to SHOULD) a Location header for just
this purpose, as described in the motivation section Section 6.22).
However, on rare occasions (such as when the end system is mobile), not
having the Location in the invitation seems to be useful. In that case,
the redirect server tracks user location (e.g., via REGISTER) and the
callee sends a BYE to the redirect server and then to whatever the
current location of the caller is.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Mark Handley <[email-masked]>
Date: Fri, 19 Jun 1998 16:02:45 -0400

>current location of the caller is.

It would certainly simplify clients if we simply _prohibit_ sending a
redirect for BYE, ACK or CANCEL requests.  It seems that the mobile
case you describe can be handled by the proxy relaying a BYE without
needing to send a redirect.  The principle purpose of a redirect is to
_inform_ the client that the callee is elsewhere.  For INVITE, OPTIONS
and REGISTER, this makes sense as the data can be meaningfully be
cached and future requests optimised.  For a BYE from the _callee_, it
doesn't seem to make too much sense - if the caller wanted you to have
the correct location, it should have included a Location header.  If
it's mobile, that's its problem, and its proxy should deal with it and
hide it from the callee.  If you don't have the proxies relay you need
to deal with both ends moving simultaneously, which seems more
complicated than we really want to get into here.

I don't feel strongly about this - I don't think it's a really big
deal, but anything we can do to simplify the situations for regular
clients and servers seems to be a good thing.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Jun 1998 17:21:53 -0400

> clients and servers seems to be a good thing.

Simplicity is in the eye of the beholder :-) To me, having an incoming
processing loop that says

2xx: we're done, ACK it
3xx: re-issue command with new Location
456xx: failure

independent of the request issued seems pretty easy (and much easier to
extend to new methods).

To paraphrase: Anything we can do to minimize the number of special
cases seems to be a good thing :-)

---

From: Mark Handley <[email-masked]>
Date: Fri, 19 Jun 1998 17:43:14 -0400

>cases seems to be a good thing :-)

I agree in general.  But there are simply some responses we should not
expect the client to have to deal with gracefully.  

Someone calls me, and we have a conversation.  Eventually I hang up,
and my client sends a BYE.  I now get back a "300 multiple choices"
response.  To do anything useful with this my client needs to prompt
me, but that's inappropriate at this stage.  So what should it do?

This also applies to "380 Alternate Service" and "381 Ambiguous".
"302 Moved Permanently" is also inapproriate because I was talking to
the user right up until the moment I got the response, so they can't
really have permanently moved.

So that just leaves "301 Moved temporarily" as possibly being
appropriate.  Why not just state that servers MUST NOT return 3xx
responses in response to a BYE.  Then the client doesn't need special
code to attempt to handle these responses gracefully but can simply
flush state and blame the server for being broken?

Cheers,
	Mark