SIP Registration on a satellite link with 600mS latency

I am having trouble getting an Asterisk installation on the end of a satellite link with 600mS latency to register reliably.

I looked at the packets and the problem appears to be timing but I not totally familiar with the Asterisk registration sequence, so I could be wrong.

In the timing below AA.AA.AA.AA is the Asterisk box and SS.SS.SS.SS is the SIP provider
I have tried to split out the time when a packet leaves one of the units and when it arrives (about 300mS later). There is some narrative inserted into the record

Time ----- Origin/Destination --------- Packet details including size of packet
destination is marked SIP
277.161 AA.AA.AA.AA
277.461 SS.SS.SS.SS SIP 603 Request: REGISTER sip:SS.SS.SS.SS (1 binding) |

277.476 SS.SS.SS.SS
277.476 SS.SS.SS.SS
277.776 AA.AA.AA.AA SIP 454 Status: 100 Trying |
277.776 AA.AA.AA.AA SIP 563 Status: 401 Unauthorized |
If my timings are right then the packet below was transmitted by the Asterisk box before the packet above from the SIP provider arrived. This happens many times.
277.423 AA.AA.AA.AA
277.723 SS.SS.SS.SS SIP 603 Request: REGISTER sip:SS.SS.SS.SS (1 binding) |
277.739 SS.SS.SS.SS
277.740 SS.SS.SS.SS
278.039 AA.AA.AA.AA SIP 454 Status: 100 Trying |
278.040 AA.AA.AA.AA SIP 563 Status: 401 Unauthorized |
On the other hand for whatever reason this packet below was sent after the packet above arrives and we appear to have a successful registration
278.202 AA.AA.AA.AA
278.502 SS.SS.SS.SS SIP 603 Request: REGISTER sip:SS.SS.SS.SS (1 binding) |
278.518 SS.SS.SS.SS
278.518 SS.SS.SS.SS
278.518 SS.SS.SS.SS
278.530 SS.SS.SS.SS
278.818 AA.AA.AA.AA SIP 454 Status: 100 Trying |
278.818 AA.AA.AA.AA SIP 564 Request: OPTIONS sip:0123456789@AA.AA.AA.AA:5060 |
278.818 AA.AA.AA.AA SIP 574 Status: 200 OK (1 binding) |
278.830 AA.AA.AA.AA SIP 605 Request: NOTIFY sip:0123456789@AA.AA.AA.AA:5060 |
Another example where the packet below was transmitted before the packet above arrived. This doesn’t seem to have caused so much trouble.

278.777 AA.AA.AA.AA
279.077 SS.SS.SS.SS SIP 603 Request: REGISTER sip:SS.SS.SS.SS (1 binding) |
279.093 SS.SS.SS.SS
279.093 SS.SS.SS.SS
279.093 SS.SS.SS.SS
279.393 AA.AA.AA.AA SIP 454 Status: 100 Trying |
279.393 AA.AA.AA.AA SIP 564 Request: OPTIONS sip:0123456789@AA.AA.AA.AA:5060 |
279.393 AA.AA.AA.AA SIP 574 Status: 200 OK (1 binding) |

279.058 AA.AA.AA.AA
279.358 SS.SS.SS.SS SIP 573 Status: 200 OK |
279.424 AA.AA.AA.AA
279.890 AA.AA.AA.AA
279.724 SS.SS.SS.SS SIP 519 Status: 489 Bad event |
280.190 SS.SS.SS.SS SIP 573 Status: 200 OK |

288.323 SS.SS.SS.SS
288.623 AA.AA.AA.AA SIP 605 Request: NOTIFY sip:0123456789@AA.AA.AA.AA:5060 |
289.395 AA.AA.AA.AA
289.695 SS.SS.SS.SS SIP 519 Status: 489 Bad event |

339.000 Other packets

If this is correct then the problem is that the Asterisk installation is not waiting long enough for a response from the SIP provider before trying again.

Is there a timer that can be adjusted to increase that time? Or is there another way of getting round this problem?

Any help greatly appreciated…

If this is chan_sip, there are a couple of options that change the T1 timings, but retransmitting the REGISTER is normal behaviour for a high latency path, and should not cause problems.

Without the full SIP trace, it is difficult to see which side is mishandling the retransmissions.