Migrating sip to pjsip trunk problem, incoming call drops after 32 seconds

General Help
1

Hello,

I am trying to migrate one of my sip trunks to pjsip, with no success. Everything works, except incoming calls are dropped after 32 seconds. While everything points to NAT problem, I can not figure why this is happening and which pjsip configuration file has to be changed. I am using FreePBX 14 and asterisk 13.
When call comes on standard sip trunk, INVITE is sent from provider, and replied with 100 trying followed by 200 OK. Afterwards, ACK is sent from provider. In pjsip case, ACK is never received. pjsip trunk keeps sending 200 OK every 2 seconds until call ends after 32 seconds.
Below is debug for both sip and pjsip trunk, my IP is changed with 44.55.66.77 as well as phone numbers. Everything else is original. There is difference in Contact header, but I can not tell if this is a source of the problem.
Any help is highly appreciated.

SIP trunk:

INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
Record-Route: sip:[email protected];lr=on
Via: SIP/2.0/UDP 162.213.111.22;branch=z9hG4bK4691.63020d51.0
Via: SIP/2.0/UDP 208.65.240.165:5060;branch=z9hG4bK-524287-1—09f4250da1d5b522;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5061;branch=z9hG4bK-d5is3ewwkdxnqxfi;rport=5061
Max-Forwards: 69
Record-Route: sip:208.65.240.165:5060;lr;transport=UDP
Contact: "Anonymous"sip:208.65.240.165:5061
To: sip:[email protected]
From: “JOHN DOE” sip:[email protected];tag=cngv2bh4sycxomak.o
Call-ID: [email protected]~o~o
CSeq: 695 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
h323-conf-id: 887280958-3263631848-2616459291-559912524
Portasip-3264-action: offer 1
cisco-GUID: 887280958-3263631848-2616459291-559912524
Content-Length: 159

v=0
o=Sippy 2481384099842951197 0 IN IP4 208.65.240.165
s=-
t=0 0
m=audio 39574 RTP/AVP 0 101
c=IN IP4 208.65.240.142
a=rtpmap:101 telephone-event/8000

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 162.213.111.22;branch=z9hG4bK4691.63020d51.0;received=162.213.111.22;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5060;branch=z9hG4bK-524287-1—09f4250da1d5b522;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5061;branch=z9hG4bK-d5is3ewwkdxnqxfi;rport=5061
Record-Route: sip:[email protected];lr=on
Record-Route: sip:208.65.240.165:5060;lr;transport=UDP
From: “JOHN DOE” sip:[email protected];tag=cngv2bh4sycxomak.o
To: sip:[email protected]
Call-ID: [email protected]~o~o
CSeq: 695 INVITE
Server: FreePBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:[email protected]:6666
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 162.213.111.22;branch=z9hG4bK4691.63020d51.0;received=162.213.111.22;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5060;branch=z9hG4bK-524287-1—09f4250da1d5b522;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5061;branch=z9hG4bK-d5is3ewwkdxnqxfi;rport=5061
Record-Route: sip:[email protected];lr=on
Record-Route: sip:208.65.240.165:5060;lr;transport=UDP
From: “JOHN DOE” sip:[email protected];tag=cngv2bh4sycxomak.o
To: sip:[email protected];tag=as2da2f9a0
Call-ID: [email protected]~o~o
CSeq: 695 INVITE
Server: FreePBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:[email protected]:6666
Content-Type: application/sdp
Content-Length: 256

v=0
o=root 1660948966 1660948966 IN IP4 44.55.66.77
s=Asterisk PBX 13.23.1
c=IN IP4 44.55.66.77
t=0 0
m=audio 11030 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

ACK sip:[email protected]:5060;transport=UDP SIP/2.0
Record-Route: sip:[email protected];lr=on
Via: SIP/2.0/UDP 162.213.111.22;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/UDP 208.65.240.165:5060;branch=z9hG4bK-524287-1—06e64e6d9643136b;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5061;branch=z9hG4bK-p5jyi2uyej5zzowq;rport=5061
Max-Forwards: 69
Route: sip:[email protected];lr
Contact: "Anonymous"sip:208.65.240.165:5061
To: sip:[email protected];tag=as2da2f9a0
From: “JOHN DOE” sip:[email protected];tag=cngv2bh4sycxomak.o
Call-ID: [email protected]~o~o
CSeq: 695 ACK
User-Agent: Sippy
Content-Length: 0

PJSIP trunk:

INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
Record-Route: sip:[email protected];lr=on
Via: SIP/2.0/UDP 162.213.111.22;branch=z9hG4bK7aae.37fded51.0
Via: SIP/2.0/UDP 208.65.240.165:5060;branch=z9hG4bK-524287-1—85d7d14a4198ad39;rport=5060
Via: SIP/2.0/UDP 208.65.240.165:5061;branch=z9hG4bK-ixtcopezy3n7ubni;rport=5061
Max-Forwards: 69
Record-Route: sip:208.65.240.165:5060;lr;transport=UDP
Contact: "Anonymous"sip:208.65.240.165:5061
To: sip:[email protected]
From: “JOHN DOE” sip:[email protected];tag=hurlbyw43k47mmqj.o
Call-ID: [email protected]~o~o
CSeq: 196 INVITE
Expires: 300
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
h323-conf-id: 2000400052-3263697384-2616459291-559912524
Portasip-3264-action: offer 1
cisco-GUID: 2000400052-3263697384-2616459291-559912524
Content-Length: 159

v=0
o=Sippy 3928492864103473808 0 IN IP4 208.65.240.165
s=-
t=0 0
m=audio 50502 RTP/AVP 0 101
c=IN IP4 208.65.240.142
a=rtpmap:101 telephone-event/8000

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 162.213.111.22;rport=5060;received=162.213.111.22;branch=z9hG4bK7aae.37fded51.0
Via: SIP/2.0/UDP 208.65.240.165:5060;rport=5060;branch=z9hG4bK-524287-1—85d7d14a4198ad39
Via: SIP/2.0/UDP 208.65.240.165:5061;rport=5061;branch=z9hG4bK-ixtcopezy3n7ubni
Record-Route: sip:[email protected]:5060;lr
Record-Route: sip:208.65.240.165:5060;transport=UDP;lr
Call-ID: [email protected]~o~o
From: “JOHN DOE” sip:[email protected];tag=hurlbyw43k47mmqj.o
To: sip:[email protected]
CSeq: 196 INVITE
Server: FreePBX
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 162.213.111.22;rport=5060;received=162.213.111.22;branch=z9hG4bK7aae.37fded51.0
Via: SIP/2.0/UDP 208.65.240.165:5060;rport=5060;branch=z9hG4bK-524287-1—85d7d14a4198ad39
Via: SIP/2.0/UDP 208.65.240.165:5061;rport=5061;branch=z9hG4bK-ixtcopezy3n7ubni
Record-Route: sip:[email protected]:5060;lr
Record-Route: sip:208.65.240.165:5060;transport=UDP;lr
Call-ID: [email protected]~o~o
From: “JOHN DOE” sip:[email protected];tag=hurlbyw43k47mmqj.o
To: sip:[email protected];tag=107d3074-54cf-45e7-b775-8f36f49468b0
CSeq: 196 INVITE
Server: FreePBX
Contact: sip:44.55.66.77:6667
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 231

v=0
o=- 596337296 2 IN IP4 44.55.66.77
s=Asterisk
c=IN IP4 44.55.66.77
t=0 0
m=audio 11476 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

After this point, OK 200 is repeated every 2 seconds until call drops

2

Rather than retype all of the possible answers, I recommend you search through the forums and look for the words “30 seconds”. This is a relatively common problem and has been covered in quite a bit of detail over time.

3

I did all the searching before posting here, but could not find any viable solution related to pjsip

4

It’s probably a NAT or routing problem (typically routing).

5

Somewhat simplified, the Contact header in the 200 OK tells the server (Fibernetics) the IP address and port to which it should send the ACK. Of course, pjsip and chan_sip are listening on different ports, so the Contact headers have to be different.

If the chan_sip Bind Port is 6666 and the pjsip Port to Listen On is 6667, then the Contact headers are correct.

If the PBX is on an unrestricted public IP of “44.55.66.77”, then I don’t know what’s wrong, unless you have an unusual iptables setup.

If it’s behind a NAT or other hardware firewall, IMO that’s a likely suspect.

Is PBX in cloud or on-site? If in cloud, who is cloud provider? Any special firewall settings? If on-site, describe any network elements that are not dumb switches, including modem (if configured as gateway), router, separate firewall (if any), SBC (if present).

6

Are you taking this from the Asterisk CLI? Does it say “Re-Transmitting” when it keeps sending the 200 OK out to the provider?! There should be an ACK to your 200 OK to confirm the dialog has started.

7

PBX is standalone linux box behind NAT firewall, which is again linux box with iptables. chan_sip binds to 6666 and pjsip to 6667. Both ports are open, I have extensions registering and using with both sip and pjsip. tcpdumped sip dialog on both pbx and nat machine, it looks exactly the same. I will try to test it on unrestricted public IP and see if it makes any difference.

Thank you for your help

8

Do you see the ACK from you provider when doing a tcpdump on the external interface of your firewall?

1 Like
9

No ACK on firewall side either, packets look exactly the same, only difference is source address

10

@tuta Please respond to this question. As well please provide a SIP trace via the Asterisk console for a call that is having issues.

  1. asterisk -rvvvvvv
  2. pjsip set logger on
  3. Make call
  4. Copy from start to end in the output
  5. Post results.
11

I will do it on Monday

12

https://todor.risjak.net/debug/pjsip_debug.txt

Test was created on machine with public static IP, no firewall. Same results.

13

So now, you have a recent and valid call example. Provide that or at least all the details to the provider. Ask them “Did you see my 200 OK?” or better yet, do a call with them real-time so they can do a real-time trace and see what happens.

You are sending them a 200 OK, which is correct. You are not getting their ACK, as it has been pointed out it is either due to them getting the 200 OK and they sent back an ACK but you’re not getting it or they just aren’t getting it/replying to it.

We have helped as much as we can, you will need to work with your provider at this point. They need to determine what is happening when the 200 OK is sent to them. Without that information there’s no valid path to continue on without just blinding throwing darts and hoping to hit the target.

14

I agree with @BlazeStudios that getting a SIP trace from Fibernetics may be the easiest solution. However, if they don’t readily cooperate you may be able to fix it without their help.

If they did not receive the 200 OK, then they wouldn’t know where to send the media and you would be unable to hear the caller (though they could hear you). Since you didn’t mention such, I was assuming that the 200 OK was received. So, either they are not sending the ACK, sending it to the wrong IP address or port, or something in the return path is blocking it (even though it should be identical to the path the original INVITE came in on).

Do you have other trunks on your system? If so, do they work properly with pjsip?

How does Fibernetics know where to send the INVITE (registration, configured manually on their portal, other)?

15

Further on this, what happens when you actually route the call to a phone or a device that someone can answer? Not the IVR or other “PBX” level answered services.

I just reviewed this again to make sure I didn’t miss anything and after looking at this, I’m thinking this might be something with the network.

  1. While the PBX is sending a 200 OK over and over with no response. The IVR is playing back the message and waiting for DTMF input.
  2. The IVR is cycling through it’s timeout timer and timeout loops due to lack of DTMF input.
  3. The PBX is HANGING UP the call due to the IVR TIMEOUT. In other words, the call isn’t dropping due to lack of RTP (in the sense Asterisk is not hitting its RTP timeout) it is dropping because the IVR programming said “drop it” due to the timeout loop limit being hit.
  4. When the PBX is hanging up the call, the PBX is sending a BYE which is correct. The kicker, the provider is sending back a 200 OK to the BYE, which is completely correct and what should happen.

`

BYE sip:208.65.240.165:5061 SIP/2.0
Via: SIP/2.0/UDP 44.55.66.77:6667;rport;branch=z9hG4bKPjd37c1dc3-7db7-416b-9178-c978d06b974a
From: <sip:[email protected]>;tag=63812e13-00c1-4115-861d-2b897866ab02
To: “JOHN DOE” <sip:[email protected]>;tag=uokmrxukcerwszzc.o
Call-ID: [email protected]:6666
CSeq: 30656 BYE
Route: <sip:[email protected]:5060;lr>
Route: <sip:208.65.240.165:5060;transport=UDP;lr>
Max-Forwards: 70 User-Agent: FPBX-14.0.3.19(13.23.1)
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 44.55.66.77:6667;rport=6667;branch=z9hG4bKPjd37c1dc3-7db7-416b-9178-c978d06b974a
Record-Route: <sip:162.213.111.22;lr>
To: “JOHN DOE” <sip:[email protected]>;tag=uokmrxukcerwszzc.o
From: <sip:[email protected]>;tag=63812e13-00c1-4115-861d-2b897866ab02
Call-ID: [email protected]:6666
CSeq: 30656 BYE
Server: Sippy
Content-Length: 0
`

This is starting to look more like a network issue than a provider issue. I’m going to guess they are sending back the ACK.

16

This is my first pjsip trunk test. Same sip trunk works fine with Fibernetics. Test was on IVR, however there is same result when forwarded directly to extension. There is no issue with audio, both ways. I am afraid that Fibernetics will not help, since they do not support commercial environments, but will try.
Regarding INVITE, my guess is they know where to send it is based on registration.
IVR does not time out, BYE is sent from provider exactly 32 seconds after INVITE all the time.
Same when forwarded to extension.

I will try to migrate different provider during the week and see how it goes.
Thank you for your help.

17

OK, I have one more suggestion after re-reading the thread from the beginning.

You’re registering with them, so I’m going to guess that under Chan_SIP you had a Register string Did it look something like this

register => user:secret@host/16475558888

If that’s the case then go into your PJSIP trunk settings and under the Advanced tab where it says “Contact User” put 16475558888 or whatever is after the that last / in your register string. That is your Contact user which you are missing in your 200 OK’s to the provider when using PJSIP.

1 Like
18

Wow, I missed that. Could have sworn that the Contact headers were the same except for port numbers.
And I’m pretty sure that specifying it explicitly will fix the trouble.

But is this a bug in pjsip? If the registration contact had the DID number filled in automatically, I’d expect the 200 OK to have it also. Possibly, the provider is putting the actual called number in the SIP URI of the INVITE.

19

Could not find Register string in pjsip settings, only in sip, but it sip it looks exactly as you described user:secret@host/16475558888
There is “16475558888” now in “Contact User”, however it is still not there in 200 OK

Contact: <sip:44.55.66.77:6667>

Maybe some other field in Advanced settings?

20

There is no register string in PJSIP, I was using the Chan_SIP one as a reference point. Whatever comes after the / in a Chan_SIP register string is what the provider uses as the Contact User for sending calls to, etc.

There are also no quotes in the setting. Those were more like air quotes since it’s not the actual number you are using. Hence my follow up clarification of “whatever is used after the / put that in the Contact User field”. So remove the quotes and test again.

If it didn’t work, show the actual pjsip logger output from your test.