Possible bug or configuration error after changing to PJSIP

Asterisk Asterisk SIP
1

Hello,
After a lot of messing around with my configuration, I managed to get the PJSIP implementation running on Asterisk 18.9.0. It seems to work fine for most users, but one of our old Cisco IADs doesn’t like the new environment for some reason.

Looking through the SIP traffic, it seems like Asterisk thinks that the 183 Session Progress message means that the line is busy:

    -- Executing [208@dittnamn:2] Dial("PJSIP/144-0000000e", "PJSIP/208,240,gtwW") in new stack
    -- Called PJSIP/208
<--- Transmitting SIP request (766 bytes) to UDP:192.168.24.3:5060 --->
INVITE sip:9208@192.168.24.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.24.17:6060;rport;branch=z9hG4bKPj75247803-71a0-4923-8017-d6889ca8e767
From: "Mobil" <sip:144@192.168.24.17>;tag=aadfae36-b18a-45fa-b2c1-320874bf7bbb
To: <sip:9208@192.168.24.3>
Contact: <sip:asterisk@192.168.24.17:6060>
Call-ID: f1dd2f01-853e-4d92-b1c5-98f78294abe9
CSeq: 29144 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk SIP Server
Content-Type: application/sdp
Content-Length:    96

v=0
o=- 1933327125 1933327125 IN IP4 192.168.24.17
s=Asterisk
c=IN IP4 192.168.24.17
t=0 0

<--- Received SIP response (440 bytes) from UDP:192.168.24.3:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.24.17:6060;rport;branch=z9hG4bKPj75247803-71a0-4923-8017-d6889ca8e767
From: "Mobil" <sip:144@192.168.24.17>;tag=aadfae36-b18a-45fa-b2c1-320874bf7bbb
To: <sip:9208@192.168.24.3>;tag=C5515C98-1327
Date: Thu, 08 Apr 1993 07:35:31 GMT
Call-ID: f1dd2f01-853e-4d92-b1c5-98f78294abe9
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 29144 INVITE
Allow-Events: telephone-event
Content-Length: 0


<--- Received SIP response (813 bytes) from UDP:192.168.24.3:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.24.17:6060;rport;branch=z9hG4bKPj75247803-71a0-4923-8017-d6889ca8e767
From: "Mobil" <sip:144@192.168.24.17>;tag=aadfae36-b18a-45fa-b2c1-320874bf7bbb
To: <sip:9208@192.168.24.3>;tag=C5515C98-1327
Date: Thu, 08 Apr 1993 07:35:31 GMT
Call-ID: f1dd2f01-853e-4d92-b1c5-98f78294abe9
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 29144 INVITE
Require: 100rel
RSeq: 8187
Allow-Events: telephone-event
Contact: <sip:9208@192.168.24.3:5060>
Content-Disposition: session;handling=required
Content-Type: application/sdp
Content-Length: 214

v=0
o=CiscoSystemsSIP-GW-UserAgent 350 1671 IN IP4 192.168.24.3
s=SIP Call
c=IN IP4 192.168.24.3
t=0 0
m=audio 17640 RTP/AVP 8 19
c=IN IP4 192.168.24.3
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
a=ptime:20

  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [208@dittnamn:3] Hangup("PJSIP/144-0000000e", "") in new stack

<--- Transmitting SIP request (434 bytes) to UDP:192.168.24.3:5060 --->
PRACK sip:9208@192.168.24.3:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.24.17:6060;rport;branch=z9hG4bKPj3b461c2d-a736-4a8a-bf39-b07d35e23026
From: "Mobil" <sip:144@192.168.24.17>;tag=aadfae36-b18a-45fa-b2c1-320874bf7bbb
To: <sip:9208@192.168.24.3>;tag=C5515C98-1327
Call-ID: f1dd2f01-853e-4d92-b1c5-98f78294abe9
CSeq: 29145 PRACK
RAck: 8187 29144 INVITE
Max-Forwards: 70
User-Agent: Asterisk SIP Server
Content-Length:  0


  == Spawn extension (dittnamn, 208, 3) exited non-zero on 'PJSIP/144-0000000e'

Have I missed something or is this a bug? This is the relevant part of the configuration:

[144]
type = aor
max_contacts = 1

[144]
type = auth
username = 144
password = ******

[144]
type = endpoint
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
context = dittnamn
callerid = "Mobil" <144>
auth = 144
aors = 144
t38_udptl = yes
t38_udptl_ec = none
disallow = all
allow = alaw
allow = ulaw
allow = g729


[...]

[208]
type = aor
contact = sip:9208@192.168.24.3

[208]
type = identify
endpoint = 208
match = 192.168.24.3

[208]
type = endpoint
context = localnumbers
callerid = "Kontor" <208>
aors = 208
2

It is actually saying unavailable, not busy.

Something has gone wrong before the INVITE, as Asterisk hasn’t offered any media streams. I’m surprised it even issued the INVITE.

I think we definitely need to see what (e.g. dialplan) led up to the INVITE, and probably need debugging turned on.

3

I think your problem is that you haven’t specified a disallow. That tries to send an excessively long SDP, and in some versions, causes the SDP generation to collapse because the default list includes some codecs that aren’t real codecs.

I assume that current versions fix the second part, but you still need to disallow and then selectively allow to produce an INVITE of a sensible size.

1 Like
4

You need to actually configure 208 with explicit codecs.

1 Like
5

Great, thanks to both of you. I had missed that on a few of the endpoints. What’s interesting is that I had missed it on a few endpoints that seems to have worked without it, so it was probably the package length that caused it.

Now, I realized that we’ve had these old IADs locked down through ACLs and PJSIP has moved the ACLs to a global list instead of per peer. Is there any other way of restricting access without passwords?

6

ACLs are global or per-endpoint[1].

[1] Asterisk 18 Configuration_res_pjsip - Asterisk Project - Asterisk Project Wiki

1 Like
7

Thank you! I will try that. When I read the other pages in the documentation I assumed it implied it was only a global setting.

8

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