Vishal Mathur wrote:
> 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.
I agree that is it better not to crash, and if you do crash it is better
not to lose any data. But in the real world people trade that sort of
stuff off against other properties they also want.
One of the advantages of proxies over B2BUAs is that they don't need to
keep much state, and if you have a farm of them, then one crashing
doesn't cause much trouble.
> 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.
You can think what you like, but 3261 says:
16.7 Response Processing
When a response is received by an element, it first tries to locate a
client transaction (Section 17.1.3) matching the response. If none
is found, the element MUST process the response (even if it is an
informational response) as a stateless proxy (described below). If a
match is found, the response is handed to the client transaction.
The stateless proxy then just forwards the response.
Paul
> 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
