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
The specification of the Session Initiation Protocol (SIP) permits a
user agent (UA) that receives a call to generate a response in the
"6xx class" that not only rejects the call but also requires the
termination of all attempts to route the call to alternative
destinations. As the call may have reached the UA through multiple
forwardings whose meanings cannot be known by the UA, the global
termination of alternative routing can only rarely be correctly
requested by the UA. Because such responses are almost never
appropriate, ability of a UA to generate such responses is harmful,
and all 6xx class responses should be replaced with 4xx class
responses with similar meanings. However, there is no 4xx class
response similar to "603 Decline", and so one needs to be created.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos
Sent: 03 June 2008 09:22
To: Iñaki Baz Castillo; [email protected]
Subject: Re: [Sip-implementors] Why does 6XX break a serial forking?
>>6XX behaviour is really painful.
>>I realy wonder why they break serail forking:
To me, 6xx means the user you're trying to reach doesn't exist anywhere or
won't accept your call anywhere or can't accept your call anywhere.
So, it doesn't matter if you try another fork because it won't work anyway.
4xx however, (usually) means that the problem is localised at or near to the
endpoint that you're trying to reach. So if you fail on one fork, you can try
another.
Now, it could be that an endpoint is sending a 6xx response when it should only
be a 4xx (but that's another issue).
Regards,
Attila
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
Castillo
Sent: 03 June 2008 08:41
To: [email protected]
Subject: [Sip-implementors] Why does 6XX break a serial forking?
Hi, IMHO 6XX behaviour is really painful. I realy wonder why they break serail
forking:
* Cool behaviour (with no 6XX):
- A calls B via their proxy.
- Proxy does parallel forking and 4 instances of B ring.
- All of them reply a 4XX (Busy, Not available...).
- Then the proxy generates a new branch for the INVITE and sends it to the
voicemail server.
* Painful behaviour (using 6XX):
- A calls B via their proxy.
- Proxy does parallel forking and 4 instances of B ring.
- 3 instances reply a 4XX and the other replies a 6XX.
- The proxy has received a 6XX so it MUST NOT create a new branch to forward
the request to the voicemail server !!!
RFC3261
6 Definitions:
Sequential Search: In a sequential search, a proxy server attempts
each contact address in sequence, proceeding to the next one
only after the previous has generated a final response. A 2xx
or 6xx class final response always terminates a sequential
search.
Isn't it painful?
--
Iñaki Baz Castillo
[EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
