So I've been all over the place looking at various examples, threads, issues, and solutions to all sorts of forking scenarios. What I haven't been able to find is a solution to my odd corner case. Let me explain the forking scenario:
Call comes in for user A: - Use avp_db_load to find that user A wants to parallel fork to 123 and 456 - Call to 123 fails because there's no registration - Call to 456 times out
== At this point we serial fork to the next step which might hbe - Just call my cell
What's unclear to me is how to actually achieve this logic. I mean, getting the initial parallel fork is quite simple using avp_pushto.
What's unclear is how to setup the failure route to know that you can ignore a failure in any of the forks until the last fork as failed, and then it's time to move on.
Something like, "are there other branches pending?" would be a nice check to determine if the failure route should just drop or if it should append a branch (or two) for the next serial fork.
Comments? Ideas? Thoughts? Am I totally insane? Should I be using a specific module for this?
--Chris Heiser
Chris Heiser writes:
Call comes in for user A:
- Use avp_db_load to find that user A wants to parallel fork to 123 and 456
- Call to 123 fails because there's no registration
- Call to 456 times out
== At this point we serial fork to the next step which might hbe - Just call my cell
What's unclear to me is how to actually achieve this logic. I mean, getting the initial parallel fork is quite simple using avp_pushto.
you can add permanent registrations for the aor of the user pointing to 123, 456 and your mobile number. just make sure that q value of the mobile is lower that q value of 123 and 456.
Comments? Ideas? Thoughts? Am I totally insane? Should I be using a specific module for this?
you should be able to accomplish the above this using lcr modules's load_contacts()/next_contacts() functions.
-- juha
On Fri, 2 Nov 2007, Juha Heinanen wrote:
Chris Heiser writes:
Call comes in for user A:
- Use avp_db_load to find that user A wants to parallel fork to 123 and 456
- Call to 123 fails because there's no registration
- Call to 456 times out
== At this point we serial fork to the next step which might hbe - Just call my cell
What's unclear to me is how to actually achieve this logic. I mean, getting the initial parallel fork is quite simple using avp_pushto.
you can add permanent registrations for the aor of the user pointing to 123, 456 and your mobile number. just make sure that q value of the mobile is lower that q value of 123 and 456.
if 123 and 456 are registered endpoints, how do I influence their q value?
And lets complicate things more, what if I wanted to call 123 first, then my cell, then 123 again?
Would I solve all this by adding permanent registrations that point back to OpenSER for registered endpoints, etc...? So a user would have a bunch of permanent registrations with decreasing q values that point into OpenSER, PSTN gateway, Voicemail, etc...?
Comments? Ideas? Thoughts? Am I totally insane? Should I be using a specific module for this?
you should be able to accomplish the above this using lcr modules's load_contacts()/next_contacts() functions.
-- juha
And let me throw one more wrench into the mix:
On Fri, 2 Nov 2007, Chris Heiser wrote:
On Fri, 2 Nov 2007, Juha Heinanen wrote:
Chris Heiser writes:
Call comes in for user A:
- Use avp_db_load to find that user A wants to parallel fork to 123 and 456
- Call to 123 fails because there's no registration
- Call to 456 times out
== At this point we serial fork to the next step which might hbe - Just call my cell
What's unclear to me is how to actually achieve this logic. I mean, getting the initial parallel fork is quite simple using avp_pushto.
you can add permanent registrations for the aor of the user pointing to 123, 456 and your mobile number. just make sure that q value of the mobile is lower that q value of 123 and 456.
if 123 and 456 are registered endpoints, how do I influence their q value?
And lets complicate things more, what if I wanted to call 123 first, then my cell, then 123 again?
Would I solve all this by adding permanent registrations that point back to OpenSER for registered endpoints, etc...? So a user would have a bunch of permanent registrations with decreasing q values that point into OpenSER, PSTN gateway, Voicemail, etc...?
What if I want to adjust the timers for each step based on some users' preference? I could see doing something ugly and overloaded like:
Add contacts with USER-TIMEOUT as permanent subscriptions, add a t_on_branch, and in the branch, rewrite the RURI to remove the timeout and set the invite timer properly. I don't even know if that will work nicely.
If I knew the Q value before t_relay, I could have avps assigned per q value to set the timeout dynamically.
Comments? Ideas? Thoughts? Am I totally insane? Should I be using a specific module for this?
you should be able to accomplish the above this using lcr modules's load_contacts()/next_contacts() functions.
-- juha
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Chris Heiser writes:
if 123 and 456 are registered endpoints, how do I influence their q value?
it may be possible for the user to configure their q value. if not, set default q value to be for example 0.5.
And lets complicate things more, what if I wanted to call 123 first, then my cell, then 123 again?
your first 123 would use its registered q value, cell would have permanent registration with higher q value and then you would add second permanent registration for 123 with still higher q value. that would cause the whole thing to start again though.
but it is not a good idea to have a long chain without actually answering the phone because the caller's phone or openser may timeout the transaction. for longer chains you need to use a call center style application that you can implement, for example, using sems.
Would I solve all this by adding permanent registrations that point back to OpenSER for registered endpoints, etc...? So a user would have a bunch of permanent registrations with decreasing q values that point into OpenSER, PSTN gateway, Voicemail, etc...?
that is a possibility.
-- juha
Chris Heiser wrote:
So I've been all over the place looking at various examples, threads, issues, and solutions to all sorts of forking scenarios. What I haven't been able to find is a solution to my odd corner case. Let me explain the forking scenario:
Call comes in for user A:
- Use avp_db_load to find that user A wants to parallel fork to 123 and 456
- Call to 123 fails because there's no registration
- Call to 456 times out
== At this point we serial fork to the next step which might hbe - Just call my cell
What's unclear to me is how to actually achieve this logic. I mean, getting the initial parallel fork is quite simple using avp_pushto.
What's unclear is how to setup the failure route to know that you can ignore a failure in any of the forks until the last fork as failed, and then it's time to move on.
Something like, "are there other branches pending?" would be a nice check to determine if the failure route should just drop or if it should append a branch (or two) for the next serial fork.
Comments? Ideas? Thoughts? Am I totally insane? Should I be using a specific module for this?
What about CPL? I don't play with it in OpenSER but scenario like this can be described on CPL.
Yeah, I've been taking a hard look at CPL. I did some fun fancy things with permanent registrations in openser, and avps, but that's all so terribly messy. I think a final solution will be something like:
Add some permanent registrations to openser to handle some parallel fork cases. Everything else could be handled by CPL.
The other nice thing about CPL is I can explicitly upload cpl files for specific users and not do a ton of lookups for avps, etc...
--Chris
On Thu, 8 Nov 2007, Victor Gamov wrote:
What about CPL? I don't play with it in OpenSER but scenario like this can be described on CPL.
-- CU, Victor Gamov
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Chris Heiser wrote:
Yeah, I've been taking a hard look at CPL. I did some fun fancy things with permanent registrations in openser, and avps, but that's all so terribly messy. I think a final solution will be something like:
Add some permanent registrations to openser to handle some parallel fork cases. Everything else could be handled by CPL.
The other nice thing about CPL is I can explicitly upload cpl files for specific users and not do a ton of lookups for avps, etc...
You can avoid most of the "mess" if you don't do sequential forwarding, which is what we are doing at UNC. Our analysis has shown that you can cover 95% of all "follow-me" user needs with parallel forking.
The upcoming 1.3 version of openser will include a module called H350 which allows you to store simple call preferences in LDAP (http://www.openser.org/docs/modules/1.3.x/h350.html#AEN186) which offers better performance than CPL and still gives you all the routing script flexibility. Not messy at all, isn't it ;-)
The only situation where you really need sequential forking is for call center applications, and for that you also need some sort of IVR/MoH in order to inform the caller about the long ringing time. So I think it is best to implement this with a b2bua type SIP PBX like asterisk instead of trying to implement it the pure p2p SIP way.
just my 2c
/Christian
--Chris
On Thu, 8 Nov 2007, Victor Gamov wrote:
What about CPL? I don't play with it in OpenSER but scenario like this can be described on CPL.
-- CU, Victor Gamov
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Thu, 8 Nov 2007, Christian Schlatter wrote:
Chris Heiser wrote:
Yeah, I've been taking a hard look at CPL. I did some fun fancy things with permanent registrations in openser, and avps, but that's all so terribly messy. I think a final solution will be something like:
Add some permanent registrations to openser to handle some parallel fork cases. Everything else could be handled by CPL.
The other nice thing about CPL is I can explicitly upload cpl files for specific users and not do a ton of lookups for avps, etc...
You can avoid most of the "mess" if you don't do sequential forwarding, which is what we are doing at UNC. Our analysis has shown that you can cover 95% of all "follow-me" user needs with parallel forking.
The upcoming 1.3 version of openser will include a module called H350 which allows you to store simple call preferences in LDAP (http://www.openser.org/docs/modules/1.3.x/h350.html#AEN186) which offers better performance than CPL and still gives you all the routing script flexibility. Not messy at all, isn't it ;-)
Interesting. What's bothering me is your /g with AVPs to get parallel forking. My experience has been that performing parallel forking using that method results in the failure route getting hit when any branch of the fork fails, whereas if I have a permanent registration in OpenSER with multiple entries, it seems like my failure route doesn't get called until they all fail.
(Can you tell that this has driven me nuts for a while now?)
--Chris
The only situation where you really need sequential forking is for call center applications, and for that you also need some sort of IVR/MoH in order to inform the caller about the long ringing time. So I think it is best to implement this with a b2bua type SIP PBX like asterisk instead of trying to implement it the pure p2p SIP way.
Sure, I'm walking a fine line, but I think there's a place for small chains of sequential forking. The uglier stuff comes in when you want to add conditionals to the process. It seems like CPL could let me do some of that (or I'll have to write a module that lets you query arbitrary external data). Think of something simple like "Time of Day" preferences.
--Chris
just my 2c
/Christian
--Chris
On Thu, 8 Nov 2007, Victor Gamov wrote:
What about CPL? I don't play with it in OpenSER but scenario like this can be described on CPL.
-- CU, Victor Gamov
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Chris Heiser wrote: ...
The upcoming 1.3 version of openser will include a module called H350 which allows you to store simple call preferences in LDAP (http://www.openser.org/docs/modules/1.3.x/h350.html#AEN186) which offers better performance than CPL and still gives you all the routing script flexibility. Not messy at all, isn't it ;-)
Interesting. What's bothering me is your /g with AVPs to get parallel forking. My experience has been that performing parallel forking using that method results in the failure route getting hit when any branch of the fork fails, whereas if I have a permanent registration in OpenSER with multiple entries, it seems like my failure route doesn't get called until they all fail.
I don't think there is a difference between adding branches with /g AVPs or having multiple (permanent) registrations. Internally, both methods are calling the append_branch() function, so the result should be exactly the same.
The final response sent back upstream depends on what is received in the branches. How this works is described in RFC 3261 section 16.7 (http://tools.ietf.org/html/rfc3261#section-16.7), in particular points "5. Check response for forwarding" and "6. Choosing the best response".
In a nutshell, 1xx and 2xx responses received from downstream are forwarded immediately, while all other responses are collected at the proxy. After all forks have terminated or timed out, the proxy has to choose the "best" response to send back upstream. The 6xx response is a bit special because it doesn't get forwarded immediately but tells the proxy to cancel all ongoing forked transactions. Some phones do generate a 6xx when declining an incoming call which has the effect that the call gets e.g. immediately sent to voicemail (if configured so in failure_route).
The only situation where you really need sequential forking is for call center applications, and for that you also need some sort of IVR/MoH in order to inform the caller about the long ringing time. So I think it is best to implement this with a b2bua type SIP PBX like asterisk instead of trying to implement it the pure p2p SIP way.
Sure, I'm walking a fine line, but I think there's a place for small chains of sequential forking. The uglier stuff comes in when you want to add conditionals to the process. It seems like CPL could let me do some of that (or I'll have to write a module that lets you query arbitrary external data). Think of something simple like "Time of Day" preferences.
Yes, time of day routing has to be implemented manually in the routing script if you don't use CPL. But you don't have to write a module to do so. You could e.g. store the time-of-day call preferences in a SQL DB, in LDAP, or even in Radius server, and use one of the generic query-to-AVP script functions from the respective openser module.
/Christian
--Chris
just my 2c
/Christian
--Chris
On Thu, 8 Nov 2007, Victor Gamov wrote:
What about CPL? I don't play with it in OpenSER but scenario like this can be described on CPL.
-- CU, Victor Gamov
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Chris Heiser -
Christian Schlatter -
jh＠tutpro.com -
Victor Gamov