Sending SMS messages via doodle

[Alan Evans]

Hello 2600devs,

I'm finally getting around to looking at the doodle app.
You may remember quite some time ago I submitted a couple of pull
requests in this area.
These got closed when doodle came along.

I've studied the code and it looks great. Much more comprehensive than
my feeble attempt.
[ the doc/ folder is some what weak :-( ]

What I'd like to do now is add a 3rd party SMS aggregator such as
Esendex [1] or Thecallr [2] or direct to SS7 MAP.

Can you let me know if this has been considered in the design of the
doodle and if so how should I approach this?

Regards and Thanks
Alan R Evans
KAGE Systems Ltd

[1] http://developers.esendex.com/APIs/REST-API/messagedispatcher
[2] http://thecallr.com/docs/api/json-rpc/

[stormqloud]

I only casually looked at the code, but it seems to work off SIP MESSAGE with Freeswitch to handle the SMS delivery.   Maybe I missed something to handle HTTP API.

My guess is from there you could send it to it's own Kamailio and have Kamailio translate it into a HTTP API GET/POST.

Basically use Kamailio like Homer/sipcapture does.

tx

[VCCS Telecom]

Same for me, casually looked into it. The issue I see is compatibility with a Carriers SMS protocal, im not sure how FS handles the translation or if at all. I assume it would function for internal applications though.

[Alan Evans]

On 14/05/2015 12:22:PM, Alan Evans wrote:
> Hello 2600devs,
>

> What I'd like to do now is add a 3rd party SMS aggregator such as
> Esendex [1] or Thecallr [2] or direct to SS7 MAP.
>
> Can you let me know if this has been considered in the design of the
> doodle and if so how should I approach this?
>
> Regards and Thanks
> Alan R Evans
> KAGE Systems Ltd
>
> [1] http://developers.esendex.com/APIs/REST-API/messagedispatcher
> [2] http://thecallr.com/docs/api/json-rpc/

So I've now built a test environment to play with doodle and it doesn't
seem to work the way I was expecting.

I was expecting kamailio to send the SIP/MESSAGE to doodle directly via
rabbitmq using kazoo_publish
However what I find is that kamailio is relaying the SIP/MESSGAGE to
freeswitch.

It seems to me that the kamailio config needs to be updated but maybe
I'm reading it all wrong.

I'm using the git branches 3.19 for both kazoo and kazoo-configs

Any pointers you can give me will be greatly appreciated. A brief
explanation of how it's supposed to work would be very helpful.

Thanks in advance
AlanE.

[Alan Evans]

On 20/05/2015 10:47:AM, Alan Evans wrote:
>
> So I've now built a test environment to play with doodle and it
> doesn't seem to work the way I was expecting.
>
> I was expecting kamailio to send the SIP/MESSAGE to doodle directly
> via rabbitmq using kazoo_publish
> However what I find is that kamailio is relaying the SIP/MESSGAGE to
> freeswitch.
>
> It seems to me that the kamailio config needs to be updated but maybe
> I'm reading it all wrong.
>
> I'm using the git branches 3.19 for both kazoo and kazoo-configs
>
> Any pointers you can give me will be greatly appreciated. A brief
> explanation of how it's supposed to work would be very helpful.
>
> Thanks in advance
> AlanE

If I add the following to route[HANDLE_MESSAGE] in kamailio default.cfg
then I get the SIP/MESSAGE passed to doodle_handle_inbound

$var(Payload) = '{ "Event-Category" : "message",
"Event-Name" : "inbound", "Message-ID" : "$ci", "From" : "$fu", "To" :
"$tu", "Body" : "$rb" }';
$var(exchange) = "sms";
$var(RoutingKey) = "message.inbound." + "$ci";
xlog("L_INFO", "sending message to kazoo for $ci");
kazoo_publish($var(exchange), $var(RoutingKey),
$var(Payload));

I think I'm on the right track but some validation from you guys would
be great.

Thanks
AlanE

[Luis Azedo]

did you try enabling the MESSAGE-ROLE in kamailio ?

> --
> You received this message because you are subscribed to the Google Groups
> "2600hz-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 2600hz-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alan Evans]

On 20/05/2015 03:23:PM, Luis Azedo wrote:
> did you try enabling the MESSAGE-ROLE in kamailio ?

Hi Luis,

Yes, forgot to mention that, I have enabled MESSAGE-ROLE in local.cfg.

I've now upgraded to 3.20 to see if that helps.
However 3.20 has more validations in wapi_sms so I need to update my
hack some more.
Can you just provide a brief description of how it should work?

[Luis Azedo]

msg -> kamailio -> dispatcher -> freeswitch -> ecallmgr -> route_req -> doodle

it seems you are trying to create a shortcut from kamailio to doodle.

[Alan Evans]

On 20/05/2015 04:22:PM, Luis Azedo wrote:
> msg -> kamailio -> dispatcher -> freeswitch -> ecallmgr -> route_req -> doodle

Thanks Luis, very helpful to know how it should work.

>
> it seems you are trying to create a shortcut from kamailio to doodle.

It seems so.
If this is the intended flow then in my testbed the SIP/MESSAGE is
getting dropped in freeswitch.
Before doodle, I had to make a number of changes in freeswitch in order
for it to forward the MESSAGE to ecallmgr.
I can't find any such code changes in the current freeswitch branch. I'm
using 1.4.15 from github.
Can you confirm which freeswitch branch I should be using and maybe
point me to the commit which enables this behaviour?

Many Thanks
AlanE

[Luis Azedo]

we have it running with kazoo-freeswitch-1.4-7

[Alan Evans]

I needed to load mod_sms so that freeswitch requests a chatplan from
ecallmgr.

[Alan Evans]

On 20/05/2015 04:22:PM, Luis Azedo wrote:

> msg -> kamailio -> dispatcher -> freeswitch -> ecallmgr -> route_req -> doodle

Hi Luis,

I'm now getting the chatplan fetch request into ecallmgr,
ecallmgr is publishing a route_req however doodle_inbound_handler is
not processing it.

I've traced this down to the fact that the variable_ecallmgr* Custom
Channel Variables are absent so there is no Account Info available:

process_route_req,
[chatplan,
'frees...@xxxxx.xxx.xxx',
<<"53be790f-baed-46cd-9f6b-ccdbada288cc">>,
<<"3892d70b-501b-4105-8926-47c8517229de">>,
[{<<"variable_sip_profile">>,
<<"sip_clients">>},
{<<"variable_sip_to_host">>,
<<"sip.kagesys.com">>},
{<<"variable_sip_to_user">>,
<<"xxxx">>},
{<<"variable_sip_to_uri">>,
<<"xx...@x.x.x">>},
{<<"variable_sip_from_host">>,
<<"x.x.x">>},
{<<"variable_sip_from_user">>,
<<"xxxx">>},
{<<"variable_sip_from_uri">>,
<<"xx...@x.x.x">>},
{<<"Caller-Destination-Number">>,
<<"xxxx">>},
{<<"Caller-Caller-ID-Number">>,
<<"xxxx">>},
{<<"Resource-Type">>,
<<"sms">>},
{<<"Call-Direction">>,
<<"outbound">>},
{<<"Event-Name">>,
<<"MESSAGE">>},
{<<"Core-UUID">>,
<<"cb63f9c6-7b87-4c8c-8304-4d9cdd79d32c">>},
{<<"FreeSWITCH-Hostname">>,
<<"xxxx.xxxx.xxxx">>},
{<<"FreeSWITCH-Switchname">>,
<<"xxx.xxx.xxx">>},
{<<"FreeSWITCH-IPv4">>,
<<"x.x.x.x">>},
{<<"FreeSWITCH-IPv6">>,
<<"::1">>},
{<<"Event-Date-Local">>,
<<"2015-05-21 04:11:54">>},
{<<"Event-Date-GMT">>,
<<"Thu, 21 May 2015 08:11:54 GMT">>},
{<<"Event-Date-Timestamp">>,
<<"1432195914217694">>},
{<<"Event-Calling-File">>,
<<"sofia_presence.c">>},
{<<"Event-Calling-Function">>,
<<"sofia_presence_handle_sip_i_message">>},
{<<"Event-Calling-Line-Number">>,
<<"4964">>},
{<<"Event-Sequence">>,
<<"7449">>},
{<<"login">>,
<<"sip:mod_...@10.0.1.162:5065">>},
{<<"proto">>,<<"sip">>},
{<<"to_proto">>,
<<"sip">>},
{<<"from">>,
<<"xx...@x.x.x">>},
{<<"from_user">>,
<<"xxxxxxx">>},
{<<"from_host">>,
<<"sip.kagesys.com">>},
{<<"to_user">>,
<<"xxxxxxx">>},
{<<"to_host">>,
<<"x.x.x">>},
{<<"from_sip_ip">>,
<<"x.x.x.x">>},
{<<"from_sip_port">>,
<<"5060">>},
{<<"to">>,
<<"xx...@x.x.x">>},
{<<"subject">>,
<<"SIMPLE MESSAGE">>},
{<<"context">>,
<<"context_2">>},
{<<"type">>,
<<"text/plain">>},
{<<"sip_from_uri">>,
<<"xx...@x.x.x">>},
{<<"sip_from_user">>,
<<"xxxxx">>},
{<<"sip_from_host">>,
<<"x.x.x">>},
{<<"sip_to_uri">>,
<<"xx...@x.x.x">>},
{<<"sip_to_user">>,
<<"xxxx">>},
{<<"sip_to_host">>,
<<"x.x.x">>},
{<<"Message-ID">>,
<<"nKY5RN8x-MofAgFLBLqtn8v4gO974Gdk">>},
{<<"Unique-ID">>,
<<"3892d70b-501b-4105-8926-47c8517229de">>},
{<<"Call-ID">>,
<<"3892d70b-501b-4105-8926-47c8517229de">>},
{<<"variable_sip_received_ip">>,
<<"x.x.x.x">>},
{<<"from_full">>,
<<"<sip:xx...@x.x.x>;tag=xVVipm23bF-sje3x2Y7J.B63d-Z4lru1">>},
{<<"sip_profile">>,
<<"sip_clients">>},
{<<"variable_sip_h_X-AUTH-IP">>,
<<"x.x.x.x">>},
{<<"variable_sip_h_X-AUTH-PORT">>,
<<"39088">>},
{<<"dest_proto">>,
<<"sip">>},
{<<"max_forwards">>,
<<"70">>},
{<<"body">>,
<<"Bgffgffgg">>}]]}


Kazoo logs: http://pastie.org/10200371
Freeswitch logs: http://pastie.org/10200380

There seems to be a big difference between dialplan and chatplan requests.
The dialplan request includes the channel variables whereas they are
absent in chatplan. I guess because there is no channel for a chatplan.
The Account-ID etc variables are therefore missing and doodle ignores
the route_req.

I'm now looking at the mod_sms.c code to see how the chatplan XML
request is generated.
Let me know if I'm going down the wrong path, yet again.

Regards
Alan

[Luis Azedo]

make sure you're using kazoo-freeswitch-1.4.7
also make sure your freeswitch profile has these settings

<!-- MESSAGES -->
<param name="enable-pre-register" value="true" />
<param name="in-dialog-chat" value="false"/>
<param name="auth-messages" value="false" />
<param name="enable-message-cached-authentication" value="true" />
<param name="enable-message-blind-auth" value="true" />
<param name="fire-message-events" value="false"/>

look for other places where these vars may be set

[Alan Evans]

On 21/05/2015 05:12:PM, Luis Azedo wrote:
> make sure you're using kazoo-freeswitch-1.4.7
> also make sure your freeswitch profile has these settings
>
> <!-- MESSAGES -->
> <param name="enable-pre-register" value="true" />
> <param name="in-dialog-chat" value="false"/>
> <param name="auth-messages" value="false" />
> <param name="enable-message-cached-authentication" value="true" />
> <param name="enable-message-blind-auth" value="true" />
> <param name="fire-message-events" value="false"/>
>
> look for other places where these vars may be set

Hello Luis,

I've patched mod_sms.c so that the variable_ecallmgr* CCVs are included
in the XML chatplan request and this has kicked doodle into life.
I'm currently getting the following XML response:

<document type="freeswitch/xml">
<section name="chatplan" description="Chat Response">
<context name="context_2">
<extension name="chat plan" continue="false">
<condition><action application="stop" data="stored"/></condition>
</extension>
</context>
</section>
</document>

I'm working through the logic at the moment.

I will double check if any of these params will add the CCVs.

Thanks for your support
Alan

[Luis Azedo]

you don't need to patch anything if you're using it the way i recommend it.
you seem to go thru obscure ways.

[Alan Evans]

On 21/05/2015 08:09:PM, Luis Azedo wrote:
> really, use kazoo-freeswitch-1.4.7, it just works.
> or..., any reason for not using ?
Hi Luis,

I am using 1.4.7

freeswitch@internal> version
FreeSWITCH Version 1.4.7+git~20150310T023357Z~474838208b~64bit (git
4748382 2015-03-10 02:33:57Z 64bit)

freeswitch@internal>

[Luis Azedo]

well, you said you were patching so i'm not sure if there's anything else you may have changed :)

channel vars are created by auth

    <param name="auth-messages" value="true" />

    <param name="enable-message-cached-authentication" value="true" />
    <param name="enable-message-blind-auth" value="true" />

[Alan Evans]

On 21/05/2015 06:46:PM, Luis Azedo wrote:
> you don't need to patch anything if you're using it the way i recommend it.
> you seem to go thru obscure ways.

Hi Luis,

It seems that way to me as well.

The only way I can make doodle do anything is by setting

<param name="auth-messages" value="true" />

Which turns on authentication for SIP/MESSAGE requests, maybe a good idea.
and applying my patch[1] to mod_sms.c which adds the CCVs to the chatplan.

Can you confirm whether or not the chatplan fetch request should have
ecallmgr variables present?

{<<"variable_ecallmgr_Account-Name">>,
{<<"variable_ecallmgr_Account-Realm">>,
{<<"variable_ecallmgr_Owner-ID">>,
{<<"variable_ecallmgr_Authorizing-Type">>,
{<<"variable_ecallmgr_Authorizing-ID">>,
{<<"variable_ecallmgr_Account-ID">>,
{<<"variable_ecallmgr_Realm">>,
{<<"variable_ecallmgr_Username">>,

Looking at the doodle handler code it seems that it must and looking at
the mod_sms code it seems that it doesn't.

[1] http://pastie.org/10200935

Thanks
AlanE

[Luis Azedo]

really, use kazoo-freeswitch-1.4.7, it just works.
or..., any reason for not using ?

[Alan Evans]

Hi Luis,

In any case I'm very happy at the moment.
I can see that doodle is very similar to callflow.
It uses cf_sms_[module] rather than cf_[module] to handle the flow.
This is perfect for my application.
I can write a cf_sms_ss7map that will convert the SIP/MESSAGE to an MAP-SMS-DELIVER PDU, forward to my SS7 Gateway and out to the mobile via SMS.

When you have some time, please take a look at the patch[1] and if it's complete garbage let me know how it's supposed to work.

cheers
AlanE

[1] http://pastie.org/10200935

[Matt - nurango.ca]

Hi there. I am revisiting this post and the info was very helpful to get going thank you to all. I seem to be stuck in doodle vortex though that endlessly loops my messages, even after delivery. I am sending SMS from an external number to a DID which points to a phone. The message is received but as mentioned kazoo and FS loops endlessly causing a flood. I'm wondering if anyone has an idea of what the issue is? FS version is kazoo-freeswitch-4.0-7.el7

Kazoo Log

-----------

Jun 25 22:08:03 kz 2600hz[3012]: |0000000000|gen_listener:381 (<0.28000.9>) starting new gen_listener proc : doodle_exe

Jun 25 22:08:03 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_assignments:475 (<0.118.0>) assigned existing channel <0.27865.9> on amqp://guest:guest@kz:5672 to new consumer <0.28000.9>

Jun 25 22:08:03 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_assignments:886 (<0.118.0>) registered handlers for channel <0.27865.9> to <0.28000.9>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|gen_listener:1147 (<0.28000.9>) channel started, let's connect

Jun 25 22:08:03 kz 2600hz[3012]: |0000000000|Undefined:Undefined (<0.28002.9>) Supervisor {<0.28002.9>,amqp_channel_sup} started amqp_gen_consumer:start_link(amqp_selective_consumer, [], {<<"client 158.xxx:40769 -> 158.xxxx:5672">>,5146}) at pid <0.28003.9>

Jun 25 22:08:03 kz 2600hz[3012]: |0000000000|Undefined:Undefined (<0.28002.9>) Supervisor {<0.28002.9>,amqp_channel_sup} started amqp_channel:start_link(network, <0.125.0>, 5146, <0.28003.9>, {<<"client 158.x.x.x:40769 -> 158.x.x.x:5672">>,5146}) at pid <0.28004.9>

Jun 25 22:08:03 kz 2600hz[3012]: |0000000000|Undefined:Undefined (<0.28002.9>) Supervisor {<0.28002.9>,amqp_channel_sup} started rabbit_writer:start_link(#Port<0.3042>, 5146, 131072, rabbit_framing_amqp_0_9_1, <0.28004.9>, {<<"client x.x.x.x:40769 -> 158.x.x.x:5672">>,5146}) at pid <0.28005.9>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:302 (<0.28000.9>) declared queue kazoo_apps@kz-<0.28000.9>-1e94bf13 via channel <0.27865.9>

Jun 25 22:08:03 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_assignments:600 (<0.118.0>) added new channel <0.28004.9> on amqp://guest:guest@kz:5672 to available pool

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:328 (<0.28000.9>) created consumer amq.ctag-r2hVldOEN3ifGI6Hkm5dOA via channel <0.27865.9>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|gen_listener:889 (<0.28000.9>) queue started: kazoo_apps@kz-<0.28000.9>-1e94bf13

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|gen_listener:1038 (<0.28000.9>) creating new binding: 'sms'

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:321 (<0.28000.9>) bound kazoo_apps@kz-<0.28000.9>-1e94bf13 to sms exchange (routing key message.delivery.3c7bab56cf6087cb10b612e2605c4881) via channel <0.27865.9>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|gen_listener:1038 (<0.28000.9>) creating new binding: 'self'

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:321 (<0.28000.9>) bound kazoo_apps@kz-<0.28000.9>-1e94bf13 to targeted exchange (routing key kazoo_apps@kz-<0.28000.9>-1e94bf13) via channel <0.27865.9>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:159 (<0.28006.9>) published to callctl(amqp://guest:guest@kz:5672) exchange (routing key chatplan_ignored) via <0.27865.9>

Jun 25 22:08:03 kz 2600hz[3012]: |034c65e5c7d06160|kz_amqp_channel:159 (<0.27275.1>) published to configuration(amqp://guest:guest@kz:5672) exchange (routing key doc_edited.account%2F01%2F80%2Ffabe1652a755xxxxxxxxxxxxxxx-201706.sms.201706-1946d9698c2987923625791d8e300452) via <0.27238.1>

Jun 25 22:08:03 kz 2600hz[3012]: |034c65e5c7d06160|kz_amqp_worker:663 (<0.27275.1>) published message 034c65e5c7d06160 for <0.27967.9>

Jun 25 22:08:03 kz 2600hz[3012]: |034c65e5c7d06160|webhooks_object:103 (<0.27969.9>) no hooks to handle doc_edited for {account id}

Jun 25 22:08:03 kz 2600hz[3012]: |kz_couch_compactor|kz_couch_compactor:1597 (<0.1198.0>) getting db info attempt 1

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_endpoint:827 (<0.28006.9>) failed to create endpoint: call_forward_not_appropriate

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kapps_config:386 (<0.28006.9>) setting default for kazoo_endpoint [<<"sip_transport">>]: undefined

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kapps_config:386 (<0.28006.9>) setting default for kazoo_endpoint [<<"custom_sip_interface">>]: undefined

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_endpoint:178 (<0.28006.9>) no formatters defined

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_worker:441 (<0.28006.9>) attempting to collect 1 responses from ecallmgr

Jun 25 22:08:03 kz 2600hz[3012]: |57e1a9aa04790c0d|kz_amqp_channel:159 (<0.27275.1>) published to registrar(amqp://guest:guest@kz:5672) exchange (routing key registration.query.domain.user_xxx) via <0.27238.1>

Jun 25 22:08:03 kz 2600hz[3012]: |57e1a9aa04790c0d|kz_amqp_worker:614 (<0.27275.1>) published request with msg id 57e1a9aa04790c0d for <0.28006.9>

Jun 25 22:08:03 kz 2600hz[3012]: |57e1a9aa04790c0d|kz_amqp_worker:798 (<0.27275.1>) recv message 57e1a9aa04790c0d

Jun 25 22:08:03 kz 2600hz[3012]: |57e1a9aa04790c0d|kz_amqp_worker:802 (<0.27275.1>) responses have apparently met the criteria for the client, returning

Jun 25 22:08:03 kz 2600hz[3012]: |57e1a9aa04790c0d|kz_amqp_worker:803 (<0.27275.1>) response for msg id 57e1a9aa04790c0d took 2366us to return

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kapps_sms_command:127 (<0.28006.9>) sending sms and waiting for response 3c7bab56cf6087cb10b612e2605c4881

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_channel:159 (<0.27275.1>) published to sms(amqp://guest:guest@kz:5672) exchange (routing key message.route.kamailio%40kz2%2Ekz.3c7bab56cf6087cb10b612e2605c4881) via <0.27238.1>

Jun 25 22:08:03 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|kz_amqp_worker:663 (<0.27275.1>) published message 6e0b524b0d154063 for <0.28006.9>

Jun 25 22:08:04 kz 2600hz[3012]: |c9aa7276d02e9fedd77a32100ce5af10|kz_amqp_channel:159 (<0.27275.1>) published to callctl(amqp://guest:guest@kz:5672) exchange (routing key chatplan_ignored) via <0.27238.1>

Jun 25 22:08:04 kz 2600hz[3012]: |c9aa7276d02e9fedd77a32100ce5af10|kz_amqp_worker:663 (<0.27275.1>) published message 42c9d585f08cb094 for <0.25731.9>

Jun 25 22:08:04 kz 2600hz[3012]: |c9aa7276d02e9fedd77a32100ce5af10|kz_amqp_channel:95 (<0.25731.9>) release consumer <0.25731.9> channel assignment

Jun 25 22:08:04 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_assignments:893 (<0.118.0>) unregistered handlers for channel <0.22166.9>

Jun 25 22:08:04 kz 2600hz[3012]: |c9aa7276d02e9fedd77a32100ce5af10|gen_listener:724 (<0.25731.9>) doodle_exe terminated cleanly, going down

Jun 25 22:08:04 kz 2600hz[3012]: |kz_amqp_history|kz_amqp_history:301 (<0.119.0>) removing AMQP history for consumer <0.25731.9> in 2.5s: normal

Jun 25 22:08:04 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|doodle_util:270 (<0.20851.9>) trying to replay sms 201706-61f1e7df802635ae47856d490908566c for account {account id}

Jun 25 22:08:04 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_channel:105 (<0.118.0>) closed amqp channel <0.22166.9>

Jun 25 22:08:04 kz 2600hz[3012]: |kz_amqp_assignments|kz_amqp_assignments:300 (<0.118.0>) removed assignment for consumer <0.25731.9>

Jun 25 22:08:04 kz 2600hz[3012]: |3c7bab56cf6087cb10b612e2605c4881|doodle_util:280 (<0.20851.9>) replaying sms 201706-61f1e7df802635ae47856d490908566c for account {account id}

Jun 25 22:08:04 kz 2600hz[3012]: |61f1e7df802635ae47856d490908566c|doodle_route_win:62 (<0.20851.9>) error getting kz_endpoint for the sms : invalid_endpoint_id

Jun 25 22:08:04 kz 2600hz[3012]: |61f1e7df802635ae47856d490908566c|kz_amqp_channel:159 (<0.20851.9>) published to callctl(amqp://guest:guest@kz:5672) exchange (routing key chatplan_ignored) via <0.21251.2>

FS Log

-----------

2017-06-26 01:54:05.713654 [INFO] mod_sms.c:368 Processing text message 151xxxx->1844xxxx in context context_2

2017-06-26 01:54:05.713654 [DEBUG] kazoo_fetch_agent.c:216 Sending chatplan XML request (927ccf6e-5a01-11e7-9a0c-7ff39be64202) to ecallmgr@kz2 <1.19971.6>

send 610 bytes to udp/[158.xxxx]:5060 at 01:54:05.721080:

   ------------------------------------------------------------------------

   SIP/2.0 202 Accepted

   Via: SIP/2.0/UDP 158.x.x.x;branch=z9hG4bK42ac.979e06fad9da977a912e6730f6c14929.0

   Via: SIP/2.0/UDP 158.6x.x.x;received=158.6xxxx;rport=5060;branch=z9hG4bK22UH80QKFv7vS

   From: <sip:1514x...@64.xxxx>;tag=sansay1958528959rdb27188

   To: <sip:18446872640@158.6xxxx>;tag=3708H9DDm3vjB

   Call-ID: 95c64c22-5a01-11e7-a680-3fdc8336d067

   CSeq: 108881628 MESSAGE

   Contact: <sip:158.69.xxxx>

   User-Agent: CloudCalling.me

   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE

   Supported: path, replaces

   Content-Length: 0

   ------------------------------------------------------------------------

2017-06-26 01:54:05.873644 [DEBUG] kazoo_node.c:1319 Sent erlang message to ecallmgr@kz2 <1.24118.6>

2017-06-26 01:54:05.873644 [DEBUG] kazoo_node.c:1319 Sent erlang message to ecallmgr@kz2 <1.19971.6>

2017-06-26 01:54:05.893647 [DEBUG] kazoo_fetch_agent.c:277 Received chatplan XML (927ccf6e-5a01-11e7-9a0c-7ff39be64202) after 179ms: <document type="freeswitch/xml"><section name="chatplan" description="Chat Response"><context name="context_2"><extension name="chat plan" continue="false"><condition><action application="stop" data="stored"/></condition></extension></context></section></document>

Chatplan: 18446xxxx parsing [context_2->chat plan] continue=false

Chatplan: 1844...@158.x.x.x Absolute Condition [chat plan]

Chatplan: 1844...@158.x.x.x Action stop(stored)

2017-06-26 01:54:05.893647 [DEBUG] sofia_presence.c:225 Can't find registered user 1844...@158.x.x.x

send 636 bytes to udp/[158.x.x.x]:5060 at 01:54:05.895742:

   ------------------------------------------------------------------------

   MESSAGE sip:1844...@158.x.x.x SIP/2.0

   Via: SIP/2.0/UDP 158.6x.x.x;rport;branch=z9hG4bKyF7tH3SN7QUyj

   Max-Forwards: 70

   From: <sip:15145...@64.xx.x.>;tag=sansay1958528959rdb27188

   To: <sip:1844xxx@158.>

   Call-ID: 929770da-5a01-11e7-9a0d-7ff39be64202

   CSeq: 108881639 MESSAGE

   User-Agent: CloudCalling

   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE

   Supported: path, replaces

   Content-Type: text/plain

   Content-Length: 12

   X-FS-Sending-Message: d659adac-5a00-11e7-9736-7ff39be64202

   X-AUTH-IP: 158.

   X-AUTH-PORT: 5060

   new sms test

------------------------

FS version is kazoo-freeswitch-4.0-7.el7

Thanks for any insight on this!

Matt

[Sergey Safarov]

I think have same issue

https://2600hz.atlassian.net/browse/KAZOO-5572

четверг, 14 мая 2015 г., 15:11:26 UTC+3 пользователь Alan Evans написал:

[VCCS Portal]

Ah ok! Thank's for the heads up, I will keep my eye on the bug...

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/Po0DvPbWxdI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+unsubscribe@googlegroups.com.