the correct way to handle it is to do what RFC3261 says. But the problem is the UA seems to be saying one thing when really, another is meant. A UA should only send a 6xx if: 1. it knows that no other end point will take the call or (from the BLISS discussion "Rejection conditions for ACH") 2. if it doesn't want any other end point to take the call In your case, it seems that neither of the above is true but it it is still sending 6xx. In this case you have only 3 choices: 1. fix the UA 2. reconfigure the UA 3. change the proxy behaviour the BLISS draft (draft-ietf-bliss-ach-analysis-02.txt) indicates that forwarding to voice mail after 6xx could be ok:
The survey gave only a very small number of answers on the issue of handling 6xx responses, with no conclusions to be drawn other than that forwarding to voice mail is sometimes allowed following a 6xx response. It seems like usage of 6xx is becoming a policy matter rather than a strict set of rules. ________________________________ From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED] Sent: Tue 03/06/2008 18:15 To: Attila Sipos Cc: [email protected] Subject: Re: [Sip-implementors] Why does 6XX break a serial forking? Well, I already have hack-like solutions for this :). But I 'm trying to figue out what is the correct way to handle 6xx reply in order to: 1) keep RFC compliance 2) make some common-sense scenarios to work 3) still have proxy-UA full interoperability. Regards, Bogdan Attila Sipos wrote: > 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
