Hi Dale,
inline...
[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?
>
I think RFC 3261 is clear about this. The UAC must continue sending the
request even if it received a provisional response to NICT or there will
be a danger of not assuring delivery of the final response.
17.1.2.1 Overview of the non-INVITE Transaction
Non-INVITE transactions do not make use of ACK. They are simple
request-response interactions. For unreliable transports, requests
are retransmitted at an interval which starts at T1 and doubles until
it hits T2. If a provisional response is received, retransmissions
continue for unreliable transports, but at an interval of T2. The
server transaction retransmits the last response it sent, which can
be a provisional or final response, only when a retransmission of the
request is received. This is why request retransmissions need to
continue even after a provisional response; they are to ensure
reliable delivery of the final response.
> 2) Will SIP agents behave badly if they receive 100 responses to
> non-INVITE requests?
>
Not if they are compliant since the previous paragraph implies that a
provisional response maybe received for NICT.
I do send a 100 Trying for REGISTER requests (which usually takes long
to process because of internal DB access ) but this is only to serve as
a hint to the the UAC that I have received the request without the
intention of stopping it from retransmitting.
> 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
