SIP vs PJSIP trunk

Hello, I am trying to set up Siemens HiPath with Asterisk 20.5/7 over IP. It works with the sip module, but not with pjsip. With pjsip the call (from 28555 to 28245) goes through, but is immediately dropped.

sip.conf

[trunk1]
type=friend
context=set
host=10.57.243.20
permit=0.0.0.0/0.0.0.0
endpoint/allow=!all,ulaw,g722

pjsip.conf

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

[trunk1]
endpoint/allow = !all,ulaw,g722

[trunk1]
type = aor
contact = sip:10.57.243.20

[trunk1]
type = identify
endpoint = trunk1
match = 10.57.243.20

[trunk1]
type = endpoint
context = set
aors = trunk1

[acl]
type = acl
permit = 0.0.0.0/0.0.0.0

Error

srv_asterisk*CLI>
– Executing [28245@set:1] Dial(“PJSIP/28555-00000001”, “PJSIP/28245@trunk1”) in new stack
– Called PJSIP/28245@trunk1
== Everyone is busy/congested at this time (1:0/0/1)
– Auto fallthrough, channel ‘PJSIP/28555-00000001’ status is ‘CHANUNAVAIL’

At first I wrote the pjsip config manually, but it didn’t work. Then I used the sip config and automatically generated pjsip. The error remains. Can someone tell me what I’m doing wrong here please?

This looks like some sort of wizard format,but it is in the standard file and mixed in with standard format entries. It’s also in sip.conf, where there is no wizard option.

The logging isn’t really detailed enough to show the actujl error, but it doesn’t show a call that goes through , but rather one that either fails because there is no way of reaching the destination, or the destination refused the call.

I don’t think your ACL is being used, and the permits are redundant.

I would suggest looking at the logs from when the configuration was loaded.

As a minor quibble, “trunk” is not a term used by SIP and both chan_sip; and chan_pjsip implement SIP, so, given the typical uinderstanding of “trunk”, both are SIP trunks.

check to see if the endpoint is available using the “pjsip show endpoints”.

Now my conf look like:

pjsip.conf
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0

[trunk1]
type = aor
contact = sip:10.57.243.20

[trunk1]
type = identify
endpoint = trunk1
match = 10.57.243.20

[trunk1]
type = endpoint
allow = !all,ulaw,g722
context = set
aors = trunk1
Error
srv_asterisk*CLI> 
<--- Received SIP request (948 bytes) from UDP:10.57.143.88:5060 --->
INVITE sip:28245@10.58.134.34 SIP/2.0
Via: SIP/2.0/UDP 10.57.143.88:5060;branch=z9hG4bK0018b01e52e5ee11bb37950b6019a9ec;rport
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
CSeq: 1 INVITE
Contact: <sip:28555@10.57.143.88>
Content-Type: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Supported: replaces, from-change, 100rel
User-Agent: PhonerLite/3.24
P-Preferred-Identity: <sip:28555@10.58.134.34>
Content-Length:   342

v=0
o=- 1133730223 1 IN IP4 10.57.143.88
s=PhonerLite/3.24
c=IN IP4 10.57.143.88
t=0 0
m=audio 5080 RTP/AVP 8 0 3 9 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:3757306392
a=sendrecv

<--- Transmitting SIP response (546 bytes) to UDP:10.57.143.88:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.57.143.88:5060;rport=5060;received=10.57.143.88;branch=z9hG4bK0018b01e52e5ee11bb37950b6019a9ec
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>;tag=z9hG4bK0018b01e52e5ee11bb37950b6019a9ec
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1710957936/0369c9daeef6e699b010ed392b931435",opaque="4d00ad68703fb809",algorithm=MD5,qop="auth"
Server: Asterisk PBX 20.7.0
Content-Length:  0


<--- Received SIP request (351 bytes) from UDP:10.57.143.88:5060 --->
ACK sip:28245@10.58.134.34 SIP/2.0
Via: SIP/2.0/UDP 10.57.143.88:5060;branch=z9hG4bK0018b01e52e5ee11bb37950b6019a9ec;rport
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>;tag=z9hG4bK0018b01e52e5ee11bb37950b6019a9ec
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
CSeq: 1 ACK
Content-Length: 0


<--- Received SIP request (1242 bytes) from UDP:10.57.143.88:5060 --->
INVITE sip:28245@10.58.134.34 SIP/2.0
Via: SIP/2.0/UDP 10.57.143.88:5060;branch=z9hG4bK0018b01e52e5ee11bb39950b6019a9ec;rport
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
CSeq: 2 INVITE
Contact: <sip:28555@10.57.143.88>
Authorization: Digest username="28555", realm="asterisk", nonce="1710957936/0369c9daeef6e699b010ed392b931435", uri="sip:28245@10.58.134.34", response="1ec5287433973d4658a8019a1f688e59", algorithm=MD5, cnonce="0018b01e52e5ee11bb38950b6019a9ec", opaque="4d00ad68703fb809", qop=auth, nc=00000001
Content-Type: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Supported: replaces, from-change, 100rel
User-Agent: PhonerLite/3.24
P-Preferred-Identity: <sip:28555@10.58.134.34>
Content-Length:   342

v=0
o=- 1133730223 1 IN IP4 10.57.143.88
s=PhonerLite/3.24
c=IN IP4 10.57.143.88
t=0 0
m=audio 5080 RTP/AVP 8 0 3 9 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:3757306392
a=sendrecv

<--- Transmitting SIP response (350 bytes) to UDP:10.57.143.88:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.57.143.88:5060;rport=5060;received=10.57.143.88;branch=z9hG4bK0018b01e52e5ee11bb39950b6019a9ec
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>
CSeq: 2 INVITE
Server: Asterisk PBX 20.7.0
Content-Length:  0


    -- Executing [28245@set:1] Dial("PJSIP/28555-00000006", "PJSIP/28245@trunk1") in new stack
    -- Called PJSIP/28245@trunk1
<--- Transmitting SIP request (936 bytes) to UDP:10.57.243.20:5060 --->
INVITE sip:28245@10.57.243.20 SIP/2.0
Via: SIP/2.0/UDP 10.58.134.34:5060;rport;branch=z9hG4bKPj9aadc1e6-d214-44d9-893e-57086c7a94a5
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=ad320ed3-2b60-4261-a641-19fec82b8227
To: <sip:28245@10.57.243.20>
Contact: <sip:asterisk@10.58.134.34:5060>
Call-ID: 230fa376-ea32-4942-bb2c-a8e112e44b3c
CSeq: 10923 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.7.0
Content-Type: application/sdp
Content-Length:   261

v=0
o=- 1025821819 1025821819 IN IP4 10.58.134.34
s=Asterisk
c=IN IP4 10.58.134.34
t=0 0
m=audio 10632 RTP/AVP 0 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

<--- Received SIP response (419 bytes) from UDP:10.57.243.20:5060 --->
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 10.58.134.34:5060;rport=5060;branch=z9hG4bKPj9aadc1e6-d214-44d9-893e-57086c7a94a5;received=10.58.134.34
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=ad320ed3-2b60-4261-a641-19fec82b8227
To: <sip:28245@10.57.243.20>;tag=159122879
Call-ID: 230fa376-ea32-4942-bb2c-a8e112e44b3c
CSeq: 10923 INVITE
Server: OpenScape 4000 - HiPath 4000 SoftGate
Content-Length: 0


<--- Transmitting SIP request (396 bytes) to UDP:10.57.243.20:5060 --->
ACK sip:28245@10.57.243.20 SIP/2.0
Via: SIP/2.0/UDP 10.58.134.34:5060;rport;branch=z9hG4bKPj9aadc1e6-d214-44d9-893e-57086c7a94a5
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=ad320ed3-2b60-4261-a641-19fec82b8227
To: <sip:28245@10.57.243.20>;tag=159122879
Call-ID: 230fa376-ea32-4942-bb2c-a8e112e44b3c
CSeq: 10923 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 20.7.0
Content-Length:  0


  == Everyone is busy/congested at this time (1:0/0/1)
    -- Auto fallthrough, channel 'PJSIP/28555-00000006' status is 'CHANUNAVAIL'
<--- Transmitting SIP response (428 bytes) to UDP:10.57.143.88:5060 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.57.143.88:5060;rport=5060;received=10.57.143.88;branch=z9hG4bK0018b01e52e5ee11bb39950b6019a9ec
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>;tag=c8274029-4432-4462-9d6c-0d85bc4dc31a
CSeq: 2 INVITE
Server: Asterisk PBX 20.7.0
Reason: Q.850;cause=34
Content-Length:  0


<--- Received SIP request (642 bytes) from UDP:10.57.143.88:5060 --->
ACK sip:28245@10.58.134.34 SIP/2.0
Via: SIP/2.0/UDP 10.57.143.88:5060;branch=z9hG4bK0018b01e52e5ee11bb39950b6019a9ec;rport
From: "PhonerLite" <sip:28555@10.58.134.34>;tag=2107865067
To: <sip:28245@10.58.134.34>;tag=c8274029-4432-4462-9d6c-0d85bc4dc31a
Call-ID: 0018B01E-52E5-EE11-BB36-950B6019A9EC@10.57.143.88
CSeq: 2 ACK
Authorization: Digest username="28555", realm="asterisk", nonce="1710957936/0369c9daeef6e699b010ed392b931435", uri="sip:28245@10.58.134.34", response="1ec5287433973d4658a8019a1f688e59", algorithm=MD5, cnonce="0018b01e52e5ee11bb38950b6019a9ec", opaque="4d00ad68703fb809", qop=auth, nc=00000001
Content-Length: 0

Available

Endpoint: trunk1 Not in use 0 of inf
Aor: trunk1 0
Contact: trunk1/sip:10.57.243.20 c9531bc9b6 NonQual nan

Use preformatted text to correctly render logs.

You’ve got a 488 response which either means incompatible encryption settings or no compatible codecs. I don’t think encryption is an issue here. I suppose they might mishandle maxptime.

They are the same in PJSIP and SIP.

sip.conf
v=0
o=root 419145688 419145688 IN IP4 10.84.134.34
s=Asterisk PBX 20.7.0
c=IN IP4 10.84.134.34
t=0 0
m=audio 13762 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:140
a=sendrecv
pjsip.conf
v=0
o=- 610862184 610862184 IN IP4 10.84.134.34
s=Asterisk
c=IN IP4 10.84.134.34
t=0 0
m=audio 26844 RTP/AVP 0 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

ptime is the default, so they should not reject that, and whilst you are adding an extra codec, you include the one that they accepted before. They’re broken.

1 Like

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