[Freeswitch-users] Dialplan: Outbound route: destination_number: regex question

Nate nathan.port at gmail.com
Thu Jul 6 04:44:44 UTC 2017


Heaps of thanks David, and apologies for my lack of certainty regarding
what you mean by "trace".

I have increased debugging on all aspects and seem have turned up the
following entries from the log and thought I would ask for a sanity check
here.
Does the context look okay to you? 0223334444 is an alias for my mobile
number.

I can see where certain decisions are being made such as responding to my
INVITE with 480 at the end, but why? Is there another log I can set up or
something?

...
2017-07-06 16:10:40.694638 [DEBUG] mod_sofia.c:143 sofia/internal/
200 at 192.168.1.13 SOFIA ROUTING
2017-07-06 16:10:40.694638 [DEBUG] switch_core_state_machine.c:236
sofia/internal/200 at 192.168.1.13 Standard ROUTING
2017-07-06 16:10:40.694638 [INFO] mod_dialplan_xml.c:637 Processing 200
<200>->0223334444 in context 192.168.1.13
Dialplan: sofia/internal/200 at 192.168.1.13 parsing
[192.168.1.13->user_exists] continue=true
Dialplan: sofia/internal/200 at 192.168.1.13 Regex (PASS) [user_exists] () =~
// break=on-false
Dialplan: sofia/internal/200 at 192.168.1.13 Action
set(user_exists=${user_exists id ${destination_number} ${domain_name}})
INLINE
2017-07-06 16:10:40.733859 [DEBUG] freeswitch_lua.cpp:365 DBH handle
0x7f2ba40aa750 Connected.
2017-07-06 16:10:40.733859 [DEBUG] freeswitch_lua.cpp:382 DBH handle
0x7f2ba40aa750 released.
EXECUTE sofia/internal/200 at 192.168.1.13 set(user_exists=false)
2017-07-06 16:10:40.733859 [DEBUG] mod_dptools.c:1530 SET sofia/internal/
200 at 192.168.1.13 [user_exists]=[false]
...
///Note: after a whole lot of conditionals and such, things appear to get
interesting again:
...
2017-07-06 16:10:40.753859 [DEBUG] mod_sofia.c:198 sofia/internal/
200 at 192.168.1.13 SOFIA EXECUTE
2017-07-06 16:10:40.753859 [DEBUG] switch_core_state_machine.c:328
sofia/internal/200 at 192.168.1.13 Standard EXECUTE
ed34877a-2bed-4478-947a-13bc01ef90a7 EXECUTE sofia/internal/200 at 192.168.1.13
set(call_direction=local)
 2017-07-06 16:10:40.753859 [DEBUG] mod_dptools.c:1530 SET sofia/internal/
200 at 192.168.1.13 [call_direction]=[local]
EXECUTE sofia/internal/200 at 192.168.1.13 export(origination_callee_id_name=
0223334444)
  2017-07-06 16:10:40.753859 [DEBUG] switch_channel.c:1296 EXPORT
(export_vars) [origination_callee_id_name]=[0223334444]
EXECUTE sofia/internal/200 at 192.168.1.13 set(RFC2822_DATE=Thu, 06 Jul 2017
16:10:40 +1200)
  2017-07-06 16:10:40.753859 [DEBUG] mod_dptools.c:1530 SET sofia/internal/
200 at 192.168.1.13 [RFC2822_DATE]=[Thu, 06 Jul 2017 16:10:40 +1200]
34877a-2bed-4478-947a-13bc01ef90a7
EXECUTE sofia/internal/200 at 192.168.1.13
hash(insert/192.168.1.13-last_dial/200/0226391300)
ed34877a-2bed-4478-947a-13bc01ef90a7 EXECUTE sofia/internal/200 at 192.168.1.13
eval(not_secure)
  2017-07-06 16:10:40.753859 [NOTICE] switch_core_state_machine.c:385
sofia/internal/200 at 192.168.1.13 has executed the last dialplan instruction,
hanging up.
  2017-07-06 16:10:40.753859 [NOTICE] switch_core_state_machine.c:387
Hangup sofia/internal/200 at 192.168.1.13 [CS_EXECUTE] [NORMAL_CLEARING]
  2017-07-06 16:10:40.753859 [DEBUG] switch_core_state_machine.c:650
(sofia/internal/200 at 192.168.1.13) State EXECUTE going to sleep
  2017-07-06 16:10:40.753859 [DEBUG] switch_core_state_machine.c:584
(sofia/internal/200 at 192.168.1.13) Running State Change CS_HANGUP (Cur 1 Tot
15)
  2017-07-06 16:10:40.753859 [DEBUG] switch_core_state_machine.c:850
(sofia/internal/200 at 192.168.1.13) Callstate Change RINGING -> HANGUP
  2017-07-06 16:10:40.753859 [DEBUG] switch_core_state_machine.c:852
(sofia/internal/200 at 192.168.1.13) State HANGUP
  2017-07-06 16:10:40.753859 [DEBUG] mod_sofia.c:438 Channel sofia/internal/
200 at 192.168.1.13 hanging up, cause: NORMAL_CLEARING
2017-07-06 16:10:40.753859 [DEBUG] mod_sofia.c:577 Responding to INVITE
with: 480

Many many thanks for looking this over!

Nate.

On Thu, Jul 6, 2017 at 12:07 AM, David Villasmil <
david.villasmil.work at gmail.com> wrote:

> Fs will fallback to Digest from ACL when the source ip is not allowed,
> this is normal.
>
> Looking at your log, it doesn't seem like the client is actually
> responding to the challenge.
>
> Can you take a trace and look at it? You should see the challenge and then
> an INVITE with credentials.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170706/a5c8cd1b/attachment-0001.html>


More information about the FreeSWITCH-users mailing list