Asterisk refuses INVITE (401) and I don’t know why

Home » Asterisk Users » Asterisk refuses INVITE (401) and I don’t know why
Asterisk Users 10 Comments

Jonas,

May I suggest that you present us your sip.conf entry for this peer, properly redacted, of course. That might help more. What I do for “gateways” at known addresses is to put an
entry like this into the sip.conf entry:

[peer]
type=peer
defaultip=192.168.40.123
insecure=invite,port
context=some_context

On 11/22/2011 06:40 AM, Jonas Kellens wrote:
> Hello list,
>
> this is the communication between an Aastra 5000 PBX and Asterisk, where the Aastra makes a call to Asterisk. For some reason, Asterisk responds with 401-Unauthorized and I don’t
> know why.
>
> Calls go well with Panasonic PBX, Avaya PBX, Alcatel-Lucent PBX but NOT with this Aastra.
>
>
> A1.A1.A1.A1 = IP-address Asterisk PBX
> AS.AS.AS.AS = IP-address Aastra PBX
>
> Aastra PBX makes a call to the number 3221112233…
>
> This is all the sip debug trace gathered with asterisk :
>
>
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> INVITE sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK15388160301891243008;rport
> From: ;tag=310158BD
> To:
> Call-ID: 0201FFFFCEFEA742
> CSeq: 1 INVITE
> Contact:
> Proxy-Authorization: Digest username=”SIPPEERusername”, realm=”domain.tld”, nonce=”67105ac4″, uri=”sip:3221112233@A1.A1.A1.A1:5060″, response=”60be856773
> f86450fc9ddbaf7a568505″, algorithm=MD5
> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE
> Max-Forwards: 70
> Privacy: none
> P-Asserted-Identity:
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Type: application/sdp
> Content-Length:195
>
> v=0
> o=- 0 0 IN IP4 sip.domain.tld
> s=-
> i=(o=IN IP4 10.1.2.35)
> c=IN IP4 AS.AS.AS.AS
> t=0 0
> m=audio 62654 RTP/AVP 8 0
> a=rtcp:65115
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=ptime:20
>
> < ------------->
>
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] — (16 headers 11 lines) —
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP TOS bits 184
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP CoS mark 5
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Sending to AS.AS.AS.AS : 61490 (no NAT)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Using INVITE request as basis request – 0201FFFFCEFEA742
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Found peer ‘SIPPEERusername’ for ‘SIPPEERusername’ from AS.AS.AS.AS:61490
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- Reliably Transmitting (NAT) to AS.AS.AS.AS:61490 --->
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK15388160301891243008;received=AS.AS.AS.AS;rport=61490
> From: ;tag=310158BD
> To: ;tag=as68f71fe5
> Call-ID: 0201FFFFCEFEA742
> CSeq: 1 INVITE
> Server: Asterisk PBX 1.6.2.20
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm=”domain.tld”, nonce=”46ef24d9″
> Content-Length: 0
>
> < ------------>
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Scheduling destruction of SIP dialog ‘0201FFFFCEFEA742’ in 32000 ms (Method: INVITE)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> ACK sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK15388160301891243008;rport
> From: ;tag=310158BD
> To: ;tag=as68f71fe5
> Call-ID: 0201FFFFCEFEA742
> CSeq: 1 ACK
> Contact:
> Max-Forwards: 70
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Length: 0
>
>
> < ------------->
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] — (11 headers 0 lines) —
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> INVITE sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK6996345481960200906;rport
> From:
;tag=33015DBD
> To:
> Call-ID: 0201FFFFCCFEA242
> CSeq: 1 INVITE
> Contact:
> Proxy-Authorization: Digest username=”SIPPEERusername”, realm=”domain.tld”, nonce=”46ef24d9″, uri=”sip:3221112233@A1.A1.A1.A1:5060″, response=”14ecbfc7df24b49926151284c123ea11″,
> algorithm=MD5
> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE
> Max-Forwards: 70
> Privacy: none
> P-Asserted-Identity:
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Type: application/sdp
> Content-Length:195
>
> v=0
> o=- 0 0 IN IP4 sip.domain.tld
> s=-
> i=(o=IN IP4 10.1.2.35)
> c=IN IP4 AS.AS.AS.AS
> t=0 0
> m=audio 62654 RTP/AVP 8 0
> a=rtcp:65115
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=ptime:20
>
>
> < ------------->
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] — (16 headers 11 lines) —
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP TOS bits 184
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP CoS mark 5
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Sending to AS.AS.AS.AS : 61490 (no NAT)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Using INVITE request as basis request – 0201FFFFCCFEA242
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Found peer ‘SIPPEERusername’ for ‘SIPPEERusername’ from AS.AS.AS.AS:61490
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- Reliably Transmitting (NAT) to AS.AS.AS.AS:61490 --->
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK6996345481960200906;received=AS.AS.AS.AS;rport=61490
> From: ;tag=33015DBD
> To: ;tag=as1ba6ed56
> Call-ID: 0201FFFFCCFEA242
> CSeq: 1 INVITE
> Server: Asterisk PBX 1.6.2.20
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm=”domain.tld”, nonce=”3df09f45″
> Content-Length: 0
>
>
> < ------------>
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Scheduling destruction of SIP dialog ‘0201FFFFCCFEA242’ in 32000 ms (Method: INVITE)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> ACK sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK6996345481960200906;rport
> From: ;tag=33015DBD
> To: ;tag=as1ba6ed56
> Call-ID: 0201FFFFCCFEA242
> CSeq: 1 ACK
> Contact:
> Max-Forwards: 70
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Length: 0
>
>
> < ------------->
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] — (11 headers 0 lines) —
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> INVITE sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK847851481531358325;rport
> From:
;tag=340163BD
> To:
> Call-ID: 0201FFFFCBFE9C42
> CSeq: 1 INVITE
> Contact:
> Proxy-Authorization: Digest username=”SIPPEERusername”, realm=”domain.tld”, nonce=”3df09f45″, uri=”sip:3221112233@A1.A1.A1.A1:5060″, response=”80683cd640815b362f74afcfcb68809a”,
> algorithm=MD5
> Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, UPDATE
> Max-Forwards: 70
> Privacy: none
> P-Asserted-Identity:
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Type: application/sdp
> Content-Length:195
>
> v=0
> o=- 0 0 IN IP4 sip.domain.tld
> s=-
> i=(o=IN IP4 10.1.2.35)
> c=IN IP4 AS.AS.AS.AS
> t=0 0
> m=audio 62654 RTP/AVP 8 0
> a=rtcp:65115
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=ptime:20
>
>
> < ------------->
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] — (16 headers 11 lines) —
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP TOS bits 184
> [Nov 18 15:14:35] VERBOSE[2255] netsock.c: [Nov 18 15:14:35] == Using SIP RTP CoS mark 5
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Sending to AS.AS.AS.AS : 61490 (no NAT)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Using INVITE request as basis request – 0201FFFFCBFE9C42
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Found peer ‘SIPPEERusername’ for ‘SIPPEERusername’ from AS.AS.AS.AS:61490
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- Reliably Transmitting (NAT) to AS.AS.AS.AS:61490 --->
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK847851481531358325;received=AS.AS.AS.AS;rport=61490
> From: ;tag=340163BD
> To: ;tag=as26c6d395
> Call-ID: 0201FFFFCBFE9C42
> CSeq: 1 INVITE
> Server: Asterisk PBX 1.6.2.20
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm=”domain.tld”, nonce=”6a7cfd54″
> Content-Length: 0
>
>
> < ------------>
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35] Scheduling destruction of SIP dialog ‘0201FFFFCBFE9C42’ in 32000 ms (Method: INVITE)
> [Nov 18 15:14:35] VERBOSE[2255] chan_sip.c: [Nov 18 15:14:35]
> < --- SIP read from UDP:AS.AS.AS.AS:61490 --->
> ACK sip:3221112233@A1.A1.A1.A1:5060 SIP/2.0
> Via: SIP/2.0/UDP AS.AS.AS.AS:61490;branch=z9hG4bK847851481531358325;rport
> From: ;tag=340163BD
> To: ;tag=as26c6d395
> Call-ID: 0201FFFFCBFE9C42
> CSeq: 1 ACK
> Contact:
> Max-Forwards: 70
> User-Agent: A5000 R52-H2C0205
> P-Behind-Gsi: 192.168.6.1
> Content-Length: 0
>
>
>
> Thanks.
>
> Kind regards,
> Jonas.
>
>
> —
> _____________________________________________________________________
> — Bandwidth and Colocation Provided by http://www.api-digital.com
> New to Asterisk? Join us for a live introductory webinar every Thurs:
> http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users

10 thoughts on - Asterisk refuses INVITE (401) and I don’t know why

  • This is the peer definition in sip.conf :

    [SIPPEERusername]
    type=friend
    host=dynamic
    defaultuser=SIPPEERusername
    secret=guessthis
    context=from-PEERTRUNK
    nat=yes
    dtmfmode=rfc2833
    canreinvite=no
    disallow=all
    allow=alaw
    allow=gsm

    Hope you can help me out with this extra information.

  • do you see the register messages? if your device is not registered, INVITE would be challenged. You should check to see if register messages are being properly acknowledge with 200OK.

  • From what I see in your entry, you are requiring registration from the peer. The next thing i would check is to see if the registration has succeeded. If it doesn’t succeed, you
    will see the results you presented. I see you have the peer set as a dynamic host, and if the IP address of the device does in fact change then registration is appropriate.

  • Registration of the SIP PEER is no problem. The PEER registers with a
    correct REGISTER statement and Asterisk sends a 200 OK.

    So the PEER is registered and then wants to make a call (INVITE) but for
    some reason this INVITE is being refused with 401-Unauthorized.

    The first 401-Unauthorized is normal, because the SIP PEER needs to send
    a second INVITE with a challenge (nonce). But after this INVITE with
    challenge, Asterisk still sends a 401 and that’s strange !!

    Jonas.

  • Your registration should have also have the flow

    PEER ASTERISK
    REGISTER——->
    < ----------------------401
    REGISTER(nonce) ->
    < ------------------------200OK Then the server controls the life of the registration and 200 Expires Header gives you this timeout. If the invite is sent within that window, then Asterisk should not challenge anymore. If Invite is challenged and the peer responds with the correctly calculated NONCE, domain and other Auth params, then something is wrong with your Authentication. I suggest trapping the traffic with Ethereal or any other packet capture programs and examining that carefully from the start of the session (i.e. register) to the invite. I would also check where the 401 is coming from (i.e. IP address). Hope that helps Alex

  • I’ve already captured with Wireshark, but what to do with it if I don’t
    know what I’m looking for ??

    Registration goes without problem, but every INVITE is answered with a
    401-Unauthorized.

    Like I already said : there is no problem with Avaya, Panasonic and
    Alcatel-Lucent.
    The only difference I see between an INVITE from Avaya and the INVITE
    from Aastra PBX is the presence of the SIP-header : “P-Behind-Gsi:
    192.168.6.1″.

    Could this header mess up Asterisk ?

    Jonas.

  • What trace do you need ? Have you read my original post ? Asterisk SIP
    debug trace is posted in my original post.

  • This is a trace taken when an Alcatel-Lucent PBX sends an INVITE (no
    refusal by Asterisk). Do you see any difference ?

    A1.A1.A1.A1 = IP-address Asterisk PBX
    AL.AL.AL.AL = IP-address Alcatel-Lucent PBX

    < --- SIP read from UDP:AL.AL.AL.AL:5060 --->
    INVITE sip:311083335533@A1.A1.A1.A1;user=phone SIP/2.0
    Allow: INVITE, ACK, CANCEL, BYE, PRACK, NOTIFY, SUBSCRIBE, OPTIONS, UPDATE
    Supported: replaces, timer, 100rel
    User-Agent: OmniPCX Enterprise R9.1 i1.605.21
    Session-Expires: 1800;refresher=uac
    Min-SE: 900
    P-Asserted-Identity: “Dan Luc”
    ;tag=37a49f0486bab42b240be214b2d13153
    Contact:

    Call-ID: 2fae0b0266919172cac1e23dc2567cd2@192.168.8.10
    CSeq: 443337258 INVITE
    Via: SIP/2.0/UDP
    AL.AL.AL.AL:5060;branch=z9hG4bK5dee58e3294e4b7f9fe34c65af7b4cae
    Max-Forwards: 70
    Content-Type: application/sdp
    Content-Length: 292

    v=0
    o=OXE 1322045354 1322045354 IN IP4 AL.AL.AL.AL
    s=abs
    c=IN IP4 AL.AL.AL.AL
    t=0 0
    m=audio 34422 RTP/AVP 8 18 97
    a=sendrecv
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=maxptime:30
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=ptime:20
    a=maxptime:40
    a=rtpmap:97 telephone-event/8000

    < --- Reliably Transmitting (NAT) to AL.AL.AL.AL:5060 --->
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP
    AL.AL.AL.AL:5060;branch=z9hG4bK5dee58e3294e4b7f9fe34c65af7b4cae;received=AL.AL.AL.AL
    ;tag=37a49f0486bab42b240be214b2d13153
    Call-ID: 2fae0b0266919172cac1e23dc2567cd2@192.168.8.10
    CSeq: 443337258 INVITE
    Server: Asterisk PBX 1.6.2.20
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
    Supported: replaces, timer
    WWW-Authenticate: Digest algorithm=MD5, realm=”domain.tld”, nonce=”7684ab1d”
    Content-Length: 0

    < --- SIP read from UDP:AL.AL.AL.AL:5060 --->
    INVITE sip:311083335533@A1.A1.A1.A1;user=phone SIP/2.0
    Allow: INVITE, ACK, CANCEL, BYE, PRACK, NOTIFY, SUBSCRIBE, OPTIONS, UPDATE
    Supported: replaces, timer, 100rel
    User-Agent: OmniPCX Enterprise R9.1 i1.605.21
    Session-Expires: 1800;refresher=uac
    Min-SE: 900
    P-Asserted-Identity: “Dan Luc”
    ;tag=37a49f0486bab42b240be214b2d13153
    Contact:

    Call-ID: 2fae0b0266919172cac1e23dc2567cd2@192.168.8.10
    CSeq: 443337259 INVITE
    Max-Forwards: 70
    Authorization: Digest
    username=”SIPPEERusername”,realm=”domain.tld”,nonce=”7684ab1d”,algorithm=MD5,uri=”sip:311083335533@A1.A1.A1.A1;user=phone”,response=”38bb824b9081bf2eefe9f9677d3eb005″
    Via: SIP/2.0/UDP
    AL.AL.AL.AL:5060;branch=z9hG4bK52dae2e7816406e20a9c02aa9cb86726
    Content-Type: application/sdp
    Content-Length: 292

    v=0
    o=OXE 1322045354 1322045354 IN IP4 AL.AL.AL.AL
    s=abs
    c=IN IP4 AL.AL.AL.AL
    t=0 0
    m=audio 34422 RTP/AVP 8 18 97
    a=sendrecv
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=maxptime:30
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=ptime:20
    a=maxptime:40
    a=rtpmap:97 telephone-event/8000

    < --- Transmitting (NAT) to AL.AL.AL.AL:5060 --->
    SIP/2.0 100 Trying
    Via: SIP/2.0/UDP
    AL.AL.AL.AL:5060;branch=z9hG4bK52dae2e7816406e20a9c02aa9cb86726;received=AL.AL.AL.AL
    ;tag=37a49f0486bab42b240be214b2d13153
    Call-ID: 2fae0b0266919172cac1e23dc2567cd2@192.168.8.10
    CSeq: 443337259 INVITE
    Server: Asterisk PBX 1.6.2.20
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
    Supported: replaces, timer
    Session-Expires: 1800;refresher=uac
    Contact:
    Content-Length: 0

    Thanks !

    Jonas.

  • just a quick observation, but not sure that it is critical

    in this case, the first invite comes without Authorization header, then gets challenged then resends the invite (with increased cseq) with calculated response based on the challenge from the server.

    In your AAstra case, the first invite already contained Authorization header (which is really impossible because you don’t have all the pieces to calculate the response). Normally not an issue, as UAS should challenge it, but I wonder why it does it anyway. I would compare Authorize elements between 2 cases particularly response, uri and authorization user name. if response is the same between the two, I am lost.