Dale,
I have never wrapped my head around all the timer stuff, so I won't try
to say anything definitive. My one concern would be whether what you are
proposing is compatible with RFC 4320. I guess it you are assuming that
receiving a retransmission of the original request implies that the
condition has been satisfied for the UAS to send a 100. Is that right?
Paul
[EMAIL PROTECTED] wrote:
> We're noticing that when the SIP network gets congested, phones will
> be fairly frantic about resending requests that they do not receive
> (provisional or final) responses for. Unfortunately, this only
> increases the load on the proxy, which does not help the situation.
> For INVITEs, the proxy sends 100 responses to stop the phone from
> resending (and to keep it from failing over to another proxy). But
> for non-INVITE requests, 100 responses are SHOULD NOT.
>
> However, we're considering adjusting the proxy so that if it receives
> a resend of a non-INVITE request (on a non-reliable transport), it
> will send a 100 response to (hopefully) quench the resends.
>
> 1) Will phones respond to 100 responses to non-INVITE requests to
> quench resends?
>
> 2) Will SIP agents behave badly if they receive 100 responses to
> non-INVITE requests?
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
