SIP only accepts register after second or third try

Hi,

I noticed that in my asterisk console, the sip registration is only accepted after the second register attempt.

Why isn’t the attempt accepted the first time?

This is a problem because one of my sip devices only makes one attempt at a registration.

Thanks,

David

SIP.conf[code]
[david-cell]
username=david-cell
type=friend
secret=1234567
record_out=Always
record_in=Always
qualify=100
port=5060
nat=no
mailbox=14185551212
host=dynamic
dtmfmode=rfc2833
context=david_lublink
canreinvite=no
callerid=David Cell <1008>
regcontext=david_lublink_reg
regexten=1008
accountcode=david_lublink

cantransfer = yes
canreinvite = no
transfer = yes
trustrpid = yes
threewaycalling = yes

allow=GSM
allow=speex
allow = ulaw
allow = g729
allow = h263
allow = h263p
allow = all
[/code]

Here is the console for the device that only tries to register once before it fails:

Aug  8 17:31:07 DEBUG[10572]: chan_sip.c:1334 __sip_autodestruct: Auto destroying call 'e7ad20a7-5faab93f@192.168.1.100'
Destroying call 'e7ad20a7-5faab93f@192.168.1.100'
vserver-lublink*CLI> 
<-- SIP read from 70.82.177.77:5060: 
REGISTER sip:sip.mydomain.tld;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 70.82.177.77:5060;branch=z9hG4bK6a8ad610fa879f44cd4fdf7aca37c1e8
Via: SIP/2.0/UDP 192.168.178.113:5060;branch=z9hG4bKcar9gdqna5hc63iq0j00vmk;rport
From: <sip:david-cell@sip.mydomain.tld>;tag=3uppgdv34thc6b0p0j00
To: <sip:david-cell@sip.mydomain.tld>
Call-ID: nM6odTE0oIcfn0j03MQuXBlZQRAoNs
CSeq: 1564 REGISTER
Contact: <sip:david-cell@70.82.177.77>;expires=3600
Security-client: tls
Security-client: digest
Require: sec-agree
Proxy-require: sec-agree
Supported: sec-agree
User-agent: Nokia RM-227 1.0633.22.05
Max-forwards: 69
Content-Length: 0


Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 0: REGISTER sip:sip.mydomain.tld;transport=UDP SIP/2.0 (50)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 1: Via: SIP/2.0/UDP 70.82.177.77:5060;branch=z9hG4bK6a8ad610fa879f44cd4fdf7aca37c1e8 (81)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 2: Via: SIP/2.0/UDP 192.168.178.113:5060;branch=z9hG4bKcar9gdqna5hc63iq0j00vmk;rport (81)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 3: From: <sip:david-cell@sip.mydomain.tld>;tag=3uppgdv34thc6b0p0j00 (63)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 4: To: <sip:david-cell@sip.mydomain.tld> (36)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 5: Call-ID: nM6odTE0oIcfn0j03MQuXBlZQRAoNs (39)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 6: CSeq: 1564 REGISTER (19)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 7: Contact: <sip:david-cell@70.82.177.77>;expires=3600 (51)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 8: Security-client: tls (20)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 9: Security-client: digest (23)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 10: Require: sec-agree (18)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 11: Proxy-require: sec-agree (24)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 12: Supported: sec-agree (20)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 13: User-agent: Nokia RM-227 1.0633.22.05 (37)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 14: Max-forwards: 69 (16)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 15: Content-Length: 0 (17)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3392 parse_request: Header 16:  (0)
--- (16 headers 0 lines) ---
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3216 find_call: = No match Their Call ID: 1d79c252f2525489@192.168.178.76 Their Tag 7470356c0dd5386f Our tag: as54e094b8
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3216 find_call: = No match Their Call ID: 4a0e9afe9da226e3@192.168.178.76 Their Tag f1fec8b739b739fe Our tag: as5212f97a
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:3168 sip_alloc: Allocating new SIP dialog for nM6odTE0oIcfn0j03MQuXBlZQRAoNs - REGISTER (No RTP)
Aug  8 17:31:10 DEBUG[10572]: chan_sip.c:11225 handle_request: **** Received REGISTER (2) - Command in SIP REGISTER
Using latest REGISTER request as basis request
Sending to 70.82.177.77 : 5060 (non-NAT)
Transmitting (NAT) to 70.82.177.77:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 70.82.177.77:5060;branch=z9hG4bK6a8ad610fa879f44cd4fdf7aca37c1e8;received=70.82.177.77
Via: SIP/2.0/UDP 192.168.178.113:5060;branch=z9hG4bKcar9gdqna5hc63iq0j00vmk;rport
From: <sip:david-cell@sip.mydomain.tld>;tag=3uppgdv34thc6b0p0j00
To: <sip:david-cell@sip.mydomain.tld>
Call-ID: nM6odTE0oIcfn0j03MQuXBlZQRAoNs
CSeq: 1564 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:david-cell@72.55.141.253>
Content-Length: 0


---
Transmitting (NAT) to 70.82.177.77:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 70.82.177.77:5060;branch=z9hG4bK6a8ad610fa879f44cd4fdf7aca37c1e8;received=70.82.177.77
Via: SIP/2.0/UDP 192.168.178.113:5060;branch=z9hG4bKcar9gdqna5hc63iq0j00vmk;rport
From: <sip:david-cell@sip.mydomain.tld>;tag=3uppgdv34thc6b0p0j00
To: <sip:david-cell@sip.mydomain.tld>;tag=as471fe5dd
Call-ID: nM6odTE0oIcfn0j03MQuXBlZQRAoNs
CSeq: 1564 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="73f18d31"
Content-Length: 0


---
Scheduling destruction of call 'nM6odTE0oIcfn0j03MQuXBlZQRAoNs' in 15000 ms
vserver-lublink*CLI> 
<-- SIP read from 24.203.243.32:52760: 

--- (0 headers 0 lines) Nat keepalive ---
vserver-lublink*CLI> 
<-- SIP read from 24.203.243.32:61000: 

--- (0 headers 0 lines) Nat keepalive ---
vserver-lublink*CLI> 

It does not say why the forbidden was sent.

your asterisk is trying to register with digest authentication and the SIP device is set only to basic. see if the SIP device will support digest authentication.

with digest authentication the sip device first attempt is always returned as a 401 error, in that errata the digest MD5 info issent back to the device, the second attempt is made and will be successful since the digest info is sent across.

-Christopher