Outgoing calls not working, SIP/2.0 401 Unauthorised

[fireblade]

I am having problems with outgoing calls on FusionBPX
The gateway is registered and incoming calls and internal calls appear to work fine

Outgoing calls dont work

PBX is connected to the internet via a pfsense router using native IPv6 connection, and the firewall logs dont show it being blocked

a packet capture shows

INVITE sip:<redacted>@voiceless.aa.net.uk SIP/2.0
SIP/2.0 401 Unauthorised
ACK sip:<redacted>@voiceless.aa.net.uk SIP/2.0

then several TCP packets to port 5060 which are denyed by the server
and it stops

there is no attempt to authenticate and i cant see a setting that relates to this

but logs as far as i can tell doesnt mention authentication and just has

[NOTICE] sofia.c:8559 Hangup sofia/internal-ipv6/<redacted>[CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE]
[NOTICE] switch_core_session.c:1744 Session 4 (sofia/internal-ipv6/<redacted>) Ended
[NOTICE] switch_core_session.c:1748 Close Channel sofia/internal-ipv6/<redacted>[CS_DESTROY]

[INFO] mod_dptools.c:3631 Originate Failed. Cause: NORMAL_TEMPORARY_FAILURE
[NOTICE] switch_core_state_machine.c:386 sofia/internal/01@<redacted> has executed the last dialplan instruction, hanging up.

can anyone suggest how to fix this?

i can post more complete logs if needed

 

[Adrian Fretwell]

You should talk to your SIP provider. If the providers proxy was wanting you to perform a user authentication then it would have sent a 407 Proxy Authentication Required. The immediate 401 suggests to me that the proxy doesn't like your INVITE for some other reason, for example, not originating from an authorised IP address.

It is easier to help you if you post the full packets, not just the request/status line.

 

[fireblade]

here is full SIP capture

i dont think there is a proxy, so 407 may not apply

INVITE sip:<redacted>@voiceless.aa.net.uk SIP/2.0
Via: SIP/2.0/UDP [<redacted>];rport;branch=z9hG4bKjvvvjQgD31cjH
Max-Forwards: 69
From: "01" <sip:+<redacted>@voiceless.aa.net.uk>;tag=ZBFDpZSp7Qg3c
To: <sip:<redacted>@voiceless.aa.net.uk>
Call-ID: eb16c42c-b411-1239-b5ab-00505691114d
CSeq: 29167947 INVITE
Contact: <sip:gw+873d8a13-2986-481d-aa3f-a1b6d0a7ba9a@[<redacted>]:5060;transport=udp;gw=873d8a13-2986-481d-aa3f-a1b6d0a7ba9a>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 304
X-FS-Support: update_display,send_info
Remote-Party-ID: "01" <sip:01@voiceless.aa.net.uk>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1607414672 1607414673 IN IP6 <redacted>
s=FreeSWITCH
c=IN IP6 <redacted>
t=0 0
m=audio 29718 RTP/AVP 9 0 8 101 13
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
SIP/2.0 401 Unauthorised
Via: SIP/2.0/UDP [<redacted>];received=<redacted>;rport=5060;branch=z9hG4bKjvvvjQgD31cjH
CSeq: 29167947 INVITE
Call-ID: eb16c42c-b411-1239-b5ab-00505691114d
From: "01" <sip:+<redacted>@voiceless.aa.net.uk>;tag=ZBFDpZSp7Qg3c
To: <sip:<redacted>@voiceless.aa.net.uk>
WWW-Authenticate: Digest realm="FireBrick",qop="auth",nonce="270003440103202012081604400A9AB69B6F69B4C8",algorithm=MD5
Content-Length: 0

ACK sip:<redacted>@voiceless.aa.net.uk SIP/2.0
Via: SIP/2.0/UDP [<redacted>];rport;branch=z9hG4bKjvvvjQgD31cjH
Max-Forwards: 69
From: "01" <sip:+<redacted>@voiceless.aa.net.uk>;tag=ZBFDpZSp7Qg3c
To: <sip:<redacted>@voiceless.aa.net.uk>
Call-ID: eb16c42c-b411-1239-b5ab-00505691114d
CSeq: 29167947 ACK
Content-Length: 0

 

[Adrian Fretwell]

Ok, so the 401 response does contain a WWW-Authenticate header, This is normal in order to set up the proxy authentication process. So after the ACK you should see another INVITE go out with a Proxy-Authorization header.

Looking at the Contact header in the INVITE, it looks like your ipv6-external profile is signalling on port 5060, on a default installation I would have expected this to be 5080.

Does your gateway use a username and password to register and is it using the external SIP profile?

 

[fireblade]

yes registers using a username and password, which registers without issues

it is currently using the ipv6-internal profile

 

[Adrian Fretwell]

Any reason for setting up a gateway on an internal profile? External is the norm for gateways and there are a few configuration differences between internal and external.

 

[fireblade]

no specific reason

the profile description doesnt realy mention how profiles relate to gateways and says is optional "External ipv6 sip profiles (port 5080-5081) allow anonymous connection to FusionPBX and is optional." (https://docs.fusionpbx.com/en/latest/advanced/sip_profiles.html)

all phones use internal profiles

i can change it if you think it will make a diference

 

[Adrian Fretwell]

It should work OK with the internal profile. What I don't understand is why FreeSWITCH is not responding to the 401 with a second INVITE containing a Proxy-Authorization header (authentication digest).

Does your realm setting in your gateway record match the Digetst-realm in the WWW-Autenticate header of the 401?

It may be worth setting the gateway to use the external profile as a diagnostic step. I'm trying to think what else may be going on to cause this...

 

[DigitalDaz]

I would get that gateway onto the external profile where it belongs.

Unless it is redacted, its possible AA are 401 due to the RPID.

Solving outbound is always a problem because you have to send what the carrier expects.

If you cannot resolve it, send them the capture of the INVITE, they should be able to tell you if there are problems with it.

 

[mcs3ss2]

I have noticed in the latest build that if I define outbound all together i.e 8 digit 10 digit international etc in single save i get the above error
but when i define each outbound rout individually like add outbound routre for 8 gidits save then add new 10 digits save and so forth then it works flawlesly

 

[mcs3ss2]

Donot do this


But instead do this


and


and so forth based on your locality. It should work.

Example 8 and 10 I used is good for my local and national numbers etc. Yours may vary.

 

[fireblade]

I reinstalled the VM and setup using the external-ipv6 profile

Ive changed the profile to external and registers correctly on as that
had to add "apply-inbound-acl domains" to the external-ipv6 to get incoming calls to work

but discovered something interesting

using the console and "sofia profile external-ipv6 siptrace on"

siptrace show attempts at trying to send authentication

which caused me to check local tcpdump which also showed the packets, so i checked the firewall packed dump in the internal interface

and the packets are detected there

the issue appears to be related to IPV6 UDP packet size and fragmentation and pfsense

it looks like the PBX is not attempting to fragment the packets to FIT the MTU

... frag (0|1448) 5080 > 5060: UDP, bad length 1455 > 1440

or pfsense is not sending the right icmp message to say it needs to

its also possibe pfsense is doing something od with its mtu as 1440 seems low


at a closer the pbx appears to be fragmenting the packets but the inital packet is still to large

 

[DigitalDaz]

So why don't you just switch to TCP?

 

[Adrian Fretwell]

1440 does seem low. You can test the MTU using ping and the -s switch to specify the packet size. Remember that the ICMP packet will be 28 bytes larger than the -s value owing to the header overheads (don't ping IPs like google, they often don't respond to large packet sizes).

From home on my FTTP I see an MTU of 1480, this is basically 1500 minus the 20 byte PPPoE encapsulation overhead:

adrian@a2es-devwork:~$ ping -c 1 -s 1452 185.194.xxx.xx
PING 185.194.xxx.xxx (185.194.xxx.xxx) 1452(1480) bytes of data.
1460 bytes from 185.194.xxx.xxx: icmp_seq=1 ttl=57 time=16.0 ms

adrian@a2es-devwork:~$ ping -c 1 -s 1453 185.194.xxx.xxx
PING 185.194.xxx.xxx (185.194.xxx.xxx) 1453(1481) bytes of data.
From 192.168.61.1 icmp_seq=1 Frag needed and DF set (mtu = 1480)

But the same test between my data centres will allow larger packets:

root@a2estest2:~# ping -c 1 -s 2000 185.194.xxx.xxx
PING 185.194.xxx.xxx (185.194.xxx.xxx) 2000(2028) bytes of data.
2008 bytes from 185.194.xxx.xxx: icmp_seq=1 ttl=57 time=22.2 ms

You can reduce the packet size by removing unwanted headers, switching to compact headers and reducing the number of codecs offered in the SDP body.