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