2011/4/26 Worley, Dale R (Dale) <[email protected]>: >> From: Iñaki Baz Castillo [[email protected]] >> >> But, why should a proxy generate a new branch after receiving a 404? > > Because that is a ubiquitously-used mechanism in SIP -- if the attempt > to reach one contact point or destination fails, the call is then > routed to another, lower-priority, destination. E.g., if you don't > answer a call on your desk phone, then the call is routed to your > voicemail recorder.
Dale, I do know how serial forking works. Serial forking makes sense when the tryed branch fails due to a real "error" (500/503/408/timeout...), but not on a 404. Of course, it could occur that in a custom/specific scenario it makes sense to perform failover upon receipt of a 404 but it's not usual in PSTN scenarios. >> And in case the proxy wants to do it upon receipt of a response >> "destination doesn't exist", why should a 6XX avoid it? > > Um, you have read RFC 3261 regarding the handling of 6xx responses, > haven't you? Yes, I think you didn't understand what I mean: - A proxy routes a request to a destination and wants to do failover to other destination if the call receives a status code of "destination not found" (404/604). - If the first destination replies 404 the proxy is able to perform serial forking to second destination. - If the irst destination replies 604 the proxy is NOT able to perform serial forking (due to special 6XX behaviour as stated in RFC 3261 which I've read 5-10 times). My question was: why should the first destination *decide* that the proxy cannot do serial forking? why should a UAS have such "power"? It's the same case as a proxy routing a call to a user and the user replying "603 Decline". Upon receipt of such 603 the proxy is not able to generate a new branch to forward the call to a voicemail server. Obviously you know this problem as you wrote a draft about it: http://tools.ietf.org/html/draft-worley-6xx-considered-harmful-00 Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
