One reason for not recursing on some contact is because the proxy is
incapable of doing so. A theoretical reason for that is if the contact
is not a sip/sips url. For instance, its legal to include http or mailto
uris in your 305, though I have never heard of it being done in
practice. Such a uri *might* be handled by the UAC, but can't be by a proxy.
For an example of how this could conceivably work: a uas that is busy
could return a mailto URI. Then the UAC could *locally* record an audio
message and send it to the mailto URI. That is a more endpoint centric
way to handle voicemail.
But of course there are innumerable issues in such techniques -
specifically knowing that the uac can/will do something meaningful with
this kind of response.
But in the end it doesn't matter why the proxy chooses not to recurse.
Nor can the UAC tell that is what has happened, rather than just getting
the 305 because there is no proxy, or a proxy that never recurses. If
you receive a 305, you should attempt to do something with it.
Thanks,
Paul
Dale Worley wrote:
> On Fri, 2009-01-23 at 10:07 +0530, karthik karthik wrote:
>> 305 has 3 contacts.
>> Proxy decided to recurse on first 2 contacts.
>> For some reasons Proxy decided not too recurse on the 3rd contact.
>> Meanwhile, If proxy received 4xx from 2nd contact, (and not all the
>> contacts are recursed)
>> 305 will be forwarded for 305 being lowest class.
>>
>> Is my understanding OK?
>
> Yes, I think you are correct.
>
>> If yes, are there specific reasons for proxy
>> deciding not to recurse on some of the contacts?
>
> One case is where the proxy never recurses on 3xx responses.
>
> But all proxies that I know of, if they receive a 3xx response, recurse
> on all contacts. I suppose that if the proxy did not understand the
> contact URI's scheme, it might choose to not recurse upon it. But I
> expect that most proxies do not handle that case in the way that the RFC
> prescribes, that they drop the contact rather than returning it upstream
> in a shortened 3xx response.
>
> Dale
>
>
> _______________________________________________
> 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
