I can't decide where to reply in this thread, so I'll just do it here.
(I've read a bunch of replies.)
There definitely are problems with 6xx - partly defintional and partly
inappropriate use. But IMO there is need of a way to express stronger
rejections than is possible with the existing 4xx responses.
More inline.
Iñaki Baz Castillo wrote:
> 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 !!!
So why did the one instance reply with 6xx rather than 4xx? Was it just
whim? Or did it want to express a different policy?
It may well be that the user at that one extension noticed the caller id
was that nasty bill collector that he doesn't want to talk to. So he
pushed the "reject this call totally" button, and that resulted in the
6xx response. Not sending the call to VM is exactly what was intended.
Could there be another way to accomplish this? Yes. But this is the best
we have at the moment. The BLISS group is tackling this at the moment.
Paul
> 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?
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
