Unable to answer incoming calls

FreePBX Providers
1

I’m having a problem with my ISP SIP Trunk (IInet). For a while now, it hasn’t been registering with my ISP and as such incoming calls were not working at all. Outbound calls were fine. So i did a yum update, and this “improved” the situation and the trunk is now registering. Outbound calls working fine as before, but now Inbound calls are ringing on my Cisco IP Phone extension, but as soon as I try to answer they disconnect. Log of the call ringing and disconnecting below. Error seems to be related to trying to transcode G.729. Trouble is I’m not trying to use G.729 on either the trunk (have configured it for only G.711 ulaw and alaw) nor the IP Phone the call is terminating on. I have disallowed all codecs on the extension config, and only allowed ulaw and alaw. The inbound invite from the ISP is also below. The trace on the extension side shows G.711 ulaw being successfully negotiated.

Any ideas what could be wrong.

Asterisk Log:
[2020-01-14 12:38:30] VERBOSE[16963][C-0000001b] app_dial.c: Connected line update to PJSIP/iinet-00000038 prevented.
[2020-01-14 12:38:30] VERBOSE[16963][C-0000001b] app_dial.c: PJSIP/101-00000039 is ringing
[2020-01-14 12:38:30] VERBOSE[16963][C-0000001b] app_dial.c: PJSIP/101-00000039 is ringing
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] app_dial.c: PJSIP/101-00000039 answered PJSIP/iinet-00000038
[2020-01-14 12:38:33] VERBOSE[16964][C-0000001b] bridge_channel.c: Channel PJSIP/101-00000039 joined ‘simple_bridge’ basic-bridge
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] bridge_channel.c: Channel PJSIP/iinet-00000038 joined ‘simple_bridge’ basic-bridge
[2020-01-14 12:38:33] WARNING[16963][C-0000001b] translate.c: No translator path: (ending codec is not valid)
[2020-01-14 12:38:33] WARNING[16963][C-0000001b] translate.c: No translator path: (ending codec is not valid)
[2020-01-14 12:38:33] WARNING[16964][C-0000001b] channel.c: Unable to find a codec translation path: (g729) -> (alaw)
[2020-01-14 12:38:33] VERBOSE[16964][C-0000001b] bridge_channel.c: Channel PJSIP/101-00000039 left ‘simple_bridge’ basic-bridge
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] bridge_channel.c: Channel PJSIP/iinet-00000038 left ‘simple_bridge’ basic-bridge
[2020-01-14 12:38:33] WARNING[16963][C-0000001b] channel.c: Unable to find a codec translation path: (g729) -> (alaw)
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] app_macro.c: Spawn extension (macro-dial-one, s, 54) exited non-zero on ‘PJSIP/iinet-00000038’ in macro ‘dial-one’
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on ‘PJSIP/iinet-00000038’ in macro ‘exten-vm’
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx.c: Spawn extension (ext-local, 101, 2) exited non-zero on ‘PJSIP/iinet-00000038’
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx.c: Executing [h@ext-local:1] Macro(“PJSIP/iinet-00000038”, “hangupcall,”) in new stack
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/iinet-00000038”, “1?theend”) in new stack
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/iinet-00000038”, “0?Set(CDR(recordingfile)=)”) in new stack
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“PJSIP/iinet-00000038”, “”) in new stack
[2020-01-14 12:38:33] VERBOSE[16963][C-0000001b] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘PJSIP/iinet-00000038’ in macro ‘hangupcall’

Inbound Invite from ISP:
No. Time Source Destination Protocol Length Info
480 31.903656 203.55.231.200 192.168.100.100 SIP/SDP 878 Request: INVITE sip:[email protected]:5060 |

Frame 480: 878 bytes on wire (7024 bits), 878 bytes captured (7024 bits) on interface \Device\NPF_{E52C8EC1-5642-4A42-BEA3-3A10B7D186F4}, id 0
Ethernet II, Src: Cisco_34:ba:05 (00:24:c4:34:ba:05), Dst: HewlettP_7f:bc:ee (30:e1:71:7f:bc:ee)
Internet Protocol Version 4, Src: 203.55.231.200, Dst: 192.168.100.100
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]:5060
Request-URI User Part: 0731224895
Request-URI Host Part: 192.168.100.100
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 203.55.231.200:5060;branch=z9hG4bKd0ej18102gr7csis0jo0.1
From: sip:[email protected];user=phone;tag=876634584-1578960212713-
SIP from address: sip:[email protected];user=phone
SIP from tag: 876634584-1578960212713-
To: "Not Known"sip:[email protected]
SIP Display info: “Not Known”
SIP to address: sip:[email protected]
Call-ID: [email protected]
[Generated Call-ID: [email protected]]
CSeq: 279865717 INVITE
Sequence Number: 279865717
Method: INVITE
Contact: sip:[email protected]:5060;transport=udp
Contact URI: sip:[email protected]:5060;transport=udp
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Recv-Info: x-broadworks-client-session-info
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 176
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): BroadWorks 111915857 1 IN IP4 203.55.231.203
Session Name (s): -
Connection Information ©: IN IP4 203.55.231.203
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 43050 RTP/AVP 8 0 18 101
Media Type: audio
Media Port: 43050
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-15
[Generated Call-ID: [email protected]]

200OK from FreePBX:

No. Time Source Destination Protocol Length Info
498 34.143994 192.168.100.100 203.55.231.200 SIP/SDP 957 Status: 200 OK |

Frame 498: 957 bytes on wire (7656 bits), 957 bytes captured (7656 bits) on interface \Device\NPF_{E52C8EC1-5642-4A42-BEA3-3A10B7D186F4}, id 0
Ethernet II, Src: HewlettP_7f:bc:ee (30:e1:71:7f:bc:ee), Dst: Cisco_34:ba:05 (00:24:c4:34:ba:05)
Internet Protocol Version 4, Src: 192.168.100.100, Dst: 203.55.231.200
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 480]
[Response Time (ms): 2241]
Message Header
Via: SIP/2.0/UDP 203.55.231.200:5060;rport=5060;received=203.55.231.200;branch=z9hG4bKd0ej18102gr7csis0jo0.1
Call-ID: [email protected]
[Generated Call-ID: [email protected]]
From: sip:[email protected];user=phone;tag=876634584-1578960212713-
SIP from address: sip:[email protected];user=phone
SIP from tag: 876634584-1578960212713-
To: “Not Known” sip:[email protected];tag=9fb48522-6188-4229-86d7-24f2fc64f4ac
SIP Display info: “Not Known”
SIP to address: sip:[email protected]
SIP to tag: 9fb48522-6188-4229-86d7-24f2fc64f4ac
CSeq: 279865717 INVITE
Sequence Number: 279865717
Method: INVITE
Server: FPBX-13.0.197.21(13.29.2)
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Contact: sip:192.168.100.100:5060
Contact URI: sip:192.168.100.100:5060
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 257
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 111915857 3 IN IP4 192.168.100.100
Session Name (s): Asterisk
Connection Information ©: IN IP4 192.168.100.100
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 15914 RTP/AVP 8 0 101
Media Type: audio
Media Port: 15914
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): maxptime:150
Media Attribute Fieldname: maxptime
Media Attribute Value: 150
Media Attribute (a): sendrecv
[Generated Call-ID: [email protected]]

2

Bizarre – AFAICT, Asterisk is properly offering only alaw and ulaw, but the ISP seems to be sending g729 anyhow.

Though it doesn’t seem related, it’s strange that the 200 OK has Asterisk’s private address in the SDP. In Asterisk SIP Settings, confirm that External Address and Local Networks are correctly set. There is also External IP Address and Local network in the pjsip-specific settings, which should be left blank (or correctly set).

Also, check Media Address in the trunk settings, which should normally be left blank.

If you change any of the above, restart (not just reload) Asterisk.

Possibly, your router has a SIP ALG that is messing things up. Turn this off, if a setting is available.

If you still have trouble, look at the RTP with tcpdump / Wireshark and see whether the ISP is actually sending g729. If so, try to get their support to fix it or at least explain what is happening. While you could set up Asterisk to transcode it, that’s a significant voice quality impairment that can almost certainly be avoided.

If you post new logs, type
pjsip set logger on
at the Asterisk command prompt before making your test call. That will include the SIP trace in the log file, in a format that is easier to read than the expanded output from Wireshark. Paste the log at https://pastebin.freepbx.org and post a link here.

3

Thanks Stewart. You are right, when I filter the trace for RTP, FreePBX is sending alaw to the ISP, but the ISP is sending G.729.

I will work my way through your suggestions and post back soon.

4

One question though. In the Invite from the ISP, there are no media attributes specified for any of the codecs? Is that normal?

5

It’s normal, because there are predefined defaults (8 kHz sampling, format 8=G.711a), which the ISP is presumably using. In any case, Asterisk’s 200 response seems proper, so that wouldn’t explain the bogus RTP. It seems especially unusual in that it’s the third offering and there was presumably no G.729 coming toward the ISP, as the call was from a domestic mobile.

1 Like
6

So external IP in Asterisk SIP settings is set to 192.168.100.100 and local network is 192.168.100.0/24. I tried Detecting network settings, which changed the IP address to my public IP, but that broke everything so I set it back to the internal IP address. pjsip specific settings are blank.

I couldn’t find any media address setting in the pjsip trunk, but direct media was set to no.

Here’s the log with SIP tracing:
https://pastebin.freepbx.org/view/4ee345d2

7

When Asterisk is behind a NAT, the usual setup has External IP set to the public address. Asterisk emulates being on a public IP when communicating with an extension or trunk outside the LAN. This typically requires the router to forward the RTP port range (default is UDP 10000 to 20000) to the private IP address of the PBX. We could proceed down that path and try to find why that ‘broke everything’. After changing External IP and restarting Asterisk, can your phones still register? Do calls between extensions work? Does the trunk register? If so, what happens on outbound call attempts? On inbound attempts?

IMO pjsip was pretty immature in Asterisk 13. Upgrading to Asterisk 16 (probably with FreePBX 15) would be another possibility.

Trying with a chan_sip trunk is yet another option.

8

Thanks for your advice Stewart. Yes I should have been a little less sensationalist there. When I changed the external IP, outbound calling still worked, extension to extension calling still worked. Just inbound on the trunk stop working completely. By this I mean I see no trace of an incoming invite, so my suspicion is that the trunk did not register again. This was my original problem before I did the yum updates.

BTW, I should mention that some time ago (like maybe 6 months ago) this was all working fine. About the only thing I ever do to this PBX is update it and I suspect that’s what originally broke the inbound calling.

I think my Cisco 877 SIP ALG is handling all the NAT and header manipulation correctly. It’s a bit of mission to disable that.

Yes I’ve been putting off the FreePBX 14 (and now 15) upgrades for a while now, because I’m on a distro and it’s a bit more complicated. My Linux skills aren’t great (I know enough to be dangerous) and I was worried about the network adapter renaming issue. Maybe I just need to bite the bullet there.

9

In a simple configuration, assuming that the RTP port range is forwarded, all you should need is
no ip nat service sip udp port 5060
But if you have fancy firewall rules, it could be more complex.

The good news is that with an IOS router, you can capture traffic on the WAN side to see whether the header manipulation is causing trouble.

10

Yeah I’ve got that zone based firewall configured, as at one point I was using one of Cisco’s config tools. I haven’t touched it in years. Does my head in. I might try the WAN capture. I remember that was a bit of a mission too, needing to TFTP the buffer off the router.

NBN is coming soon and the router will get replaced then, so I’m thinking I’ll try the upgrade path.

11

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