[Home]

Summary:ASTERISK-03830: Incomplete information in SIP Contact header
Reporter:babledsoe (babledsoe)Labels:
Date Opened:2005-04-01 01:03:10.000-0600Date Closed:2011-06-07 14:10:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When generating SIP messages, Asterisk creates an incomplete "Contact" header. Seems to break Caller ID on my D-Link ATA. An INVITE sent to the ATA from * dumps a caller id string to the ATA's console with the right number but a name with a length of 0. The Contact header in this case is as such:

Contact: <sip:401@192.168.1.6>

An INVITE to * from the ATA shows the following Contact:

Contact: 202 <sip:202@192.168.1.80:5061>

(Name and number of the extention are 202)
It would seem that rather than getting CID Name information from the "From" header the D-Link gets information from the Contact header and barfs when it is incomplete. Prepending the current information in the Contact header with the name of the calling extention making it like the From header should, presumably, fix this.
Comments:By: Brian West (bkw918) 2005-04-01 01:27:13.000-0600

Can you please attach a full sip debug.

Thanks,
/b
By: Brian West (bkw918) 2005-04-01 01:36:53.000-0600

Actually I think your d-link is what is broken.  

The contact headers on mine work fine with my cisco.  

From my 7960 to Asterisk:
INVITE sip:999@x.x.x.x SIP/2.0
Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK4fad64b5
From: "HOME-10" <sip:10@x.x.x.x>;tag=000dbcd92c3866f36f661b4a-730397f1
To: <sip:999@x.x.x.x>
Call-ID: 000dbcd9-2c3800d6-5a94b782-65fd1f8b@65.38.28.157
CSeq: 102 INVITE
User-Agent: CSCO/7
Contact: <sip:10@y.y.y.y:5060>
Proxy-Authorization: Digest username="10",realm="bkw.org",uri="sip:x.x.x.x",response="4e6abf10csdfcd4f7b8cc181fb3334b2",nonce="21098838",algorithm=md5
Expires: 180
Content-Type: application/sdp
Content-Length: 245

Please read section 20.10 of rfc3261
By: Brian West (bkw918) 2005-04-01 01:39:00.000-0600

the m: header being the compact for of the contact header in the example in 20.10 of the rfc so it seems asterisk is not at fault here.

     m: <sips:bob@192.0.2.4>;expires=60
By: Brian West (bkw918) 2005-04-01 01:39:41.000-0600

If after reading section 20.10 of the RFC you still feel this is a bug please contact someone on #asterisk-bugs.

Thanks,
/b