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, [email protected] 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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
