From: "Attila Sipos" <[EMAIL PROTECTED]>
There is even an IETF draft which discusses
the problems with UAs inappropriately sending
6xx responses.
Title : 6xx-Class Responses Considered Harmful in the
Session Initiation Protocol (SIP)
Author(s) : D. Worley
Filename : draft-worley-6xx-considered-harmful-00.txt
Pages : 12
Date : 2007-2-26
As people have noted, the problem is that the UA, in sending 6xx, is
asserting that no other branch of the call can be successful. But in
general, the UA *cannot* know that, since there may be multiple forks
upstream -- if the UA is [EMAIL PROTECTED], that is, serving extension
1234 at the address 10.1.1.1, it may be possible for the UA's user to
know that no other destination for [EMAIL PROTECTED] should be
contacted. But it does not know that the call was originally made to
[EMAIL PROTECTED] (Although I suppose it could check the From:
header.) and so it cannot know that no other fork can be successful.
There have been proposals for a "scoped" rejection, allowing the UA to
reject the call on behalf of all other forks of its immediate AOR
(sip:[EMAIL PROTECTED]), but no further forks upstream. Unfortunately,
I haven't seen much discussion about them, and it is difficult to
implement it in an upward-compatible way.
draft-ietf-bliss-ach-analysis-02 touches on a lot of these issues,
too, and is probably the best current path toward resolution.
In the project I work on, the sipX (open-source) PBX system, we've
adjusted the proxy to treat 6xx responses as 4xx to avoid this problem
(especially in order to ensure that if a P*lyc*m phone responds 603
Decline that the call will still go to voicemail, which is what the
users want). I suspect that in the future, proxies will automatically
translate 6xx responses into 4xx responses when forwarding them
upstream.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
