First, I'm not trying to be much of an apologist for 6xx. It has
problems. But it was at least a halfway reasonable attempt to provide
needed functionality. And, I expect that the concept was developed in
the context of http, and may have made more sense there.
Bogdan-Andrei Iancu wrote:
> 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.
In general it cannot know what other devices *will* do.
However the *user* of the device may know that.
And, I think this is better understood as asserting a policy rather than
a fact. So by returning the 6xx the UA is saying that *its* desired
policy is that this call not be answered by any other device.
> 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.
The BLISS WG is grappling with this issue. You should visit over there.
Thanks,
Paul
> 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
