2 Nov
2007
2 Nov
'07
2:27 p.m.
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
2 Nov
2 Nov
2:46 p.m.
New subject: [OpenSER-Users] Forking Madness
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
4:22 p.m.
On Fri, 2 Nov 2007, Juha Heinanen wrote:
Chris Heiser writes:
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...?
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
5:30 p.m.
And let me throw one more wrench into the mix:
On Fri, 2 Nov 2007, Chris Heiser wrote:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Fri, 2 Nov 2007, Juha Heinanen wrote:
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.
Chris Heiser writes:
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...? 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
3 Nov
3 Nov
2:38 a.m.
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
7 Nov
7 Nov
4:23 p.m.
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.
--
CU,
Victor Gamov
6:02 p.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
8 Nov
8 Nov
9:52 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
2:10 p.m.
On Thu, 8 Nov 2007, Christian Schlatter wrote:
Chris Heiser wrote:
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
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.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:37 p.m.
Chris Heiser wrote:
...
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).
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
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. 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(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
>
6160
days inactive
6167
days old
9 comments
4 participants
participants (4)
-
Chris Heiser -
Christian Schlatter -
jh＠tutpro.com -
Victor Gamov