[OpenSIPS-Users] SIP MESSAGE retransmission suppression

[Gavin Murphy]

Hi Chris,

     it would seem (based on the description) that the fr_timer setting 
is for the final timeout, and not related to retransmissions, but please 
correct me if I have interpreted the description incorrectly. In RFC 
3261, it appears that Timer E is the one that governs the 
retransmissions of non-INVITE requests, and is initially set to T1. 
While T1 could be set to some larger value to suppress the 
retransmissions, it would also apply to INVITEs, since Timer A is also 
based on T1, and we don't want to impact the INVITE retransmission 
handling.

In this scenario, I don't think it's possible for there to be a final 
response for quite some time, as we are doing interworking between 
disparate networks (specifically an SMS network), with the terminating 
network taking a significant amount of time before being able to 
determine if the message can be accepted or will be rejected. That is 
why I asked about whether a provisional response (such as the 100 
Trying) would help to suppress the retransmissions. In looking at RFC 
3428 (section3 last paragraph, and section 8 last paragraph), it appears 
that provisional responses for MESSAGE are supported. Section 21.1 of 
RFC 3261 indicates "A server sends a 1xx response if it expects to take 
more than 200 ms to obtain a final response.". In our case it is 
definitely going to be more than 200 ms before a final response can be 
determined, and thus the thinking that a 1xx class response would help 
suppress the retransmissions.

At this point our only option may be to go to a TCP transport.

Gavin

On 29/02/2016 10:07 AM, users-request at lists.opensips.org wrote:
> Hi Gavin,
>
> You can adjust timer behavior but this is not covered by RFC 3261.
> If you need to be aware against RFC, you should think about to solve it in another way.
>
> http://www.opensips.org/html/docs/modules/1.8.x/tm.html
>
> fr_timer can be adjusted to solve this.
> Better way is to have intelligent devices on your transmission route to answer fastest.
>
> Best regards
>
> Chris