Hi Paul,

Generally all Proxy should try to keep there data in shared storage (or
shared memory in single Unix BOX). That will give then advantage that
even after crash they can attached to same transaction FSM and get the
older state going. Note that this does not apply if machine (where proxy
is running) itself is restarted. In that case only shared storage can
help not shared memory.

Also I am not sure that forwarding a Final response without an INVITE
itself is a good idea or not. I think it should reject it with error
code Call leg Transaction Not Found. 

Regards,

Vishal Mathur
Symantec Corporation
www.symantec.com
_________________________________
Office: +91-20-66067655
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat
Sent: Friday, June 22, 2007 5:24 AM
To: Scott Lawrence
Cc: [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Behaviour on receipt ofsecond non-2xx
response



Scott Lawrence wrote:

> I think this can only happen if you're talking to something that's
> broken - either a UA that sends more than one final response to the
same
> request, or a proxy that is returning more than one to you (it is
> correct for a proxy to return multiple 2xx responses, but anything >=
> 300 should be cause the proxy to just choose one).

It could be a proxy that isn't "broken", but which happened to crash and

restart, losing all its transaction state. Then if it receives final 
responses from other forks, and has no matching transaction, it will 
just forward the response statelessly.

        Paul

> In any event, it seems to me that the simplest thing to do is to just
> construct an ACK that matches the new response and send it (otherwise
> the broken thing downstream may keep resending it).
> 
_______________________________________________
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

Reply via email to