[OpenSIPS-Users] SIP MESSAGE retransmission suppression

[Christian Lahme]

HI Gavin,

Yes it’s the T1 timer which needs to be set.
But in this case as you’re talking about different network, you should more and more think about proxying SIP.

100 Trying is typically to suppress retransmits of invites, but an 180 or 18x should follow fast until you send a final response like an ACK or a decline.

Cheers
Chris




Am 29.02.16 20:34 schrieb "users-bounces at lists.opensips.org im Auftrag von Gavin Murphy" <users-bounces at lists.opensips.org im Auftrag von gavin.murphy at newnet.com>:

>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
>
>
>
>_______________________________________________
>Users mailing list
>Users at lists.opensips.org
>http://lists.opensips.org/cgi-bin/mailman/listinfo/users