[Freeswitch-dev] Chat Dialplan

[Steven Ayre]

You can also write a module to load in FS that can listen to the same
events, so programmatically may be able to handle them within FS there.

-Steve


2011/7/6 João Mesquita <jmesquita at freeswitch.org>

> I believe that these messages show up as events on ESL, don't they?
> Therefore you can do whatever from there...
>
> Regards,
> João Mesquita
>
>
>
>
> On Tue, Jul 5, 2011 at 11:31 PM, Kurtis Heimerl <kheimerl at cs.berkeley.edu>wrote:
>
>> I forgot to disable digest mode, and so I have 5 emails to respond to
>> in 2 received mails. Instead, I'm going to address the highlights
>> here:
>>
>> Steven Ayre <steveayre at gmail.com> said:
>> "Have you thought of making it a patch to add a new API interface so
>> that modules can register chat dialplans, similar to how
>> mod_dialplan_xml works?
>>
>> -Steve"
>>
>> I don't quite understand what you're saying here. Individual modules
>> (e.g., Sofia) would register a different dialplan? Is that how it
>> currently works? I thought, if they selected an XML dialplan in the
>> conf, they all used the same one. I'm obviously confused, so please
>> explain in more depth!
>>
>> "Abdul Hakeem" <alhakeem at gmail.com> said:
>> "Kurtis,
>> Which protocol will this chat/sms dialplan be compliant with ?.
>> Sip MESSAGE method , SIMPLE and XMPP are both widely adopted.
>> It would be great to add support for connectivity to external domains such
>> as
>> Gtalk, Yahoo Messenger etc.
>> Cheers,
>> AH"
>>
>> So far as my current architectural vision, any module implementing a
>> MESSAGE event should be able to trigger a dialplan action. My plan is
>> to start with Sofia, so it would support SIMPLE. Others should be
>> pretty easy as well.
>>
>> Lastly,
>> Anthony Minessale <anthony.minessale at gmail.com> said:
>> "This sounds redundant and intrusive.
>> We already have a concept of namespace within the chat username which
>> is used for routing.
>>
>> we prefix the namespace into the user id such as conf+1234 at domain.com
>> This allows conference to get messages from sip, xmpp or any other
>> protocol that supports chat.
>>
>> When a from user on chat contains +:
>>
>> each module just parses the inbound chat message, cuts off the proto
>> "everything up to the first +" in this case conf
>> and routes it to the module registered to that namespace.
>>
>> Right now conference will advertise it's presence and receive chat of
>> the word list and respond with the list despite the protocol used, eg
>> sip, jabber etc.
>>
>> Also chat messages are routed to individual calls when they are
>> associated with an active channel allowing you to use chat inside IVR.
>>
>> I recommend trying to understand all of this before proposing drastic
>> changes that will regress all of this functionality."
>>
>> I need a programmatic layer for routing messages. What's currently in
>> FS is (seemingly) unable to do this. I'm aware that the current system
>> routes messages to users correctly; I don't think it enables any sort
>> of interesting programmatic access. For instance, building a system
>> that receives a message and immediately starts a call is not something
>> I think can be currently done. The dialplan abstraction is
>> well-understood by FS users, and an extension I think could provide a
>> lot of value.
>>
>> I don't think these changes will regress any functionality either. I
>> proposed adding a configuration flag that switched between behaviors,
>> so that existing functionality won't be modified. Lastly, sending this
>> email was part of me trying to understand the current system. Thanks
>> for the direction.
>>
>> If I'm wrong, and there's a simple way to provide programmatic access,
>> I'd love to hear about it. That's a lot less work for me!
>>
>> On Sun, Jul 3, 2011 at 4:49 PM, Kurtis Heimerl <kheimerl at cs.berkeley.edu>
>> wrote:
>> > Hello Freeswitch-dev!
>> >
>> > I've recently begin modifying Sofia to support a chat "dialplan", very
>> > similar to the voice dialplan. Basically, a chat/sms will come in at a
>> > certain number/address and be routed via the dialplan. My current plan
>> > for doing this is as follows:
>> >
>> > 1) Add message events to sofia: I want sofia (and eventually all chat
>> > clients) to send message events through FS's event framework when an
>> > event arrives.
>> > 2) Remove message routing from Sofia: Sofia should not be routing
>> > messages itself. Instead, it should just generate the event saying a
>> > message has arrived and someone else should do the routing (namely my
>> > dialplan)
>> > 3) Implement a simple chat dialplan module that listens for message
>> > events and routes them according to an XML dialplan.
>> >
>> > I have some questions for the FS developer community.
>> >
>> > First, building my own module is conceptually simple. Modifying Sofia
>> > is not. What's the best way to go about making these changes? I could
>> > submit extension tickets (e.g., a configuration variable that adds
>> > messages and one that removes routing), or submit patches, or both. I
>> > think this could be broadly useful, and I want to try to contribute to
>> > the community.
>> >
>> > Secondly,  I'm having a little difficulty finding the place where
>> > messages are routed in sofia. That's probably the place to insert both
>> > 1 & 2. Any pointers would be appreciated.
>> >
>> > Thanks!
>> >
>>
>> _______________________________________________
>> Join us at ClueCon 2011, Aug 9-11, Chicago
>> http://www.cluecon.com 877-7-4ACLUE
>>
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>
>
> _______________________________________________
> Join us at ClueCon 2011, Aug 9-11, Chicago
> http://www.cluecon.com 877-7-4ACLUE
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20110706/ab6a17d9/attachment-0001.html