[Home]

Summary:ASTERISK-03522: Asterisk changing 'From:' field after authorization challenge.
Reporter:eko1 (eko1)Labels:
Date Opened:2005-02-15 09:22:37.000-0600Date Closed:2005-02-18 18:31:53.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I've been having some trouble lately concerning CID with my VoIP provider. Whenever I made a call to the USA, the CID shown on the called person's phone was his/her NUMBER. And sometimes, if the call was made to a person's cellphone, I would either be asked for a password to enter their voicemail or if they hadn't set a password, HAVE COMPLETE ACCESS to his/her VOICEMAIL.

I've discussed this with my provider. They said they don't do anything with the CID. I did a 'sip debug' and placed a call to the USA. Here's part of the initial dialog:

SIP Debugging Enabled for IP: 69.20.61.219:5060
   -- Executing Macro("SIP/310-447a", "call-international|17324609000") in new stack
   -- Executing Dial("SIP/310-447a", "sip/kayote/17324609000") in new stack We're at 172.16.1.251 port 15502 Answering/Requesting with root capability 0x100 (g729) Answering with preferred capability 0x4 (ulaw) Answering with non-codec capability 0x1 (telephone-event)
12 headers, 11 lines
Reliably Transmitting:
INVITE sip:17324609000@sip-devices-01.kayote.net SIP/2.0
Via: SIP/2.0/UDP 172.16.1.251:5060;branch=z9hG4bK5180bb78
From: "310" <sip:310@172.16.1.251>;tag=as7e61b074
To: <sip:17324609000@sip-devices-01.kayote.net>
Contact: <sip:310@172.16.1.251>
Call-ID: 4a37cd31777b9f01628e3fcc41650219@172.16.1.251
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Mon, 14 Feb 2005 20:54:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 5841 5841 IN IP4 172.16.1.251
s=session
c=IN IP4 172.16.1.251
t=0 0
m=audio 15502 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
(no NAT) to 69.20.61.219:5060
   -- Called kayote/17324609000


Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.1.251:5060;branch=z9hG4bK5180bb78
From: 310 <sip:310@172.16.1.251>;tag=as7e61b074
To: <sip:17324609000@sip-devices-01.kayote.net>
CSeq: 102 INVITE
Call-ID: 4a37cd31777b9f01628e3fcc41650219@172.16.1.251
Content-Length: 0


7 headers, 0 lines


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 172.16.1.251:5060;branch=z9hG4bK5180bb78;received=63.245.57.70
From: 310 <sip:310@172.16.1.251>;tag=as7e61b074
To: <sip:17324609000@sip-devices-01.kayote.net>
CSeq: 102 INVITE
Call-ID: 4a37cd31777b9f01628e3fcc41650219@172.16.1.251
Proxy-Authenticate: DIGEST realm="kayote.com", nonce="2ba74a7b1006505837365579b163dd3c", algorithm=MD5, opaque="3023060710"
Content-Length: 0


8 headers, 0 lines
Transmitting:
ACK sip:17324609000@sip-devices-01.kayote.net SIP/2.0
Via: SIP/2.0/UDP 172.16.1.251:5060;branch=z9hG4bK5180bb78
From: "310" <sip:310@172.16.1.251>;tag=as7e61b074
To: <sip:17324609000@sip-devices-01.kayote.net>
Contact: <sip:310@172.16.1.251>
Call-ID: 4a37cd31777b9f01628e3fcc41650219@172.16.1.251
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

(no NAT) to 69.20.61.219:5060
We're at 172.16.1.251 port 15502
Answering/Requesting with root capability 0x100 (g729) Answering with preferred capability 0x4 (ulaw) Answering with non-codec capability 0x1 (telephone-event) Reliably Transmitting:
INVITE sip:17324609000@sip-devices-01.kayote.net SIP/2.0
Via: SIP/2.0/UDP 172.16.1.251:5060;branch=z9hG4bK0ddf73a6
From: "17324609000" <sip:17324609000@172.16.1.251>;tag=as7e61b074
To: <sip:17324609000@sip-devices-01.kayote.net>
Contact: <sip:17324609000@172.16.1.251>
Call-ID: 4a37cd31777b9f01628e3fcc41650219@172.16.1.251
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="XXXXXX", realm="kayote.com", algorithm=MD5, uri="sip:17324609000@sip-devices-01.kayote.net", nonce="2ba74a7b1006505837365579b163dd3c", response="57ea67bc4b3164093b15ed0acc68518d", opaque="3023060710"
Date: Mon, 14 Feb 2005 20:54:55 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 5841 5842 IN IP4 172.16.1.251
s=session
c=IN IP4 172.16.1.251
t=0 0
m=audio 15502 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
(no NAT) to 69.20.61.219:5060

I don't know if this is a bug or a misconfiguration on my part, but what (mis)configuration would cause that?!
Comments:By: Kevin P. Fleming (kpfleming) 2005-02-15 09:34:44.000-0600

This is probably related to the Caller ID handling change that went into Asterisk recently, and then was backed out of the stable branch. Please update to the very latest stable CVS version (you are a little more than a week behind) and try again. Let us know if the behavior changes; we need to address this issue in CVS HEAD still, and I suspect this CLID change is having deeper effects than was realized when it was made.
By: Mark Spencer (markster) 2005-02-15 09:55:22.000-0600

This has already been fixed in CVS -- in head for sure, and I'm pretty sure for stable, but we'll let Russell comment.
By: Russell Bryant (russell) 2005-02-18 18:31:53.000-0600

Yeah, for stable, I backed out that change.  So, in current stable cvs, and in the near future 1.0.6, this should be fixed.