Well, here is the first problem - how can a client(like device) know that no other end point will answer? personally I find it a wide and un-sustainable assumption for the UAS.
But going over this, let's say the UAS sends the 6xx reply. The fact that the call will be (if so) forwarded to another destination is something known by the proxy and not by the UAS - many operators are implementing such services on the proxy side, totally transparent for the UAS device. Let's consider the scenario: 1) incoming call for BOSS 2) the person behind UAS does reject, so the UAS device is entitled to generate a 6xx reply (as a person refused to answer). And the 6xx refers to the BOSS user. 3) proxy should attempt to deliver the call to the SECRETARY user, but the 6xx prevents this.....Even if the 6xx reply contains no information about the SECRETARY user, but only about the BOSS user. Regards, Bogdan Attila Sipos wrote: > 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
