In the Boss-Secretary example below, the UAS should not return 6xx if the user (ie Boss) rejects the call, that seems more appropriate for a client error, 4xx. 6xx kind of error would seem appropriate if the system know that the called user (Boss in this case) does not exist in the system. So it does not make sense for the proxy to try to create another leg for that call, maybe to voicemail since that will fail as well because no account for that user exists on the VM system
Sanjay >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Bogdan-Andrei Iancu >Sent: Tuesday, June 03, 2008 1:12 PM >To: Attila Sipos >Cc: [email protected] >Subject: Re: [Sip-implementors] Why does 6XX break a serial forking? > >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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
