The effect of sending 100 for non-INVITE is that the next downstream hop extends its retransmission interval (for UDP) to T2 (4 seconds by default). RFC4320 does allow it, but only after timer E reaches T2, so effectively the 100 trying response does not change the interval in that case.
So changing a proxy to send 100 upon receiving a retransmission is not compliant with RFC4320. That being said, I have heard about endpoints (certain ATAs) that crashed upon receiving a 100 response for REGISTER. That is not normal though, we should not base proxy design upon such cases Regards, Jeroen Sanjay Sinha (sanjsinh) wrote: > This is addressed in RFC 4320, which also suggests normative updates > to RFC 3261. > I did not understand the question about Cancel for non-Invite > transaction, is that allowed or useful? > > Sanjay > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Christer Holmberg (JO/LMF) >> Sent: Monday, June 04, 2007 8:54 AM >> To: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu >> Subject: Re: [Sip-implementors] 100 response for non-INVITE requests >> >> >> Hi Dale, >> >> I can't speak for others, but I have never heard about crashes >> due receiving 100 Trying responses to non-INVITE requests. >> >> One question, however, is whether 100 Trying responses for >> non-INVITE requests have any impact on the re-transmission. >> >> Another question is what happens if terminals, after receiving >> 100 Trying for non-INVITE requests, start to send CANCEL... >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of >>> [EMAIL PROTECTED] >>> Sent: 4. kesäkuuta 2007 4:19 >>> To: sip-implementors@cs.columbia.edu >>> Subject: [Sip-implementors] 100 response for non-INVITE requests >>> >>> 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 >> > > _______________________________________________ > 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
