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