[Freeswitch-dev] Chat Dialplan

[Steven Ayre]

>
> 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!
>

There's an interface so a module can register a dialplan handler.
mod_dialplan_xml provides the one most commonly used. Endpoint modules like
Sofia don't have a anything to do with the dialplan interface, that's the
job of another module. Other modules that implement dialplan handlers
include mod_dialplan_asterisk, mod_dialplan_directory, mod_yaml, mod_lua,
mod_enum, mod_osp, mod_lcr. Most people just use the XML one though. The
"XML" you often see in documentation for things like transfer actually is
you specifying you want to use the mod_dialplan_xml one. The other modules
use different dialplan names such as asterisk, directory, lua, lcr etc.

-Steve



On 6 July 2011 03:31, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20110706/ed484798/attachment-0001.html