Inbound Calls from O²-mobile-number drop after ~ 40 seconds

Hi there!

I’am using a Vodafone (Germany) test-trunk with some testnumbers. It’s working fine so far with inbound and outbound calls and a few more settings like groups, pickup-groups, fax and so on.

But there’s one main problem at the moment: Calling my extension inbound from a smartphone which contains a O²-mobile-number, the call hangs up after ca. 40-45 seconds. Calling the O²-mobile-number from the extension outbound, the call works fine and don’t hang up. Calling inbound and outbound from a Vodafone-landline-number or a Vodafone-mobile-number, the calls also doesn’t have any problems at all and the voice flow stays fine.

Tomorrow, i’am sending some logs for you - but is there anything to check-up first? Did you have that problem before by yourselv? It’s very interesting that this problem only appears while calling from O² inbound to the PBX, but calling O² outbound works fine …

Tomorrow i also check up one or two other providers to see if the problem appears also when calling into the PBX.

Thanks a lot for any help!

Search through the forum for “call drop 30 second”.

Here’s one:

I suspect you’re going to find that the process this article (and many more like it) is going to be where you need to end up.

Thanks for that first tip!
I will search trough the forum and trying out the solutions which works for other users and report here again.

Eventually, maybe - someone else got a tip to search / look for.

The stack i want to share is to big (over 32000) to provide it in this thread…
I uploadet it here:

I cant provide this huge codestack elsewhere.
Do you see any problem in this stack? In my opinion there’s no main error/failure which provides the hard hang up in this case…
It seems to be the 30 seconds call-drop problem - but did you see anything in the code i provided in the file where i can begin with?

Thanks for any help!

Although I have no idea why the calling number or carrier could possibly matter, it shouldn’t be hard to debug the failing case by itself.

[2020-02-05 08:55:39] VERBOSE[58154][C-000003bd] app_dial.c: PJSIP/2366-00000763 answered PJSIP/Vodafonetrunk-00000762
[2020-02-05 08:55:39] VERBOSE[58155][C-000003bd] bridge_channel.c: Channel PJSIP/2366-00000763 joined 'simple_bridge' basic-bridge <2f0439e0-a3a8-4dec-a8b6-f219531f284d>
[2020-02-05 08:55:39] VERBOSE[58154][C-000003bd] bridge_channel.c: Channel PJSIP/Vodafonetrunk-00000762 joined 'simple_bridge' basic-bridge <2f0439e0-a3a8-4dec-a8b6-f219531f284d>
[2020-02-05 08:56:11] VERBOSE[58154][C-000003bd] bridge_channel.c: Channel PJSIP/Vodafonetrunk-00000762 left 'simple_bridge' basic-bridge <2f0439e0-a3a8-4dec-a8b6-f219531f284d>

I suspect that either the 200 OK sent in response to the incoming INVITE has an incorrect Contact header, that a firewall blocked the ACK from being received, or the format of the ACK was somehow rejected by pjsip.

In Asterisk SIP Settings, confirm that External Address and Local Networks are correctly set.

At the Asterisk command prompt, type
pjsip set logger on
then call in from your O2 mobile, wait for the call to drop and post the log, which will now include the SIP trace.

Instead of using, please paste the log at and post the link here.

1 Like

Thanks Stewart for your reply!
I changed the link for the stack-upload, thanks for the info as well - didn’t know that yet.

So, i’ve tried the trunk with Chan_SIP, instead of PJSIP, and it’s working now without a problem. Thats very intereseting…
I mean… did PJSIP got so much more parameters within the call that this causes the call to drop after 30 seconds and Chan_SIP works fine? Pretty curios…

I’m trying to debug the problem for PJSIP with pjsip set logger on and will send the log from this trace here soon.

Thats so interesting… i’ve changed the trunk back to PJSIP and changed also two test-extensions back to PJSIP from Chan_SIP and changed the specified ports from Chan_SIP 5060 to PJSIP 5060 and no extension can log in to the PBX… if the Chan_SIP port is set back to 5060 and the extensions driver is also changed back to Chan_SIP, the ext can log in.

It would be good to figure out what’s wrong when it’s setup with PJSIP, as chan_sip is slowly going the way of the dinosaur. I’m guessing there’s a PJSIP setting that needs to be set that makes it match chan_sip’s default behavior.

A PCAP of what happens with PJSIP is probably the next essential step to figure out what’s going on.



Some of those settings changes require that Asterisk be restarted (not just reloaded). You also may have to reboot the endpoint after restarting Asterisk. If you still have trouble with this, please post details.

I’m fairly sure that this is the same issue as:
The one in the current thread is a little more complex because the failure is source carrier dependent, but I suspect that’s because a different Vodafone server is involved in the two cases.

The failure is caused by pjsip sending the 200 OK response to an incoming INVITE with a Contact header that does not contain a user part. I believe that is in conformance with the RFCs but differs from industry practice. It appears that some trunking providers fail to parse the header correctly and therefore don’t send an ACK to the correct address. When I looked at the issue in 2018, pjsip had no setting that would force a user in the Contact field (in this situation).

It’s possible that pjsip has since been updated to provide this option, though if so there is nothing in the FreePBX GUI to enable it.

Though IMO this is technically a problem on the trunking provider side, we are very unlikely to get them to correct it, so we need the fix in pjsip.


Thanks for the detailed reply!
I think the best way to get the PBX running stable at the moment with the vodafone-trunk is to use Chan_SIP, even when this is the more easy and dirty way. I know, it’s older, but in my case, its running perfect now without any problems.

In the foreseeable future, i set my PBX up to PJSIP, but for now - i don’t think it’s working very well in our company for this moment and because of that i use Chan_SIP.

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