"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.
--
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (732) 741-4778
http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244
http://www.dynamicsoft.com
