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