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
