CallerID withheld problem
Hello there.... One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box. The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234"). The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id. Message Header is: Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373 I forward this on as: Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41> I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful. But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this. The current dialplan is: <extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension> Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly. But that "privacy" setting doesn't seem to be enough. Any ideas or suggestions for more diagnostics?
At a quick glance... sounds like you want to normalize everything to the 0XX format. If you're getting +44 which should just be 0, then match ^\+44(\d*)$ and set effective_caller_id_number to be 0$1. -Avi On Tue, May 20, 2014 at 7:26 PM, Alex Lake <alex@digitalmail.com> wrote:
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes, I've done that, but it's still coming through as CLI withheld (although we know what it is). Coming from a Q.931 background, that's quite normal. I presume the SIP equivalent is Privacy="yes" but here I've attempted to set it to "no" to little avail! Cheers, Alex
At a quick glance... sounds like you want to normalize everything to the 0XX format. If you're getting +44 which should just be 0, then match ^\+44(\d*)$ and set effective_caller_id_number to be 0$1.
-Avi
On Tue, May 20, 2014 at 7:26 PM, Alex Lake <alex@digitalmail.com <mailto:alex@digitalmail.com>> wrote:
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41 <mailto:sip%3A448700802332@213.239.197.41>> From: <sip:02070604380@217.145.67.2 <mailto:sip%3A02070604380@217.145.67.2>>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202 <mailto:sip%3A%2B442070604380@193.113.183.202>> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com <mailto:3560925-3609589914-358457@MSX1.mydomain.com> CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060 <http://sip:02070604380@217.145.67.2:5060>> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41 <mailto:sip%3A02070604380@213.239.197.41>>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200 <mailto:sip%3A448700802332@89.202.128.200>> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060 <http://sip:mod_sofia@213.239.197.41:5060>> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41 <mailto:sip%3A02070604380@213.239.197.41>>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200 <mailto:destination_number%7D@89.202.128.200>"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
No virus found in this message. Checked by AVG - www.avg.com <http://www.avg.com> Version: 2014.0.4570 / Virus Database: 3950/7523 - Release Date: 05/20/14
One thing I could do with help on is how to make the sip_cid_type work for INBOUND calls? i.e. ignore what's in the P-Asserted header and just take the "from" address. I don't have a specific trunk set up for these calls, they just come in on IP-authorised acl. FWIW, this carrier is the only source of inbound traffic on the box, so setting a global default would be acceptable. Cheers!
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7523 - Release Date: 05/20/14
Just to say that I've tried changing internal.xml: <param name="caller-id-type" value="none"/> And (belt and braces?) have in the dialplan: <extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="set" data="sip_cid_type=none"/> <action application="export" data="sip_cid_type=none"/> <action application="lua" data="fixcli.lua"/> <action application="privacy" data="no"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension> But the lua script is still seeing caller id taken from P-Asserted-Identity.
One thing I could do with help on is how to make the sip_cid_type work for INBOUND calls?
i.e. ignore what's in the P-Asserted header and just take the "from" address.
I don't have a specific trunk set up for these calls, they just come in on IP-authorised acl.
FWIW, this carrier is the only source of inbound traffic on the box, so setting a global default would be acceptable.
Cheers!
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7523 - Release Date: 05/20/14
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7531 - Release Date: 05/21/14
Anyone able to help with this in exchange for cash?! ;-) Alex
One thing I could do with help on is how to make the sip_cid_type work for INBOUND calls?
i.e. ignore what's in the P-Asserted header and just take the "from" address.
I don't have a specific trunk set up for these calls, they just come in on IP-authorised acl.
FWIW, this carrier is the only source of inbound traffic on the box, so setting a global default would be acceptable.
Cheers!
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. "02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7523 - Release Date: 05/20/14
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7531 - Release Date: 05/21/14
mod_translate perhaps? https://wiki.freeswitch.org/wiki/Mod_translate You can use it to normalize back to the national format before it hits the dialplan. On 27 May 2014 09:51, Alex Lake <alex@digitalmail.com> wrote:
Anyone able to help with this in exchange for cash?! ;-)
Alex
One thing I could do with help on is how to make the sip_cid_type work for INBOUND calls?
i.e. ignore what's in the P-Asserted header and just take the "from" address.
I don't have a specific trunk set up for these calls, they just come in on IP-authorised acl.
FWIW, this carrier is the only source of inbound traffic on the box, so setting a global default would be acceptable.
Cheers!
Hello there....
One of our carriers has changed their signalling today and its resulted in some strange behaviour through our Freeswitch box.
The change was that the P-Asserted ID has changed format to have a "+44" at the beginning - it used to be in the national format (eg. " 02070601234").
The problem manifests itself further down the chain (the FS box forwards to an Asterisk box which forwards to a legacy system using E1's and Aculab cards). For some reason the E1 interprets the signalling as withheld caller id.
Message Header is:
Max-Forwards: 69 Session-Expires: 3600;refresher=uac Min-SE: 600 Supported: timer, 100rel To: <sip:448700802332@213.239.197.41> From: <sip:02070604380@217.145.67.2>;tag=3609589914-358461 P-Asserted-Identity: <sip:+442070604380@193.113.183.202> Call-ID: 3560925-3609589914-358457@MSX1.mydomain.com CSeq: 1 INVITE Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Via: SIP/2.0/UDP 217.145.67.2:5060;branch=z9hG4bK630bccab557da527f8875b902c88fb6b Contact: <sip:02070604380@217.145.67.2:5060> Content-Type: application/sdp Accept: application/sdp Content-Length: 373
I forward this on as:
Via: SIP/2.0/UDP 213.239.197.41;rport;branch=z9hG4bKm3jHajt7g1gaa Max-Forwards: 68 From: "02070604380" <sip:02070604380@213.239.197.41>;tag=57cmagKg0yctN To: <sip:448700802332@89.202.128.200> Call-ID: 81dbf634-5ad9-1232-1f90-d43d7ee2fdec CSeq: 59964493 INVITE Contact: <sip:mod_sofia@213.239.197.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140319T002132Z~b96946822d~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Privacy: none Content-Type: application/sdp Content-Disposition: session Content-Length: 207 X-FS-Support: update_display,send_info P-Asserted-Identity: "02070604380" <sip:02070604380@213.239.197.41>
I don't know if the SIPerati can discern anything from this. I could pastebin the pcap file if that would be useful.
But the angle might be for me to tell FS to give calls a sip_cid_type of "none". But I don't quite undersrand from the wiki (https://wiki.freeswitch.org/wiki/Variable_sip_cid_type) where I should put this.
The current dialplan is:
<extension name="ajl-test2"> <condition field="destination_number" expression="^44"> <action application="privacy" data="no"/> <action application="log" data="INFO caller_id_number 0${caller_id_number:3}"/> <action application="export" data="origination_caller_id_number=0${caller_id_number:3}"/> <action application="bridge" data="sofia/internal/${destination_number}@89.202.128.200"/> </condition> </extension>
Note the hack to change callerid from +44xxx... format to 0xxx... has been replaced by a Lua script that handles it a bit more cleanly.
But that "privacy" setting doesn't seem to be enough.
Any ideas or suggestions for more diagnostics?
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7523 - Release Date: 05/20/14
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3950/7531 - Release Date: 05/21/14
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F <info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
participants (3)
-
Alex Lake
-
Andrew Cassidy
-
Avi Marcus