PJSIP (outbound) connects to different IPs

Asterisk Asterisk Support
1

Hello people of Asterisk,
I set up a new Asterisk box with Asterisk 13.14.0 (self-compiled) on Debian jessie. This is my first installation using PJSIP.
I am migrating from another system which runs Asterisk 11.
I built the config files by first using the chan_sip->pjsip converter script and cross checking the manual and hints which can be found in the Asterisk wiki.

Inbound calls work fine, but - according to the logs - the INVITE my Asterisk sends to the provider (Deutsche Telekom) is directly answered with an 403 FORBIDDEN.

I further looked into the logs and found out the following:
The registration is done against 217.0.23.44 successfully, but when I try to initiate an outbound call, 217.0.23.36 is consulted.

Any hints? My Asterisk runs mostly with default config files resp. no config files for unneeded modules.

I also did an upgrade to Asterisk 13.15.0, which did not change anything.
This is my pjsip.conf

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0

This is my pjsip_wizard.conf:

[telekom-template](!)
type = wizard
transport = transport-udp
endpoint/allow=!all,g722,ulaw,alaw,g729,gsm
endpoint/context=ankommend

sends_auth = yes
sends_registrations = yes
remote_hosts = tel.t-online.de
endpoint/from_domain=tel.t-online.de

;aor/qualify_frequency = 15
aor/default_expiration=585
registration/retry_interval = 60
registration/server_uri=sip:tel.t-online.de
endpoint/dtmf_mode=rfc4733
max_retries=0
endpoint/direct_media=no
outbound_auth/realm=tel.t-online.de
;NAT-Kram:
endpoint/force_rport=yes
endpoint/rewrite_contact=yes
endpoint/rtp_symmetric=yes

[ko123456789](telekom-template)
outbound_auth/username = 040123456789
outbound_auth/password = supergeheim
registration/contact_user=ko123456789
endpoint/from_user=040123456789
aor/contact = sip:040123456789@tel.t-online.de:5060
endpoint/callerid=040123456789

If I use the sip.conf from my old system and run the Asterisk with chan_sip instead of pjsip, everything works fine instantly. So apparently the Asterisk core and the underlying system seem to be OK and the problem seems to be within PJSIP.

Any ideas?

2

The chan_pjsip module, unlike chan_sip, follows the RFC for looking up SIP servers and as a result on each request does a DNS query and determines the location. This means that depending upon the provider there is no guarantee that the REGISTER will go to the same place as the INVITE. In chan_sip DNS resolution is only done at configuration load time and doesn’t change until then. If DNS resolution is resulting in a different IP address then I’d expect the provider to be fine with it, and the provider may be elsewhere. Have you compared the INVITEs between both chan_sip and chan_pjsip for any other stuff?

3

I think there are indeed some other differences.
Basically, I notice that with chan_pjsip, the answer to the INVITE directly is the FORBIDDEN.
With chan_sip, the provider answers with 407 Proxy Authentication Required, which is answered by the asterisk with an ACK, a new INVITE containing authentication data.

This is the INVITE when using chan_sip, what is answered by the 407:

<--- Transmitting (NAT) to 192.168.178.200:1040 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.178.200:1040;branch=z9hG4bK-tf5vve24l0y7;received=192.168.178.200;rport=1040
From: "Asterisk neu" <sip:my-voip-phone@192.168.178.12>;tag=l7iwyeaoog
To: <sip:08003301000@192.168.178.12;user=phone>
Call-ID: 31353...d8uka
CSeq: 2 INVITE
Server: Asterisk PBX 13.16.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:08003301000@192.168.178.12:5060>
Content-Length: 0


<------------>
Audio is at 17158
Adding codec g722 to SDP
Adding codec alaw to SDP
Adding codec ulaw to SDP
Adding codec g729 to SDP
Adding codec gsm to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 217.0.23.72:5060:
INVITE sip:08003301000@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 192.168.178.12:5060;branch=z9hG4bK7f38e426;rport
Max-Forwards: 70
From: "My SIP Deskphone" <sip:023454144420@tel.t-online.de>;tag=as5f4a9584
To: <sip:08003301000@tel.t-online.de>
Contact: <sip:023454144420@192.168.178.12:5060>
Call-ID: 060...7789435@tel.t-online.de
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.16.0
Date: Thu, 20 Jul 2017 05:48:55 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "My SIP Deskphone" <sip:41@tel.t-online.de>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 368

v=0
o=root 507546420 507546420 IN IP4 192.168.178.12
s=Asterisk PBX 13.16.0
c=IN IP4 192.168.178.12
t=0 0
m=audio 17158 RTP/AVP 9 8 0 18 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

---

And this is what chan_pjsip starts and the answer from the provider:

<--- Transmitting SIP request (1040 bytes) to UDP:217.0.23.36:5060 --->
INVITE sip:08003301000@tel.t-online.de:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.12:5060;rport;branch=z9hG4bKPjb8dcb47...3edbef6b5
From: <sip:040123456789@tel.t-online.de>;tag=8f8bd2b...254b5a3
To: <sip:08003301000@tel.t-online.de>
Contact: <sip:040123456789@192.168.178.12:5060>
Call-ID: 6054a...3e2
CSeq: 14923 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 13.16.0
Content-Type: application/sdp
Content-Length:   354

v=0
o=- 1575479619 1575479619 IN IP4 192.168.178.12
s=Asterisk
c=IN IP4 192.168.178.12
t=0 0
m=audio 6576 RTP/AVP 9 0 8 18 3 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (404 bytes) from UDP:217.0.23.36:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.178.12:5060;received=79.227.245.157;rport=62226;branch=z9hG4bKPjb...-0253edbef6b5
To: <sip:08003301000@tel.t-online.de>;tag=h7g4Es...o4j7w6uxb5
From: <sip:040123456789@tel.t-online.de>;tag=8f8bd...3254b5a3
Call-ID: 6054a84...1073a3e2
CSeq: 14923 INVITE
Content-Length: 0

08003301000 is the number I try to call
040123456789 is my phone number
192.168.178.12 is my Asterisk server
192.168.178.200 is my SIP deskphone

4

So, does anyone have any idea? Or is there something I could investigate further?

5

OK, this gets strange. I managed to do an outbound call by throwing away my PJSIP config and using the configuration proposed here:
http://www.buessert.de/Technik/Linux/Asterisk/
(The website itself is in German but you will get the pjsip.conf contents).
I will see if I find out if there are fundamental differences in my pjsip_wizard.conf and the website’s proposed pjsip.conf.

BUT:
I now got the chance to compare the SIP INVITE which is sent by the working pjsip.conf and the non-working pjsip_wizard.conf.
There are literally no differences except the fact that in the working case the INVITE is sent to UDP:217.0.27.107:5060 and in the non-working case to UDP:217.0.23.132:5060.
In the working case, the INVITE is answered by the provider with SIP/2.0 407 Proxy Authentication Required. Asterisk authenticates and the call is established.

In the non-working case, as above, a 403 Forbidden is received.

6

OK, the reason why there is a “wrong” IP address, in this case 217.0.23.132, is apparently the following:
217.0.23.132 is a host that belongs to tel.t-online.de, but is apparently no host that is relevant for serving me as a SIP user.
Instead, a pjsip show identifies gives me:

Match: 217.0.27.107/32
Match: 217.0.28.107/32
Match: 217.0.20.212/32

which apparently are hosts which can be gathered by reading the SRV records for sip from tel.t-online.de.

I could solve this by exchanging

aor/contact = sip:040123456789@tel.t-online.de:5060

by

aor/contact = sip:tel.t-online.de

I also deleted

outbound_auth/realm=tel.t-online.de

And I added

registration/client_uri=sip:040123456789@tel.t-online.de

This solved my issue. Finally, I can go ahead and set up my other accounts now :slight_smile:

1 Like