Outbound route working but inbound isn't at all


#1

Hey guys,

I added a new trunk and it’s working for outbound now.
Unfortunately inbound isn’t working at all.

I activated pjsip logger and checkt the history.
I have an inbound-route (any-any) so I should receive everything?

On an inbound call I get the following log:

Event1:

<— History Entry 569 Received from 88.79.204.9:5060 at 1563208936 —>
INVITE sip:MY_EXTERNAL_NUMBER@pbx1.nucleus.ngn.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 88.79.204.9:5060;received=88.79.204.9;branch=z9hG4bKrkmtgr009837vfa01600.1;origin=172.19.116.80
To: sip:MY_EXTERNAL_NUMBER@nbgsx001.ngn.vodafone.de;user=phone
From: sip:CALLING_NUMBER@ims.vodafone.de;user=phone;tag=SDvao3a01-e398456e
Call-ID: SDvao3a01-7b27dc6a53070acda0d03a904428df03-ct4u830000
CSeq: 1 INVITE
Max-Forwards: 60
Contact: sip:CALLING_NUMBER@88.79.204.9:5060;transport=udp
Date: Mon, 15 Jul 2019 18:42:16 GMT
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE
Supported: resource-priority
P-Asserted-Identity: sip:CALLING_NUMBER@ims.vodafone.de;user=phone
P-Asserted-Identity: tel:CALLING_NUMBER
Accept: application/sdp
P-Early-Media: supported
Content-Type: application/sdp
Content-Length: 289
Content-Type: application/sdp
Content-Length: 289

v=0
o=- 0 0 IN IP4 88.79.204.9
s=IMSS
c=IN IP4 88.79.204.9
t=0 0
m=audio 55004 RTP/AVP 96 9 8 101 102
a=rtpmap:101 telephone-event/8000
a=rtpmap:102 telephone-event/16000
a=ptime:20
a=maxptime:30
a=fmtp:96 mode-set=0,1,2; mode-change-period=2; mode-change-neighbor=1; max-red=0

Event2:

<— History Entry 570 Sent to 88.79.204.9:5060 at 1563208936 —>
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 88.79.204.9:5060;rport=5060;received=88.79.204.9;branch=z9hG4bKrkmtgr009837vfa01600.1;origin=172.19.116.80
Call-ID: SDvao3a01-7b27dc6a53070acda0d03a904428df03-ct4u830000
From: sip:CALLING_NUMBER@ims.vodafone.de;user=phone;tag=SDvao3a01-e398456e
To: sip:MY_EXTERNAL_NUMBER@nbgsx001.ngn.vodafone.de;user=phone;tag=z9hG4bKrkmtgr009837vfa01600.1
CSeq: 1 INVITE
Warning: 399 SIP “Missing SDP rtpmap for dynamic payload type (PJMEDIA_SDP_EMISSINGRTPMAP)”
Server: FPBX-14.0.13.4(15.4.0)
Content-Length: 0

Event3:

<— History Entry 571 Received from 88.79.204.9:5060 at 1563208936 —>
ACK sip:MY_EXTERNAL_NUMBER@pbx1.nucleus.ngn.vodafone.de:5060 SIP/2.0
Via: SIP/2.0/UDP 88.79.204.9:5060;received=88.79.204.9;branch=z9hG4bKrkmtgr009837vfa01600.1;origin=172.19.116.80
CSeq: 1 ACK
To: sip:MY_EXTERNAL_NUMBER@nbgsx001.ngn.vodafone.de;user=phone;tag=z9hG4bKrkmtgr009837vfa01600.1
From: sip:CALLING_NUMBER@ims.vodafone.de;user=phone;tag=SDvao3a01-e398456e
Call-ID: SDvao3a01-7b27dc6a53070acda0d03a904428df03-ct4u830000
Max-Forwards: 60
Content-Length: 0
Content-Length: 0


#2

Can you try with a catch-all inbound route?


#3

As I wrote, I have a any<->any inbound route. Isn’t that catch all? Or is there anything else I have to setup allow everything?

I also found a setting in my trunk “Match Inbound Authentication”.
I tried all options, but without any influence.


(Itzik) #4

Can you post your Trunk config?


#5

sure.

General:
Outbound CallerID: [BLOCK_NUMBER_0]
CID-Options: allow any
trunk dial options: any

pjsip-settings:

authentication: none
registration: none
sip-server: 88.79.204.9 (VF-SBC IP)
sip-server-port: 5060
context: from-pstn
transport: 0.0.0.0-udp

Advanced:

DTMF-Mode: Auto
Permanent Auth Rejection: Yes
Forbidden retry interval: 10
fatal retry inverval. 0
general retry inverval: 60
Expiration: 3600
Max Retries: 10
Qualify Frequency: 0
Outbound Proxy: sip:88.79.204.9:5060\;lr
Contect User: EMPTY
From Domain: xxxxxxx.ngn.vodafone.de
From User: EMPTY
Client URI: EMPTY
Server URI: EMPTY
Media Address: EMPTY
AOR: EMPTY
AOT Contact: EMPTY
Match (permit): 88.79.204.9
Support Path: No
Support T.38 UDPTL: No
T.38 UDPTL Error Correction: None
T.38 UDPTL NAT: No
T.38 UDPTL MaxDatagram: EMPTY
FAx Detect: No
Trust RPID/PAI: Yes
Send RPID/PAI No
Match Inbound Authentication: IP
Inband Progress: No
Direct Media: No
Rewrite Contact: Yes
RTP Symmetric: Yes
Media Encryption: None
Message Context: EMPTY


#6

Sorry, my bad, I overlooked the any-any route.


#7

So does nobody have any idea??
What can I do to find the problem?


#8

As I mentioned in your other thread, the INVITE that Asterisk is receiving from Vodafone is corrupted. Possibly your router / firewall / SBC is damaging the packet. If you have such equipment, try capturing traffic on the WAN interface to see if the packet is bad from Vodafone.

If so, perhaps their support can help, or maybe chan_sip will accept the packet, or you might be able to get help from the pjsip folks.

If the packet from Vodafone is ok, find where the packet is getting mangled; perhaps a configuration change or software update will fix it.


#9

Hi Stewart1,

but what is corrupted on the INVITE? It looks ok to me.
Do you see anything wrong on that message?

I have an opnsense running between pbx and wan.
I’m using 1:1 NAT and right now I’m allowing more traffic than necessary (in my opinion).

Firewall Rule allows:
Port: 55000 - 55008 (UDP)
Port: 10000 - 20000 (UDP)
Port: 5060 - 5061 (UDP)


#10

The SDP contains:

v=0
o=- 0 0 IN IP4 88.79.204.9
s=IMSS
c=IN IP4 88.79.204.9
t=0 0
m=audio 55004 RTP/AVP 96 9 8 101 102
a=rtpmap:101 telephone-event/8000
a=rtpmap:102 telephone-event/16000
a=ptime:20
a=maxptime:30
a=fmtp:96 mode-set=0,1,2; mode-change-period=2; mode-change-neighbor=1; max-red=0

The ‘m’ line means that their server is ‘offering’ payload types (codecs) 96, 9, 8, 101, and 102. In RTP, payload types below 96 are predefined (registered with IANA); see
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

96 and up are ‘dynamic’ types and are normally defined with an rtpmap attribute. There is no mapping for 96; pjsip considers that an error and rejects the request with a 400. However, I just read the RFC and saw that it’s not mandatory. See https://tools.ietf.org/html/rfc4566 page 24. This seems bizarre to me (I suppose that if there is no mapping it is defined by prior agreement between the parties). Of course, pjsip wouldn’t know what to do with the 96 and IMO should just ignore it and select another codec from the choices offered.

Some guesses as to how you can fix this:

  1. Confirm (by capturing traffic on the WAN interface) that OPNsense is not altering the packet.

  2. Try a chan_sip trunk; it may be more forgiving.

  3. There might be a setting on the Vodafone portal that would disable sending you AMR-WB (or all HD codecs).

  4. Find a sufficiently high level person at Vodafone support and explain that the unusual behavior of there system is incompatible with recent Asterisk/pjsip. They may be able to change a setting at their end.

  5. Post an issue on the pjsip mailing list.

  6. Dig into the source code and try to fix it yourself.

  7. Put some proxy or SBC in the path that will clean up the problematic request.

Edit: for reference, here is SDP from a call on my Voxbeam trunk (carrier is British Telecom):

v=0
o=sbc-uk-mr-dh03a 288828417 1562844163 IN IP4 193.113.127.218
s=sip call
c=IN IP4 193.113.127.212
t=0 0
m=audio 10580 RTP/AVP 9 113 8 0 18 101
a=rtpmap:9 G722/8000
a=rtpmap:113 AMR-WB/16000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
a=ptime:20
a=fmtp:113 octet-align=0;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0

Note the rtpmap for PT 113 (AMR-WB).


#11

Hello Stewart1,

thank you very much for the detailed answer.
I already discussed that with vodafone but it seems that they cannot do anything about it as this message comes from the caller.

I can see that some calls are coming through when the caller sends a correct invite.
In my opinion the problem is PJSIP as it gives a BAD REQUEST answer. It should simply ignore that codec and work with the other codecs…

My main problem is, that until today it was just a test-phonenumber, but now they ported our real number and many poeple can no longer call us.


#12

I absolutely agree, though I was very surprised to learn that the rtpmap attribute on a dynamic PT is not mandatory.

Ouch. Have you tried a chan_sip trunk? If that doesn’t work but the issue is different, post details – there may be an easy fix.

Other ideas for a quick fix (I don’t know if any are feasible):

Can Vodafone forward the calls to a DID at another provider (your old one or a third one you may have)?

Possibly, having Vodafone send to a provider that accepts calls by SIP URI, would launder the request so pjsip or chan_sip would accept it.

If you can quickly try the Vodafone trunk with a competing PBX (FusionPBX, 3CX, Vodia, etc.) and it works, you could set that up to relay your calls to FreePBX. Or, do the same thing with an SBC, or possibly a SIP proxy.

If all else fails:

Have a script monitor the log for these failures and have someone call the people back. Unfortunately, this won’t work if many of your callers are companies that just present their main number.

Can you temporarily get the port reversed?


#13

Vodafone “is working on that problem”…

The problem is even more strange.
It’s not happening with every caller, it depends on the provider.

Today we had many incoming calls but as soon as someone calls from a vodafone mobile-number we get the BAD REQUEST problem. As we also use vodafone mobile phones we can reproduce it all the time…

I don’t know how many providers are sending wrong invites but today we only had the problem with vodafone mobile.


(system) closed #14

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