[Freeswitch-users] External caller-number not shown on forward to external number
Michael Collins
msc at freeswitch.org
Fri Sep 10 16:35:36 PDT 2010
You'll need to get a d-channel trace so that you can see exactly what you
are sending to carrier. The wiki has some info:
http://wiki.freeswitch.org/wiki/OpenZAP#OpenZAP_CLI_Commands
There are commands for both the native stack and libpri. (The commands are
different.) Pastebin the output. In particular you need to see what the
SETUP message looks like. We'll be happy to take a look at the output.
-MC
On Fri, Sep 10, 2010 at 6:44 AM, Peter Waldheim <
peter.waldheim at framesoft.com> wrote:
> Thanks for the tipps, Michael. It seems there is a (provider-)feature
> called „CLIP / no screening“ which had to be activated. But now that it is
> active, it still does not work. I’m rather sure that the variables are set
> correctly, cause it works perfectly well for numbers of our range. Also (one
> of) the test-number(s) I use is just one bit outside of our range, so the
> format should be fine. Still for such numbers the callee always sees our
> base number.
>
> I also found a simple cli test for this:
>
> originate
> {origination_caller_id_number=<test-caller-id-number>}openzap/1/a/<target-number>
> &park()
>
>
>
> Is it possible that there is some spoof-protection somewhere in the
> FreeSWITCH/openzap/libpri stack, or am I doing somethign wrong somehow?
>
> Any further help would be very welcome.
>
>
>
> Thanks and regards
>
> Peter
>
>
>
>
>
> *Von:* Michael Collins [mailto:msc at freeswitch.org]
> *Gesendet:* Freitag, 27. August 2010 18:55
> *An:* FreeSWITCH Users Help
> *Betreff:* Re: [Freeswitch-users] External caller-number not shown on
> forward to external number
>
>
>
> Put in some log apps or the info app prior to your transfer and bridge
> apps. Make sure that these variables actually contain what you hope they do.
> Also, check with the telco to make sure that they allow you to pass
> customized caller ID like this. Some support it and some don't, but
> sometimes you have to ask explicitly to have the feature allowed. Finally,
> make sure that you are passing the phone number in a format that the telco
> wants, i.e. do they require the leading 1.
>
> -MC
>
> On Thu, Aug 26, 2010 at 3:32 AM, Peter Waldheim <
> peter.waldheim at framesoft.com> wrote:
>
> Hi all,
>
> In a diaplan I'm forwarding a call to an external (PRI) number when it
> fails to reach my SIP-Client:
> <action application="bridge" data="user/${dialed_extension}@${domain_name}"/>
> <!-- try to bridge sip -->
> <action application="set"
> data="outbound_caller_id_number=${caller_id_number}"/>
> <action application="set"
> data="outbound_caller_id_name=${caller_id_name}"/>
> <action application="transfer" data="#external-number# XML
> default"/> <!-- transfer to external through dialplan -->
> Then in that dialplan:
> <action application="set"
> data="effective_caller_id_number=${outbound_caller_id_number}"/>
> <action application="set"
> data="effective_caller_id_name=${outbound_caller_id_name}"/>
> <action application="bridge" data="openzap/1/a/$1"/> <!-- bridge to
> external -->
>
> So far this works just fine but one thing: the external party only sees the
> original caller-id if it is an internal one. If the caller was external, I
> only see the default caller-number of my installation. Ideally I'd like to
> always see the original caller id - especially if it is an external number.
> Can anybody please give me a hint whether I'm missing something or this
> might be some call-spoof protection in freeswitch or openzap or libpri or my
> PRI provider?
>
> Thanks a lot
> Peter
> ________________________________
>
>
> Framesoft AG Software Applications
> Sumpfstrasse 15
> 6301 Zug
> Switzerland
> Handelsregister des Kantons Zug: CH-170.3.022.876-2
> Pr?sident & Vorsitzender der Gesch?ftsleitung: Toralf Dittmann
>
> Framesoft AG Software Applications
> Reuterweg 49
> D-60323 Frankfurt am Main
> Germany
> HRB 34142
> Vorsitzender des Aufsichtsrates: Toralf Dittmann
> Vorstand: Jens Saarholz
>
> Framesoft Ltd.
> Business Address:
> 60 Lombard Street
> London EC3V9EA, UK
> Registered Office:
> Hackwood Secretaries Limited
> 1 silk Street
> London EC2Y 8HQ, UK
> Company Number: 4055017
> Directors: Toralf Dittmann, Volker Weber
> Secretary: Volker Weber
>
> Confidentiality Notice: The information contained in this e-mail is
> intended for the named recipient(s) only. It may contain privileged and
> confidential information, and if you are not the addressee or the person
> responsible for delivering this to the addressee, you may not copy,
> distribute or take action in reliance on it. If you have received this
> e-mail in error, please notify us immediately by returning the original
> message to the sender by e-mail and delete this message. Thank you for your
> cooperation.
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> ------------------------------
>
> Framesoft AG Software Applications
> Sumpfstrasse 15
> 6301 Zug
> Switzerland
> Handelsregister des Kantons Zug: CH-170.3.022.876-2
> Präsident & Vorsitzender der Geschäftsleitung: Toralf Dittmann
>
> Framesoft AG Software Applications
> Reuterweg 49
> D-60323 Frankfurt am Main
> Germany
> HRB 34142
> Vorsitzender des Aufsichtsrates: Toralf Dittmann
> Vorstand: Jens Saarholz
>
> Framesoft Ltd.
> Business Address:
> 60 Lombard Street
> London EC3V9EA, UK
> Registered Office:
> Hackwood Secretaries Limited
> 1 silk Street
> London EC2Y 8HQ, UK
> Company Number: 4055017
> Directors: Toralf Dittmann, Volker Weber
> Secretary: Volker Weber
>
> Confidentiality Notice: The information contained in this e-mail is
> intended for the named recipient(s) only. It may contain privileged and
> confidential information, and if you are not the addressee or the person
> responsible for delivering this to the addressee, you may not copy,
> distribute or take action in reliance on it. If you have received this
> e-mail in error, please notify us immediately by returning the original
> message to the sender by e-mail and delete this message. Thank you for your
> cooperation.
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100910/c6bae782/attachment-0001.html
More information about the FreeSWITCH-users
mailing list