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-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

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: sip-implementors-bouncescs.columbia.edu 
> [mailto:sip-implementors-bouncescs.columbia.edu] On Behalf

> Of Dale.Worleycomcast.net
> Sent: 4. kesäkuuta 2007 4:19
> To: sip-implementorscs.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-implementorscs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
> 

_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

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

Dale.Worleycomcast.net 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-implementorscs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

Hi Dale,

inline...

Dale.Worleycomcast.net 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
> Sip-implementorscs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
>
>
>   

_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors