Asterisk ARI - Calls not in Stasis App - Auth vs NonAuth

To the people smarter than I am with Asterisk (basically almost all),

Using Asterisk 18.12.1 with PJSIP, ARI, and Stasis. All my extensions/endpoints are dynamically created via ARI. All communication setup and “initiation” is done by my stasis application. (My extensions.conf is literally empty)

The one set of endpoints (the vehicles) do not have any auth Authentication Objects assigned. The other endpoints (the dispatchers) have auth Authentication Objects assigned. All endpoints register successfully once their information have been set via Stasis (aor, auth, and endpoint) have been done via ARI.

For some kind of mysterious reason, which I cannot yet track down, calls from the vehicles are placed within the stasis application, but the calls from the dispatchers are not. When I remove the auth component from the dispatchers, then the calls gets placed in the stasis application … I have tried two different SIP clients (Linphone and Microsip) for the dispatchers, and both behave the same. When I register the dispatcher endpoints I commented out the following portion (so that the calls gets placed in stasis):

var dispatcherEndpointObject = {
    configClass : "res_pjsip",
    objectType : "endpoint",
    id : tempDispatcherName,
    fields : [
        { "attribute" : "from_user", "value": tempDispatcherName },
        { "attribute" : "disallow", "value" : "all"},
        { "attribute" : "allow", "value": ariRegistrationCodecs }, 
        { "attribute" : "rewrite_contact", "value": "yes" }, 
        { "attribute" : "context", "value": ariRegistrationExtensionContext },
        { "attribute" : "transport", "value": ariRegistrationNetworkContextUDP },
        { "attribute" : "callerid", "value": '"TALK_STANDARD" <'+tempDispatcherName+'>'},
        //{ "attribute" : "auth", "value": tempDispatcherName },
        //{ "attribute" : "trust_id_inbound", "value": "yes" }, 
        { "attribute" : "aors", "value": tempDispatcherName }
    ]
}

Somewhere I am missing something that don’t allow endpoints that have an auth object assigned to be placed within the stasis app.
Can someone maybe point me in the right direction and/or clarify what I have done wrong please?

Best regards,

Dawie

You’d need to provide actual console output of what is going on, including the SIP interaction (pjsip set logger on).

Some details when the auth object is set.

pjsip show endpoints:

 Endpoint:  SIM9003/SIM9003                                      Not in use    0 of inf
        Aor:  SIM9003                                            1
      Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060     80fc4ac305 NonQual         nan
      Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060     80fc4ac305 NonQual         nan
  Transport:  transport-udp             udp      0      0  0.0.0.0:5060

 Endpoint:  dispatcher-1/dispatcher1                             Not in use    0 of inf
     InAuth:  dispatcher-1/dispatcher-1
        Aor:  dispatcher-1                                       1
      Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.5 d0a25f84a9 NonQual         nan
      Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.5 d0a25f84a9 NonQual         nan
  Transport:  transport-udp             udp      0      0  0.0.0.0:5060

pjsip show contacts:

  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

  Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060         80fc4ac305 NonQual         nan
  Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.51:50 d0a25f84a9 NonQual         nan

pjsip set logger on (call initiated):

PJSIP Logging enabled
<--- Received SIP request (1224 bytes) from UDP:192.168.88.51:5060 --->
INVITE sip:SIM9003@192.168.88.244 SIP/2.0
Via: SIP/2.0/UDP 192.168.88.51:5060;branch=z9hG4bK.Enu4K-IS4;rport
From: <sip:dispatcher-1@192.168.88.244>;tag=zXA1eRbrO
To: sip:SIM9003@192.168.88.244
CSeq: 20 INVITE
Call-ID: UeW77wdMI0
Max-Forwards: 70
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 528
Contact: <sip:dispatcher-1@192.168.88.51;transport=udp>;expires=3599;+sip.instance="<urn:uuid:a9de70d9-f89b-006d-b1eb-f477e6e9027d>"
User-Agent: Linphone Desktop/4.4.1 (Dawie-Laptop) Windows 10 Version 2009, Qt 5.15.2 LinphoneCore/5.1.19-1-g6cdd0918e

v=0
o=dispatcher-1 1889 4052 IN IP4 192.168.88.51
s=Talk
c=IN IP4 192.168.88.51
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 7078 RTP/AVP 96 97 98 0 8 18 99 100 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 speex/16000
a=fmtp:97 vbr=on
a=rtpmap:98 speex/8000
a=fmtp:98 vbr=on
a=fmtp:18 annexb=yes
a=rtpmap:99 telephone-event/48000
a=rtpmap:100 telephone-event/16000
a=rtpmap:101 telephone-event/8000
a=rtcp-fb:* trr-int 1000
a=rtcp-fb:* ccm tmmbr

<--- Transmitting SIP response (469 bytes) to UDP:192.168.88.51:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.88.51:5060;rport=5060;received=192.168.88.51;branch=z9hG4bK.Enu4K-IS4
Call-ID: UeW77wdMI0
From: <sip:dispatcher-1@192.168.88.244>;tag=zXA1eRbrO
To: <sip:SIM9003@192.168.88.244>;tag=z9hG4bK.Enu4K-IS4
CSeq: 20 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1653248550/6f52b40ca658ed8f2fdf975bb19a5b32",opaque="3ff169463ffcea1e",algorithm=MD5,qop="auth"
Server: Asterisk PBX 18.12.1
Content-Length:  0


<--- Received SIP request (408 bytes) from UDP:192.168.88.51:5060 --->
ACK sip:SIM9003@192.168.88.244 SIP/2.0
Via: SIP/2.0/UDP 192.168.88.51:5060;branch=z9hG4bK.Enu4K-IS4;rport
Call-ID: UeW77wdMI0
From: <sip:dispatcher-1@192.168.88.244>;tag=zXA1eRbrO
To: <sip:SIM9003@192.168.88.244>;tag=z9hG4bK.Enu4K-IS4
Contact: <sip:dispatcher-1@192.168.88.51;transport=udp>;expires=3599;+sip.instance="<urn:uuid:a9de70d9-f89b-006d-b1eb-f477e6e9027d>"
Max-Forwards: 70
CSeq: 20 ACK

Asterisk is challenging the calling endpoint. It is then up to the calling endpoint to send an INVITE with credentials. The calling endpoint didn’t seem to do that. That’s all I can say from the perspective of Asterisk.

Somedetails if the auth object is not set.

pjsip show endpoints:

 Endpoint:  SIM9003/SIM9003                                      Not in use    0 of inf
        Aor:  SIM9003                                            1
      Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060     80fc4ac305 NonQual         nan
      Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060     80fc4ac305 NonQual         nan
  Transport:  transport-udp             udp      0      0  0.0.0.0:5060

 Endpoint:  dispatcher-1/dispatcher1                             Not in use    0 of inf
        Aor:  dispatcher-1                                       1
      Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.5 d0a25f84a9 NonQual         nan
      Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.5 d0a25f84a9 NonQual         nan
  Transport:  transport-udp             udp      0      0  0.0.0.0:5060

pjsip show contacts:

  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

  Contact:  SIM9003/sip:SIM9003@192.168.88.10:5060         80fc4ac305 NonQual         nan
  Contact:  dispatcher-1/sip:dispatcher-1@192.168.88.51:50 d0a25f84a9 NonQual         nan

Objects found: 2

pjsip set logger on (call initiated):

PJSIP Logging enabled
<--- Received SIP request (1223 bytes) from UDP:192.168.88.51:5060 --->
INVITE sip:SIM9003@192.168.88.244 SIP/2.0
Via: SIP/2.0/UDP 192.168.88.51:5060;branch=z9hG4bK.V19I4B0CQ;rport
From: <sip:dispatcher-1@192.168.88.244>;tag=ClQYroFF8
To: sip:SIM9003@192.168.88.244
CSeq: 20 INVITE
Call-ID: ~c4Y8lCPsi
Max-Forwards: 70
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Content-Type: application/sdp
Content-Length: 527
Contact: <sip:dispatcher-1@192.168.88.51;transport=udp>;expires=3599;+sip.instance="<urn:uuid:a9de70d9-f89b-006d-b1eb-f477e6e9027d>"
User-Agent: Linphone Desktop/4.4.1 (Dawie-Laptop) Windows 10 Version 2009, Qt 5.15.2 LinphoneCore/5.1.19-1-g6cdd0918e

v=0
o=dispatcher-1 409 2778 IN IP4 192.168.88.51
s=Talk
c=IN IP4 192.168.88.51
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 7078 RTP/AVP 96 97 98 0 8 18 99 100 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 speex/16000
a=fmtp:97 vbr=on
a=rtpmap:98 speex/8000
a=fmtp:98 vbr=on
a=fmtp:18 annexb=yes
a=rtpmap:99 telephone-event/48000
a=rtpmap:100 telephone-event/16000
a=rtpmap:101 telephone-event/8000
a=rtcp-fb:* trr-int 1000
a=rtcp-fb:* ccm tmmbr

<--- Transmitting SIP response (295 bytes) to UDP:192.168.88.51:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.88.51:5060;rport=5060;received=192.168.88.51;branch=z9hG4bK.V19I4B0CQ
Call-ID: ~c4Y8lCPsi
From: <sip:dispatcher-1@192.168.88.244>;tag=ClQYroFF8
To: <sip:SIM9003@192.168.88.244>
CSeq: 20 INVITE
Server: Asterisk PBX 18.12.1
Content-Length:  0


    -- Executing [SIM9003@stasis-LIOGateway:1] Stasis("PJSIP/dispatcher-1-00000001", "LIOGateway") in new stack

Urgh … ok … so maybe I didn’t configure the clients correctly … thanks …

But really … two different SIP clients can’t do it … ???

I can’t speak as to any specific configuration on either of those, having never touched or used them. I do know people use them and seems to work from them.

Fundamentally, though, what I said before stands. It’s up to the endpoint to send a second INVITE with authentication credentials. In the trace you provided, there was no second INVITE - unless you left it out.

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