Subject: [SIP] Re: Lessons learned...

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 17:30:05 -0400

Igor Slepchin wrote:
> 
> "Adam B. Roach" wrote:
> >
> >    - 408 vs 504
> >
> >        408 is to be used when a request cannot be completed in the
> >            time specified in the "Expires" header.
> >
> >        504 is to be used when a proxy or other type of gateway
> >            doesn't receive a response from a next-hop node.
> 
> That sounds fine except that the current description of 408 is too
> restrictive. I think 408 should also be sent when a proxy gives up
> waiting for a final response due to some internal timeout (e.g., after a
> 1xx is received, INVITE transactions hang around forever unless some
> timeout is configured for them). 504 should only be used when no
> response whatsoever was received from a next hop.

Actually, I had a different interpretation of 504. 504 is when a proxy
tries to contact some other service, like a location server, and that
service does not respond. Thats why its a server failure; the other
service represents part of the operation of the server itself (many
folks include the location service within the proxy, for example). Thats
why its 500 class.

Also, I agree with Igor that 408 is used when a proxy gives up. Be
warned about this, however. Lets say a proxy forwards some request, gets
a 100. It then times out, and sends a 408. Unfortunately, the next hop
server then responds with a 300. Kind of too late... THe ideal solution
here is that when the timer expires, the proxy sends a CANCEL. This
should cause an almost immediate final response to the original request,
which can then be forwarded, or a 408 generated. This is safer, in the
sense that the server knows what the response from downstream is. Of
course, it gets more complicated if the CANCEL does not generate a
response to the original request. In this case, you are dealing with (1)
a UA which does not respond to the original request with 487 upon
receiving CANCEL, since you do not have to according to rfc2543, or (2)
some kind of downstream failure. In either case, you are much safer in
generating the 408. 

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Apr 2000 17:44:21 -0400

"Adam B. Roach" wrote:

>    - 480 vs 603
> 
>        480 indicates that the user is, for some reason, unavailable.
>            This would be appropriate, for example, if a phone
>            is in a "do not disturb" mode.
> 
>        603 means that the user you are trying to contact has been
>            reached, and has explicitly declined this particular
>            phone call. This would be appropriate if, for example,
>            your device/program displays the name of the caller,
>            and the called party presses a "reject" button.
> 
>    486 vs 600
> 
>        486 is a device busy state. This is what you normally think
>            of when you get a busy tone.
> 
>        600 is a user busy state. There is no analogous situation in
>            today's telephony system. It means that you have
>            contacted the correct user, but he has indicated
>            that he will not take the call because he is busy.
>            It is completely inappropriate to return a 600 for a
>            device busy state, since it termintates outstanding
>            searches.

Absolutely correct. The big difference between 400 and 600 is search
termination.

> 3) This is actually a disagreement I have with RFC2543, and
>    one that I raised some time ago; however, no one seemed
>    interested at the time. Since it actively prevented us from
>    running one of the test cases we wanted to run at this bakeoff,
>    I'm going to raise the issue again. Take discussion on this
>    topic to the SIP working group mailing list, please.
> 
>    According to section 6.37, an implementation should reject
>    messages containing unknown URIs in the "To:" field with
>    a 400 response. Many implementations actually did this.
>    The test case we were attempting was as follows:
> 
>    UAC1 ----> tel: mapping proxy -----> UAC2
> 
>    UAC1 then sends a message to the tel: mapping proxy like:
> 
>      INVITE tel:5551234 SIP/2.0
>      To: <tel:5551234>
>      From: <sip:bob@uac1>;tag=12345
>      Call-ID: fffff@uac1
>      CSeq: 7654 INVITE
> 
>    Because the proxy mapped the request URI, the INVITE that
>    UAC2 received ends up looking like:
> 
>      INVITE sip:5551234@uac2 SIP/2.0
>      To: <tel:5551234>
>      From: <sip:bob@uac1>;tag=12345
>      Call-ID: fffff@uac1
>      CSeq: 7654 INVITE
> 
>    UAC2 definitely has quite enough information to service the
>    call. In fact, if not for this clause in 2543, the call would
>    be set up perfectly. I contend that clients shouldn't
>    care if they understand the URI in the To: field, as long
>    as they can process the call, and I encourage implementations
>    to exhibit this behavior.
> 
>    This also follows naturally from what I suggested above: don't
>    validate fields unless you intend to use the information
>    contained in them.

Hmm. This is a good point. Given the increasing use of tel URLs, its
probably worth changing this in rfc2543bis. This doesn't introduce
backwards compatibility problems; it just means that calls to UAs
compliant to the bis version will get set up successfully, when they
won't with rfc2543.

In general, the *request URI* is what is important in processing a
request. The To field is used only for (1) call leg identification
(along with From and Call-ID), and (2) FYI to the called party. The
request URI represents the desired user at the server being contacted.
The To field may contain a URI which is meaningless within the namespace
served by the server. 

Thanks for putting these lessons learned together. They should be
incorporated into the FAQ.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Apr 2000 13:40:43 -0400

"Adam B. Roach" wrote:
> 
> Jonathan Rosenberg writes:
> >Also, I agree with Igor that 408 is used when a proxy gives up.
> ...
> 
> I have no problem with this model; it does, however, require that
> the description of 408 be updated in RFC2543bis.

Current (modified) wording is:

The server could not produce a response, e.g., a user location, within
the time indicated in the \header{Expires} request-header field.  The
client {\MAY} repeat the request without modifications at any later
time.

Please suggest improvements.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 24 Apr 2000 11:14:25 -0500 (CDT)

...

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 24 Apr 2000 13:34:01 -0500 (CDT)

The server could not produce a response, e.g., a user location, within
a suitable amount of time.  This may be due to the time indicated in the
\header{Expires} request-header field or by the expiration of an internal
timer in the server.  The client {\MAY} repeat the request without 
modifications at any later time.