PJSIP Incoming call drop

FreePBX Providers
,
1

Hi All,

This is my very first post; I would like to express sincere thanks to all contributors for their valuable contributions.

I have spent a considerable amount of time trying to fix an incoming call drop issue; the following is what I discovered, which appears to be the problem.

The following response 200/183 works without any issue.(Asterisk configuration)

            X.X.X.X:80              10.0.20.8:5060  │Via: SIP/2.0/UDP X.X.X.X:80;branch=z9hG4bK3gfqi13egfvvlwg4cqlffcue3T41492;received=X.X.X.X;rport=80
          ──────────┬─────────          ──────────┬─────────│From: <tel:+Y.Y.Y.Y;noa=international;srvattri=international>;tag=sbc0511yxxwg6sg
  17:50:45.655109   │        INVITE (SDP)         │         │To: <tel:+Z.Z.Z.Z>;tag=as3b147b77
        +0.000883   │ ──────────────────────────> │         │Call-ID: [email protected]
  17:50:45.655992   │         100 Trying          │         │CSeq: 1 INVITE
        +0.003400   │ <────────────────────────── │         │Server: Grandstream Wave 1.2.14
  17:50:45.659392   │         180 Ringing         │         │Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
        +0.000071   │ <────────────────────────── │         │Supported: replaces
  17:50:45.659463   │  183 Session Progress (SDP) │         │Contact: <sip:[email protected]:5060>
        +2.200645   │ <────────────────────────── │         │Content-Type: application/sdp
  17:50:47.860108   │        200 OK (SDP)         │         │Content-Length: 270
        +0.416034   │ <────────────────────────── │         │
  17:50:48.276142   │             ACK             │         │v=0
        +7.069805   │ ──────────────────────────> │         │o=root 1368296184 1368296184 IN IP4 10.0.20.8
  17:50:55.345947   │             BYE             │         │s=Asterisk PBX 16.28.0~dfsg-0+deb10u3
        +0.000329   │ ──────────────────────────> │         │c=IN IP4 10.0.20.8
  17:50:55.346276   │           200 OK            │         │t=0 0
                    │ <────────────────────────── │         │m=audio 11656 RTP/AVP 0 8 96
                    │                             │         │a=rtpmap:0 PCMU/8000
                    │                             │         │a=rtpmap:8 PCMA/8000
                    │                             │         │a=rtpmap:96 telephone-event/8000
                    │                             │         │a=fmtp:96 0-16
                    │                             │         │a=maxptime:150
                    │                             │         │a=sendrecv

This is the response when FreePBX initiates session for 183/200.

            X.X.X.X:80              10.0.20.48:5060  │Via: SIP/2.0/UDP X.X.X.X:80;rport=80;received=X.X.X.X;branch=z9hG4bKssn81ltn0v8p8jo8qo8oqjyllT22800
          ──────────┬─────────          ──────────┬─────────│Call-ID: [email protected]
                    │        INVITE (SDP)         │         │From: <tel:+Y.Y.Y.Y;noa=international;srvattri=international>;tag=sbc0402mipyp3xs
  18:49:46.544092   │ ──────────────────────────> │         │To: <tel:+Z.Z.Z.Z>;tag=769282fc-d2a6-44d8-8548-4aeeda10d1be
        +0.000832   │         100 Trying          │         │CSeq: 1 INVITE
  18:49:46.544924   │ <────────────────────────── │         │Server: Grandstream Wave 1.2.14
        +0.183000   │  183 Session Progress (SDP) │         │Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER
  18:49:46.727924   │ <────────────────────────── │         │Contact: <sip:[email protected]:5060>
        +0.138454   │  183 Session Progress (SDP) │         │Supported: 100rel, timer, replaces, norefersub
  18:49:46.866378   │ <────────────────────────── │         │Session-Expires: 1800;refresher=uac
        +0.019559   │  183 Session Progress (SDP) │         │Require: timer
  18:49:46.885937   │ <<<──────────────────────── │         │Content-Type: application/sdp
        +3.689477   │        200 OK (SDP)         │         │Content-Length:   252
  18:49:50.575414   │ <────────────────────────── │         │
        +0.499792   │        200 OK (SDP)         │         │v=0
  18:49:51.075206   │ <<<──────────────────────── │         │o=- 229277753 229277755 IN IP4 10.0.20.48
        +1.000201   │        200 OK (SDP)         │         │s=Asterisk
  18:49:52.075407   │ <<<──────────────────────── │         │c=IN IP4 10.0.20.48
        +1.999571   │        200 OK (SDP)         │         │t=0 0
  18:49:54.074978   │ <<<──────────────────────── │         │m=audio 14428 RTP/AVP 0 8 96
        +3.999977   │        200 OK (SDP)         │         │a=rtpmap:0 PCMU/8000
  18:49:58.074955   │ <<<──────────────────────── │         │a=rtpmap:8 PCMA/8000
        +4.000240   │        200 OK (SDP)         │         │a=rtpmap:96 telephone-event/8000
  18:50:02.075195   │ <<<──────────────────────── │         │a=fmtp:96 0-16
        +4.000542   │        200 OK (SDP)         │         │a=ptime:20
  18:50:06.075737   │ <<<──────────────────────── │         │a=maxptime:150
        +2.314463   │             ACK             │         │a=sendrecv
  18:50:08.390200   │ ──────────────────────────> │         │

Based to my understanding, the caller server never receives the response; consequently, there is no acknowledgement (ACK), which results in the call drop.

Thanks

2

Assuming that the packet details are for a 200 OK sent from Asterisk at 10.0.20.48 to X.X.X.X and X.X.X.X is a public IP address, then
Contact: <sip:[email protected]:5060>
is incorrect, because it is telling the remote server to send the ACK to 10.0.20.48, which won’t work because 10.0.20.48 is a private address not routable on the internet.

In Asterisk SIP Settings, General tab, confirm that External Address is set to the WAN address of your router/firewall, and that Local Networks includes 10.0.20.0/24 and whatever other non-NAT addresses are on your LAN, but does not include X.X.X.X

The pjsip tab has some settings for external address and port, as well as local network. In most cases these should all be left blank.

What is strange is that the working example has the same problem! If the working example is still on line and is using the same public IP address as the failing system, you have an issue because they are both trying to use port 5060.

Also, check the configuration of your router/firewall for any mention of 10.0.20.8 or 10.0.20.48.

Finally, what does “Grandstream Wave” have to do with any of this? Did you change useragent for Asterisk to meet some requirement of a remote system?

Please describe your network configuration.

3

Thank you, Stewart1,
I have inspected every message received for the inbound call, and it turns out that the trunk specifically requires a ringing signal (180). If there is no ringing, the trunk will not acknowledge any further messages.

You can notice the difference in my snippet.

FYI: Grandstream Wave is, in fact, a user agent.

Thanks,
Shankar

4

The Advanced tab for your Inbound Route has an option called Signal RINGING. If that’s on but not working, check the Asterisk log to see whether the correct route was selected.

I’m well aware of that, but Asterisk is a B2BUA; even if the extension device is Grandstream Wave it would never send that string on the trunk, so it appears that Asterisk was specifically configured to use that useragent string. Most trunking providers don’t treat user agents differently and just log it to aid in debugging or for statistics. If yours has different behavior for different user agents, you might ask them which would be best for your system.

If you still have trouble, at the Asterisk command prompt, type
pjsip set logger on
The Asterisk log will now include a SIP trace along with the regular entries. Paste the relevant section of the log at pastebin.com and post the link here. If you are too new to post links, just post the last 8 characters of the URL.

5

Thanks,

Yes, I enabled “Signal RINGING” and disabled inband progress under trunk->advanced, which solved my problem.

My server is behind NAT and I haven’t opened any ports; I’m no expert, but registered trunks appear to initiate outbound sessions, so no straight inbound connection from an external server and hence no need to expose ports to the internet.

Thanks,
Shankar

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.