[Freeswitch-users] strange behavior in setting origination_caller_id_number

Jun Sun jsun at junsun.net
Tue Dec 31 02:54:30 MSK 2013 

I looked into the log a little more.

If I put {origination_caller_id_number} into the data field of "bridge"
command, I got this:

2013-12-30 23:40:14.536358 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:40:14.536358 [DEBUG] mod_sofia.c:127
(sofia/external/15102991912) State Change CS_INIT -> CS_ROUTING
2013-12-30 23:40:14.536358 [DEBUG] switch_core_session.c:1351 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:455
(sofia/external/15102991912) State INIT going to sleep
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:415
(sofia/external/15102991912) Running State Change CS_ROUTING
2013-12-30 23:40:14.536358 [DEBUG] sofia.c:5779 Channel
sofia/external/15102991912 entering state [calling][0]
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:471
(sofia/external/15102991912) State ROUTING
2013-12-30 23:40:14.536358 [DEBUG] mod_sofia.c:150
sofia/external/15102991912 SOFIA ROUTING
2013-12-30 23:40:14.536358 [DEBUG] switch_ivr_originate.c:67
(sofia/external/15102991912) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2013-12-30 23:40:14.536358 [DEBUG] switch_core_session.c:1351 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:471
(sofia/external/15102991912) State ROUTING going to sleep
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:415
(sofia/external/15102991912) Running State Change CS_CONSUME_MEDIA
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:490
(sofia/external/15102991912) State CONSUME_MEDIA
2013-12-30 23:40:14.536358 [DEBUG] switch_core_state_machine.c:490
(sofia/external/15102991912) State CONSUME_MEDIA going to sleep
2013-12-30 23:40:16.756330 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:40:16.756330 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:40:16.756330 [DEBUG] sofia.c:5779 Channel
sofia/external/15102991912 entering state [proceeding][183]  <== difference
starts from here
2013-12-30 23:40:16.756330 [DEBUG] sofia.c:5792 Remote SDP:
v=0
...

All other failing cases, I got this trace:

2013-12-30 23:41:22.836327 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:22.836327 [DEBUG] mod_sofia.c:127
(sofia/external/15102991912) State Change CS_INIT -> CS_ROUTING
2013-12-30 23:41:22.836327 [DEBUG] switch_core_session.c:1351 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:455
(sofia/external/15102991912) State INIT going to sleep
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:415
(sofia/external/15102991912) Running State Change CS_ROUTING
2013-12-30 23:41:22.836327 [DEBUG] sofia.c:5779 Channel
sofia/external/15102991912 entering state [calling][0]
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:471
(sofia/external/15102991912) State ROUTING
2013-12-30 23:41:22.836327 [DEBUG] mod_sofia.c:150
sofia/external/15102991912 SOFIA ROUTING
2013-12-30 23:41:22.836327 [DEBUG] switch_ivr_originate.c:67
(sofia/external/15102991912) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2013-12-30 23:41:22.836327 [DEBUG] switch_core_session.c:1351 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:471
(sofia/external/15102991912) State ROUTING going to sleep
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:415
(sofia/external/15102991912) Running State Change CS_CONSUME_MEDIA
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:490
(sofia/external/15102991912) State CONSUME_MEDIA
2013-12-30 23:41:22.836327 [DEBUG] switch_core_state_machine.c:490
(sofia/external/15102991912) State CONSUME_MEDIA going to sleep
2013-12-30 23:41:23.016335 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:23.016335 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:23.016335 [DEBUG] switch_core_session.c:1016 Send signal
sofia/external/15102991912 [BREAK]  <== difference starts from here
2013-12-30 23:41:23.016335 [DEBUG] sofia.c:5779 Channel
sofia/external/15102991912 entering state [terminated][503]
2013-12-30 23:41:23.016335 [NOTICE] sofia.c:6623 Hangup
sofia/external/15102991912 [CS_CONSUME_MEDIA] [NORMAL_TEMPORARY_FAILURE]
2013-12-30 23:41:23.016335 [DEBUG] switch_channel.c:3183 Send signal
sofia/external/15102991912 [KILL]
2013-12-30 23:41:23.016335 [DEBUG] switch_core_session.c:1351 Send signal
sofia/external/15102991912 [BREAK]
2013-12-30 23:41:23.016335 [DEBUG] switch_core_state_machine.c:415
(sofia/external/15102991912) Running State Change CS_HANGUP
...

Could there be something wrong in external.xml config file?  I'm running
this on AWS EC2 instance.

Cheers.

Jun


On Mon, Dec 30, 2013 at 3:28 PM, Peter Olsson <peter at olssononline.se> wrote:

> Are you sure the var ${outbound_caller_id_number} has the correct number
> in that moment? Log the info in that var, and check if lt looks ok. I know
> for sure that effective_caller_id_number does work, so there is something
> else to it. The short example below (cut from your example), works fine at
> least for me.
>
>   <extension name="domestic.example.com">
>
>     <condition field="destination_number" expression="^(\d{11})$">
>       <action application="set" data="effective_caller_id_number=123456"/>
>
>       <action application="bridge" data="sofia/gateway/${default_
> gateway}/$1"/>
>     </condition>
>   </extension>
>
>
> 2013/12/30 Jun Sun <jsun at junsun.net>
>
>> 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}"/>
>>       <!--action application="bridge"
>> data="sofia/gateway/${default_gateway}/$1"/-->  <== NOT WORK
>>       <!--action application="bridge" data="sofia/gateway/idt/$1"/--> <==
>> NOT WORK
>>       <!--action application="bridge"
>> data="{origination_caller_id_number=$${outbound_caller_id_number}}sofia/gateway/${default_gateway}/$1"/-->
>> <== NOT WORK
>>       <action application="bridge"
>> data="{effective_caller_id_number=111111}sofia/gateway/${default_gateway}/$1"/>
>> <== NOT WORK
>>       <!--action application="bridge"
>> data="{origination_caller_id_number=111111}sofia/gateway/${default_gateway}/$1"/-->
>> <== WORKS
>>       <!--action application="bridge"
>> data="[origination_caller_id_number=111111]sofia/gateway/${default_gateway}/$1"/-->
>> <== 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 at 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 at lists.freeswitch.org [mailto:
>>> freeswitch-users-bounces at 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 at 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}"/>
>>>       <!--action application="bridge" data="sofia/gateway/idt/$1"/-->   <===
>>> NOT WORK
>>>
>>>       <!--action application="bridge"
>>> data="[effective_caller_id_number=111111]sofia/gateway/idt/$1"/-->   <===
>>> 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}"/>
>>>       <!--action application="bridge" data="sofia/gateway/idt/$1"/-->   <===
>>> NOT WORK
>>>       <!--action application="bridge"
>>> data="[origination_caller_id_number=111111]sofia/gateway/idt/$1"/-->   <===
>>> 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 at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> 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
>>>
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> 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
>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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/20131230/e695f070/attachment-0001.html

Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list