There may a way around it. If you can configure your proxy to know about bad UAs that send 6xx INVITE responses, then the proxy could treat those 6xx INVITE responses as 4xx INVITE responses. (Don't do this for REFER responses because most UAs use the "603 Decline" REFER response to reject a REFER)
The proxy could only do this if it KNEW it was talking to a UA and that it KNEW the UA sent incorrect INVITE 6xx responses. But with careful configuration it is possible. This isn't great but is better than having to replace all UAs. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: 03 June 2008 13:06 To: Bogdan-Andrei Iancu Cc: [email protected] Subject: Re: [Sip-implementors] Why does 6XX break a serial forking? What do you mean by "may reply with 6xx if BOSS is totally gone"? As derived from rfc 3261, 6xx responses can be returned "only if the client knows that no other end point will answer the request." In the system you described, you want another end point (secretary's phone) to answer the request so the phone should be configured (or fixed) to send a 4xx response - a 6xx would NOT be allowed under the conditions you desribe. If you happen to know that there is no secretary (or other endpont) then it would be acceptable to allow a 6xx response. In most cases, a UA cannot know if there are other end points so a 4xx response is wrong in these cases. Also, how does that UA know the BOSS is totally gone? The BOSS could've gone home and registered a different UA from home. Regards, Attila -----Original Message----- From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED] Sent: 03 June 2008 12:15 To: Attila Sipos Cc: Iñaki Baz Castillo; [email protected] Subject: Re: [Sip-implementors] Why does 6XX break a serial forking? Hi, What I think Iñaki tries to underline is the fact that the UAS has the knowledge about the destination user from the current branch. But a mid proxy may decide to serial fork the call to a new destination that points to a totally different user - and is this case the 6xx is not relevant as it is a different user. Imagine something like this: I have user BOSS and user SECRETARY. I want my proxy to serial fork all the un-answered calls for BOSS. So, in the first step, the call will go to the UAS of BOSS and this may reply with 6xx if BOSS is totally gone. But this should not prevent my proxy to hunt the user SECRETARY for this call. Regards, Bogdan Attila Sipos wrote: >>> But how could a UAS know that its proxy will want to forward the >>> request to a voicemail system when receiving a negative reply? >>> > > More accurately, the UAS doesn't know if the destined user is > available on another fork so it shouldn't send a 6xx response. > > >>> Why should a 6XX destroy still not generated branches? (ok, because >>> RC 3261 says it but...) >>> > > Because 6xx means you cannot be successful so don't bother trying. > It stops time being wasted on other forks. > > _______________________________________________ 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
