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: sip-implementors@lists.cs.columbia.edu > 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; sip-implementors@lists.cs.columbia.edu > 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 > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors