[asterisk-users] Sip incoming call issue with Asterisk 1.6

[Leif Madsen]

Eric van der Vlist wrote:
> After a migration to asterisk 1.6, I don't receive sip incoming calls
> anymore.
> 
> As fas as I understand the SIP debug traces, my server receives the
> request and reject it:
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> <--- SIP read from UDP:212.27.52.5:5060 --->
> INVITE sip:s at 192.168.4.2:5060;transport=udp SIP/2.0
> Call-ID: 25151-WW-0eaf098b-2f615ac60 at freephonie.net
> Contact: <sip:172.17.20.241:5062>
> Content-Type: application/sdp
> CSeq: 239836027 INVITE
> From: "096160XXXX" <sip:096160XXXX at freephonie.net;user=phone>;tag=25151-GA-0eaf098c-32a97dc05
> Max-Forwards: 28
> Record-Route: <sip:C=on-88.165.134.117.5060;t=RDKIW at 212.27.52.5:5060;lr>
> To: <sip:095199YYYY at 172.17.20.241;user=phone>
> Via: SIP/2.0/UDP 212.27.52.5:5060;branch=z9hG4bK-RDKI-00720204-55801b4f
> Allow: UPDATE,REFER,INFO
> User-Agent: Cirpack/v4.41c (gw_sip)
> Content-Length: 173
> 
> v=0
> o=cp10 125830752022 125830752022 IN IP4 212.27.52.129
> s=SIP Call
> c=IN IP4 212.27.52.129
> t=0 0
> m=audio 36480 RTP/AVP 8
> b=AS:64
> a=rtpmap:8 PCMA/8000/1
> a=ptime:30
> 
> <------------->
> --- (13 headers 9 lines) ---
>   == Using SIP RTP CoS mark 5
> Sending to 212.27.52.5 : 5060 (no NAT)
> Using INVITE request as basis request - 25151-WW-0eaf098b-2f615ac60 at freephonie.net
> Found peer 'freephonie_appelsortant' for '096160XXXX' from 212.27.52.5:5060
> asterisk*CLI> 
> <--- Reliably Transmitting (no NAT) to 212.27.52.5:5060 --->
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP 212.27.52.5:5060;branch=z9hG4bK-RDKI-00720204-55801b4f;received=212.27.52.5
> From: "096160XXXX" <sip:096160XXXX at freephonie.net;user=phone>;tag=25151-GA-0eaf098c-32a97dc05
> To: <sip:095199YYYY at 172.17.20.241;user=phone>;tag=as03dcbe68
> Call-ID: 25151-WW-0eaf098b-2f615ac60 at freephonie.net
> CSeq: 239836027 INVITE
> Server: Asterisk PBX 1.6.2.0~rc2-0ubuntu1
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces, timer
> WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="78360854"
> Content-Length: 0
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

I'm not sure you've provided enough of the trace here. It finds the peer, but 
rejects it with a 401 Unauthorized, which is not uncommon. And I don't see any 
authentication information in the first INVITE. This is why the 401 is sent 
back, as the WWW-Authenticate line contains the realm and nonce which should be 
used by the other end to generate the authentication, and then send another 
INVITE back with authentication.

Since you've only shown the two packets in the trace, it is impossible to tell 
what is going on beyond the 401 response from Asterisk.

Leif.