Hello,
I need to configure the timeout between my asterisk sending the invite and receiving the trying. In my current scenario, my asterisk server resends the invite if trying is not received in 150-160ms. The provider’s opensips doesn’t cater the retransmission and connects multiple calls.
Can someone help me in setting the trying timeout to a greater value so that the invite is not retransmitted?
Thanks
I would change to an ITSP that supports SIP. The whole point of 100 responses to to suppress the retransmission, and, as UDP is unreliable, it must be assumed that sometimes the 100 won’t get through. The 100 response serves no other purpose. It is quite legitimate to go directly to 180 or even 200.
If the ITSP is not sending the 100 Trying promptly, it’s SIP implementation is seriously non-compliant. If it cannot tolerate a retransmission of the initial INVITE, it is non-compliant.
Changing the initial retransmission timeout would be a deliberate violation of the SIP protocol and is therefore only possible by changing the source code. Developer support is not provided via this board.
One other possibility: could it be that your firewall is mangling the retransmission so that it doesn’t look like a retransmission.
Thanks for the reply. If you could just tell me what exactly is the time after which this retransmission is configured in asterisk code. So that I can verify if it is asterisk or my network who is retransmitting.
After looking at the captures from my ITSP side, they are sending trying promptly. But due to network latency, it is reaching us in more than 150ms and our asterisk servers retransmits the invite. I think this is too short a duration for retransmission. I need to increase it to may be 500ms. Any ideas?
The network latency is too high for satisfactory use of VoIP.
The ITSP’s software is still badly broken as retransmission should be perfectly safe.
You will nee to modify the source code and recompile. This forum does not provide that level of support, although my guess is that it is a fairly easy change.
As far as I know the retransmission time of SIP packets is 1000ms by default. I am using all default sip timers, I dont know why my asterisk is retransmitting in 150ms? 
It’s actually 500ms with an exponential backoff:
[quote] For unreliable transports
(such as UDP), the client transaction retransmits requests at an
interval that starts at T1 seconds and doubles after every
retransmission. T1 is an estimate of the round-trip time (RTT), and
it defaults to 500 ms.[/quote]
I was wrong about this being a compile time option. For chan_sip, the minimum value is set with t1min which defaults to 100ms. This is only used if you have qualify enabled, in which case the working value of t1 is the actual round trip time on the last qualify.
If you don’t use qualify, timert1 is used and defaults to 500ms.
If Asterisk is responding in 100ms, it means that the network round trip latency is less than 100ms, so there is no excuse for the ITSP not to respond in time. I suppose it is possible that an “intelligent” router is responding to the OPTIONs requests used for qualify, thus making it useless. In any case, retransmissions of INVITEs are perfectly normal.
These are actually all documented, so there should have been no need to ask (when you ask, the assumption tends to be that you have looked at the documentation and there are no suitable options; people responding will not spend significant time doing their own research).
;--------------------------- SIP timers ----------------------------------------------------
; These timers are used primarily in INVITE transactions.
; The default for Timer T1 is 500 ms or the measured run-trip time between
; Asterisk and the device if you have qualify=yes for the device.
;
;t1min=100 ; Minimum roundtrip time for messages to monitored hosts
; Defaults to 100 ms
;timert1=500 ; Default T1 timer
; Defaults to 500 ms or the measured round-trip
; time to a peer (qualify=yes).
;timerb=32000 ; Call setup timer. If a provisional response is not received
; in this amount of time, the call will autocongest
; Defaults to 64*timert1
Your assumption is 100% correct. I have already played with these timers available in sip.conf, but didn’t get my required results. The rrt between my asterisk and the ITSP’s opensips is 150-160ms, which is causing a lot of retransmissions and they are not absorbing the retransmissions. Thats why I needed to increase the retransmission delay.
I increased t1min upto 250ms, but it didn’t change the behaviour of my asterisk. Now I am going for your first suggestion: “CHANGE YOUR ITSP”… 
Many Thanks.