Inbound caller ID issue - after HA implementation
Submitted by sheepsnot on Thu, 08/28/2008 - 7:42am.
Here' s the story. Trixbox initail setup with pri.....inbound calls present callerid properly with name if applicable and 10 digit CID (example below) on polycom phones.
5182334567
After High Availability rollout, polycom's register via SIP to a virtual floating IP (heartbeat) of 10.10.10.10. Primary server in cluster is 10.10.10.21. Now all inbound calls register an inbound caller id of:
sip:5182334567@10.10.10.21
Please advise on how I may get the inbound CID the what the telco is handing off. I've verified the telco is still passing me 10 digits of CID, and asterisk is processing 10 digits of CID.
The issue appears to be in the transition from asterisk to SIP INVITE that the CID is getting altered by adding the "sip:" and server ip information to the endpoints.
Thanks in advance for any help provided.
here's the link
Thu, 08/28/2008 - 5:58pm
This is the basically what I'm running, except without the DRDB piece. Our system is small and static so both server configs are identical software and manually updated via some scripts when necessary so keep them as mirrors, rather than burning resources for DRDB. I'm already running md linux raid, the processor takes enough away from asterisk for that.
http://trixbox.org/forums/trixbox-forums/open-discussion/ha-clust...
Redfone TDMoE appliance with twin DL320's. heartbeat monitors and handles via virtual IP: vsftpd, httpd, and amportal under a VIP. Polycoms register to the VIP via SIP. eth0 = VOIP LAN, eth1 - TDMoE to redfone, eth2 = crossover cable for heartbeat monitoring.
Calls roll properly via failover testing form server to server via the VIP...and inbound CID was fine prior to HA build. Asterisk Logs indicate I'm still getting 10 digit CID from telco, and I can follow all the way through until in SIP debug I see
"From:
which is what the Polycom displays minus the "<>" as callerid.
Prior to HA, the Polycom correctly displayed CID as 5182221234
****numbers may not match previous post as they are fictitious and for example purposes only.
sip that you need to see
Tue, 09/02/2008 - 10:41am
AS requested, here's some sip debug. I've also noticed the Callerid is messed up from extension to extension calls as well. It must be tied to the floating IP. The extensions register themselves to the virtual 10.10.10.10 address. The server addresses are 10.10.10.21 & 10.10.10.22.
[Sep 2 13:28:09] WARNING[22400]: app_macro.c:212 _macro_exec: No such context 'macro-from-zaptel-1' for macro 'from-zaptel-1'
Audio is at 10.10.10.21 port 11292
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.10.10.254:5060:
INVITE sip:4088@10.10.10.254 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
Contact:
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Tue, 02 Sep 2008 17:28:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 242
v=0
o=root 22291 22291 IN IP4 10.10.10.21
s=session
c=IN IP4 10.10.10.21
t=0 0
m=audio 11292 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
---
rix1*CLI>
<--- SIP read from 10.10.10.254:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
CSeq: 102 INVITE
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
Contact:
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.1.0052
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
rix1*CLI>
<--- SIP read from 10.10.10.254:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
CSeq: 102 INVITE
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
Contact:
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.1.0052
Allow-Events: talk,hold,conference
Content-Length: 0
<------------->
--- (10 headers 0 lines) ---
Scheduling destruction of SIP dialog '6ffd2f1375db40d635cff8303f7f7874@10.10.10.21' in 6400 ms (Method: INVITE)
Reliably Transmitting (no NAT) to 10.10.10.254:5060:
CANCEL sip:4088@10.10.10.254 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
CSeq: 102 CANCEL
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
Scheduling destruction of SIP dialog '6ffd2f1375db40d635cff8303f7f7874@10.10.10.21' in 6400 ms (Method: INVITE)
rix1*CLI>
<--- SIP read from 10.10.10.254:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
CSeq: 102 CANCEL
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
Contact:
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.1.0052
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
rix1*CLI>
<--- SIP read from 10.10.10.254:5060 --->
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
CSeq: 102 INVITE
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
Contact:
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.1.1.0052
Content-Length: 0
<------------->
--- (9 headers 0 lines) ---
Transmitting (no NAT) to 10.10.10.254:5060:
ACK sip:4088@10.10.10.254 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.21:5060;branch=z9hG4bK23c37f6e;rport
From: "5181112222"
To:
Contact:
Call-ID: 6ffd2f1375db40d635cff8303f7f7874@10.10.10.21
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0
---
Really destroying SIP dialog '6ffd2f1375db40d635cff8303f7f7874@10.10.10.21' Method: INVITE
Thanks again for taking a look.
RESOLVED***
Tue, 09/16/2008 - 10:45am
Remained persistent and finally resolved this issue. The resolution is to "nano /etc/asterisk/sip_general_custom.conf" (You want custom.conf so freepbx won't overwrite the change moving forward.)
Add the following line:
bindaddr="VIP"
Where "VIP" is the virtual IP address that heartbeat is hosting for you. In my network example above the line would read bindaddr=10.10.10.10
This should resolve any callerid issues on the end nodes when running in a Virtual/Heartbeat Failover environment, and registering your end points to the VIP.
Member Since:
2008-06-04