Strange INVITE packets causes call hangs up

Asterisk Asterisk SIP
1

I have a Asterisk 1.8 with public IP and a CUCM behind a router that sends calls to this Asterisk. The CUCM sends INVITE with extension and IP LAN of the CUCM on “From Header” and IP LAN of the CUCM on “Via Header” because I use nat=yes to solve this on the Asterisk side .

This is the SIP flow of the call:

|Time     | PUBLIC_IP_CLIENT                      |
|         |                   | PUBLIC_IP_AST     |                   
|63.229932|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST Call-ID:d6220a00-1e818e6b-3d-a66a8c0@192.168.102.10 CSeq:101
|         |(1025)   ------------------>  (5060)   |
|63.231753|         100 Trying|                   |SIP Status 100 Trying
|         |(1025)   <------------------  (5060)   |
|63.231920|         200 OK SDP (g711A te          |SIP Status 200 OK
|         |(1025)   <------------------  (5060)   |
|63.287119|         ACK       |                   |SIP Request INVITE ACK 200 CSeq:101
|         |(1025)   ------------------>  (5060)   |
|63.310724|         RTP (g711A)                   |RTP, 44996 packets. Duration: 4294903.986s SSRC: 0x7AA
|         |(25366)  ------------------>  (16066)  |
|63.310943|         RTP (g711A)                   |RTP, 44995 packets. Duration: 4294903.986s SSRC: 0x6335863F
|         |(25366)  <------------------  (16066)  |
|963.231319|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|963.250876|         RTP (g711A)                   |RTP, 371 packets. Duration: 4294004.046s SSRC: 0x7AA
|         |(25366)  ------------------>  (16066)  |
|963.250950|         RTP (g711A)                   |RTP, 320 packets. Duration: 4294004.046s SSRC: 0x6335863F
|         |(25366)  <------------------  (16066)  |
|963.330872|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|963.531208|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|963.931722|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|964.731635|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|966.331841|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |
|969.530714|         INVITE SDP (g711A te          |SIP INVITE From: "101" <sip:101@192.168.1.10 To:<sip:999@PUBLIC_IP_AST CSeq:102
|         |(1025)   <------------------  (5060)   |

The call works until the asterisk side sends INVITE to CUCM that CUCM don’t response . Asterisk stops to send media to CUCM and the console shows me the following:

WARNING[3996] chan_sip.c: Retransmission timeout reached on transmission d6220a00-1e818e6b-3d-a66a8c0@192.168.102.10 for seqno 102 (Critical Request) 
WARNING[3996] chan_sip.c: Hanging up call d6220a00-1e818e6b-3d-a66a8c0@192.168.102.10 - no reply to our critical packet

How I can make that the asterisk side don’t send this INVITE that causes the call fails?. Thanks.

2

I didn’t think CUCM was broken in this way. Some versions of X-Lite are.

Either, you have a bad NAT configuration, and the Re-INVITE is being lost, or the peer, which is now a server, is non-compliant and does not understand how to become a server, or doesn’t even understand how to handle a Re-INVITE.

At the very least, it should reject the Re-INVITE.

Disabling direct media, turning off session timers, and disabling sendrpid should eliminate all reasons for Asterisk to Re-INVITE, although you will also lose the associated functions.

3

Hi,

Either, you have a bad NAT configuration, and the Re-INVITE is being lost, or the peer, which is now a server, is non-compliant and does not understand how to become a server, or doesn’t even understand how to handle a Re-INVITE.
At the very least, it should reject the Re-INVITE.

I know that there are a problem with nat on the CUCM side, but I think that with the correct configuration of Asterisk I could solve this.

Disabling direct media, turning off session timers, and disabling sendrpid should eliminate all reasons for Asterisk to Re-INVITE, although you will also lose the associated functions.

sip show peer CUCM on Asterisk CLI shows me:

  ...
  DirectMedia  : No
  ...
  Trust RPID   : No
  Send RPID    : No
  ...

I don’t understand because Asterisk sends this Re-INVITE packets with this configuration, and is really strange that calls works over 10 minutes before hangs with message of timeout of reply to critical packet . I am learning about sip timers to try to solve this problem. Thanks.

Regards

4

Session timers are one of the reasons for sending a re-INVITE.

The “timeout of reply to critical packet” is because CUCM is violating the protocol by not responding to the Re-iNVITE. Even if it is not prepared to honour it, it should send some response, to reject it.

We’ve found that, at lease some versions of X-Lite don’t respond to Re-INVITEs. On the other hand, when Asterisk is configured as a trunk on CUCM, we have found that CUCM does respond to re-INVITEs and correctly handles direct media ones, and, I think connected line update ones.

We did direct media on earlier versions of CUCM and connected line updates on later ones. I think we also do some direct media on later ones, but prefer to use REFER.

5

Hi,

Deactivate the SIP Timers solves the problem. I am waiting that the technical contact of the CUCM talks with me to solves definitely. Thanks for the support.

Regards.