REFER over trunk ICMP Unreachable

When a person calls client A the call comes into our server via our SIP trunk and then we immediately REFER the call to an external server that client A has subscribed to for specific IVR service. Once the caller listens to the menu and picks an option the external server REFERs the call back to our server to hit a specific extension. (The external IVR server is set up as a friend trunk on our asterisk server).

(The external IVR service has specific functionality client A needs, so keeping the IVR local isn’t an option).

This whole process generally takes over 30 seconds until the REFER comes back to our server to hit the target extension. The problem is that when the external server sends the REFER they are getting an ICMP Port Unreachable error.

When our server sends the initial REFER is is sending to dst:5060/UDP src:1xxxx/UDP. When the external server REFERs back they are replying to the src port, which obviously has been closed.

Here are the things I’ve thought/tried:

  • We thought it was a UDP or RTP timeout (even though it’s a SIP message it’s on a high port in the RTP range). So we increased our firewall’s UDP timeout, asterisk udp timeout, and asterisk rtp timeout. No luck.
  • Does asterisk automatically close the src port when it REFERs to an external system?
  • Shouldn’t all SIP messages from external servers coming over a trunk hit 5060?

The packets are there, I can see them hitting the firewall. They just can’t get through because the high port has been closed on the asterisk server by the time the REFER comes back.

Any ideas? I’m at a loss…

For UDP, Asterisk uses the port on which it is listening, presumably 5060, as the source port. This is certainly true of chan_sip, and I cannot imagine why PJSIP would do anything different, but Joshua is the pjsip expert here.

I think your address is being overwritten by a NAT router, rather than Asterisk using a strange source port.

It is not illegal to use a non-standard and transient port here, as the refer back represents a new call. However, chan_sip doesn’t do it, and I can’t see chan_pjsip doing it, as it would complicate firewall and NAT configuration.

I don’t understand why you need a friend trunk. Trunks almost always should be type=peer, for best reliability and security.

1 Like

The friend trunk is what was asked of us by the IVR server company. I will do some more packet captures and see if NAT is changing our ports.

You are correct - PJSIP is the same.

Since you two know way more about SIP than I do, can you answer a question to which I haven’t been able to find an answer?

Is a REFER a “new call” and, if so, if the dst of the REFER wants to REFER back to the src should it do so on port 5060 100% of the time?

I tried looking in the IETF SIP spec and everywhere else on the internet but couldn’t find anything explaining exactly how a REFER works.

A REFER isn’t a call, and it can exist in dialog (inside of a “call”) or outside of one.

If you provide a log of what is going on which includes the SIP messages then it may shed light on what is going on.