The difficulty with giving a 6xx response is that it can muck up forking *upstream* of the element that generates the 6xx response.
Consider typical example: AOR sip:[email protected] is forwarded to AOR sip:[email protected] and then serially forks to 1234's voicemail, sip:[email protected]. At proxy B, AOR sip:[email protected] is forwarded (incorrectly) to sip:[email protected], with no other targets. (And while we're at it, let us note that "invalid-domain.net" is *NOT* reserved by RFC 2606. Indeed, whois reveals that it is registered by Ludger Keilig of Bonn, Germany.) The desired behavior is that a call to sip:[email protected] will eventually arrive at sip:[email protected]. When an INVITE is sent to sip:[email protected], it will first be forked by proxy A to sip:[email protected]. Proxy B will attempt to fork the INVITE to sip:[email protected]. The problem to be answered is: What response code should proxy B give to proxy A? If proxy B gives a 6xx response, then by RFC 3261, section 16.7, item 5, page 109, proxy A may not serially fork the INVITE to sip:[email protected]. but if proxy B gives a 4xx response, proxy A continues the forking of the INVITE to sip:[email protected]. This pattern generalizes to all situations where 6xx responses have been proposed, which shows why 6xx responses should never be used. See draft-worley-6xx-considered-harmful-00 (dated Feb. 2007). Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
