On Tue, Dec 31, 2013 at 1:39 PM, Jun Sun <jsun@junsun.net> wrote:

Thanks for the all the helping. Now I have beaten this issue to death.

I did a SIP tracing. Peter is right on money. My SIP provider does not like "0000000000" to be caller id number. To be specific and to add confusion, their server doesn't like if it is 10 zero's. (All other cases are fine, e.g, 9 zero's!) Their server would return service not available . That is why we see NORMAL_TEMPORARY_FAILURE.

It is good to know the world is still sane, except for the little 10 zero quirk from IDT. :)

Cheers. And happy new year.

Jun

On Tue, Dec 31, 2013 at 9:44 AM, Sean Devoy <sdevoy@bizfocused.com> wrote:

Your first “set” line has a typo:

   <action application="set" data="origination_caller_id_number=${outbound_calller_id_number"/>

It is missing the closing “}” on ${outbound_calller_id_number". So origination_caller_id_number is not being set.

I think that is why these fail:

       <== NOT WORK
       <== NOT WORK

As per the wiki, effective_caller_id_number cannot be set in an origination string, so this fails:

<action application="bridge" data="{effective_caller_id_number=111111}sofia/gateway/${default_gateway}/$1"/> <== NOT WORK

And this works because you are finally assigning a value to origination_caller_id_number:

 <== WORKS

Use the LOG application to check your values before the bridge statement, like this:

<action application="log" data="INFO origination_caller_id_number is $origination_caller_id_number "/>

Hope that helps,

Sean

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jun Sun
Sent: Monday, December 30, 2013 5:59 PM

To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] strange behavior in setting origination_caller_id_number

Switching to "{}" makes no difference here. See the updated rules below.

This is driving me nuts because there is no way for me to set caller id dynamically (because I cannot do that inside the data field). Why would freeswitch ignore channel variable set? And why would it insist on origination_caller_id_number?

<extension name="domestic.example.com">
    <condition field="${toll_allow}" expression="domestic"/>
    <condition field="destination_number" expression="^(\d{11})$">
      <action application="set" data="origination_caller_id_number=${outbound_calller_id_number"/>
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/>
       <== NOT WORK
       <== NOT WORK
       <== NOT WORK
      <action application="bridge" data="{effective_caller_id_number=111111}sofia/gateway/${default_gateway}/$1"/> <== NOT WORK
       <== WORKS
       <== WORKS
    </condition>
</extension>

IN the case when it does not work, I got NORMAL_TEMPORARY_FAILURE:

2013-12-30 22:53:12.876331 [NOTICE] sofia.c:6623 Hangup sofia/external/15102991913 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE]

Cheers.

Jun

On Mon, Dec 30, 2013 at 12:13 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:

I use {} and I am not familiar with [] in the bridge statement. Try,

< action application="bridge" data="{effective_caller_id_number=111111}sofia/gateway/idt/$1" />

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jun Sun
Sent: Monday, December 30, 2013 1:46 PM
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] strange behavior in setting origination_caller_id_number

Any takers of this challenge? :)

Jun

On Sun, Dec 29, 2013 at 9:38 AM, Jun Sun <jsun@junsun.net> wrote:

Sorry! The 2nd "NOT WORK" example was meant to show setting "effective_caller_id_number", not "origination_caller_id_number". So the correct dialplan is as follows.

<extension name="domestic.example.com">
    <condition field="${toll_allow}" expression="domestic"/>
    <condition field="destination_number" expression="^(\d{11})$">
      <action application="set" data="origination_caller_id_number=11111111"/>
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/>
       <=== NOT WORK

         <=== NOT WORK

      <action application="bridge" data="[origination_caller_id_number=111111]sofia/gateway/idt/$1"/> <=== WORKS!!
    </condition>
</extension>

Cheers.

Jun

On 12/29/2013 9:25 AM, Jun Sun wrote:

I have a very simple call plan to allow internal extension to call external PSTN numbers. See below.

<extension name="domestic.example.com">
    <condition field="${toll_allow}" expression="domestic"/>
    <condition field="destination_number" expression="^(\d{11})$">
      <action application="set" data="origination_caller_id_number=11111111"/>
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
      <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/>
       <=== NOT WORK
         <=== NOT WORK
      <action application="bridge" data="[origination_caller_id_number=111111]sofia/gateway/idt/$1"/> <=== WORKS!!
    </condition>
</extension>

There a couple of things strange here:

1. I have to put origination_caller_id_number inside data field of "bridge" application in order for the dialing out to happen. Why putting it outside as channel variable does not work?

2. Actually because bridge command is for leg-B, really it should be "effective_caller_id_number" not "origination_caller_id_number". Is that right?

I'm using IDT express as SIP carrier. I don't know if they changed something or I changed configuration in freeswitch. Now it seems I have to set origination_caller_id_number if I want to use IDT for outbound calls.

I'd really appreciate your help.

Cheers.

Jun

_________________________________________________________________________
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

_________________________________________________________________________
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

_________________________________________________________________________
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

Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬

☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH

☞ irc.freenode.net #freeswitch ☞ http://freeswitch.org/g+

ClueCon Weekly Development Call

☎ sip:888@conference.freeswitch.org ☎ +19193869900