you could try using a FS api call in your originate that uses mod_http to
hit your routing logic.

The other way is just not elegant at all and there is no way I can see to do
it.


On Tue, Jul 28, 2009 at 3:29 AM, Tamas Cseke <[email protected]>wrote:

> Hello,
>
> Thank you for your effort about this issue.
> Our problem is that searching this routing data from database is quiet
> painful.
> Let me explain. we have manual calls from softphones and automatically
> originated calls pushed into fifo.
>
> We have a quiet complicate routing logic setting certain variables (sip
> headers, caller id number etc...),  select routes according to prefix,
> time matching and so on.
> For manual calls we only could accomplish these  routing in dialplan.
> (we store the data in database  but we generate  xml dialplans from them).
> For automatic calls  if  we can't use the dialplan we have to implement
> this routing again (in C module). and every time when a manager or
> customer would like a new  feature (eg. add
> different sip headers for calls for different projects) we have to
> implement it twice.
>
> I tried to make a patch to do a dialplan hunt before the real invite for
> outgoing channels, but it's not very elegant...
> We were thinking about to make a new endpoint module, but  the problem
> is that outgoing channel routine create the session, that we need for
> dialplan hunting, so I can't do it totally independent
> Could you please advise me a way to do it elegant, or is it a very bad
> idea?
>
> Here is the patch.
> svn diff -r 14390:14396
>
> http://svn.freeswitch.org/svn/freeswitch/branches/cseket/src/mod/endpoints/mod_sofia
>
> Thanks in advance,
> Tamas
>
> Anthony Minessale írta:
> > yah, I looked into that and it's not possible to do.
> >
> > Your usage of the dialplan like a database is just not a good way to do
> it.
> > I suggest you use a database or something else to store that routing data
> > like others do.
> >
> >
> >
> > On Wed, Jul 22, 2009 at 10:55 AM, Tamas Cseke <[email protected]
> >wrote:
> >
> >
> >> Hello,
> >>
> >> we are using mod_loopback for outbound calls to be able to do a dialplan
> >> hunt before the actual call origination.
> >> change caller number, change routing according to the prefix and
> >> something like that.
> >> We have talked about a lot, that this is "not very" efficient  because
> >> we have 2 extra channels (loopbacks) for every call.
> >>
> >> I diged into the state machine code and figured out that if I change the
> >> on_routing state handler functions for switch_ivr_originate to don't
> >> veto the standard behavior I can perform a dilplan hunt.
> >> But I still have to originate a channel which makes a dialplan hunt and
> >> originate another. and this isn't what we really would like to...
> >>
> >> I've got the following tip from Anthony earlier:
> >> 0416 16:39:28 <@anthm> maybe i could make an api command to pretend to
> >> do a dialplan run and print out a list in inline format of what to do
> >> 0416 16:39:48 <@anthm> that you could feed to originate inline dialplan
> >>
> >> But I don't know how to implement this. I need some explanation.
> >>
> >> 1) the dialplan pretender api returns applications in inline format
> >> 2) we feed it to inline dialplan
> >> but how could we originate the call, how should the whole process look
> >> like?
> >> could you please give me an example?
> >>
> >> I was thinking about someting like this, but it doesn't make sense I
> quess.
> >> ${originate(call_url inline ${pretend_dialplan_hunt(exten XML
> context)})}
> >>
> >> Thanks in advance,
> >> Tamas
> >>
> >>
> >>
> >> _______________________________________________
> >> FreeSWITCH-dev mailing list
> >> [email protected]
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> >> http://www.freeswitch.org
> >>
> >>
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > FreeSWITCH-dev mailing list
> > [email protected]
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
> >
>
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> [email protected]
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:[email protected] <msn%[email protected]>
GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:[email protected] <sip%[email protected]>
iax:[email protected]/888
googletalk:[email protected]<googletalk%3aconf%[email protected]>
pstn:213-799-1400
_______________________________________________
FreeSWITCH-dev mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

Reply via email to