Hello,
I want to achieve the following schema:
1. Accept an initial invite 2. Create separate dialog to different SIP server (probably with some headers from point 1) 3. Wait until that different SIP server will complete dialog. 4. Based on result of point 3, transfer invite from 1 to the next steps or decline a call. The problem I've experienced - how to create a separate dialog and control it inside main dialog?
Thanks a lot!
Hello,
On 12/12/14 06:08, Konstantin M. wrote:
Hello,
I want to achieve the following schema:
- Accept an initial invite
what do you mean by 'acccept' here, send a 200ok or a 100trying and hold the INVITE in memory for a while?
If second, then see tmx module for t_suspend()/t_continue().
- Create separate dialog to different SIP server (probably with some
headers from point 1) 3. Wait until that different SIP server will complete dialog. 4. Based on result of point 3, transfer invite from 1 to the next steps or decline a call. The problem I've experienced - how to create a separate dialog and control it inside main dialog?
Uac is the module to generate new requests, you can handle the reply to it via reply_route and decide there what to do with parked INVITE.
If possible, I would use a different request (or even protocol, see evapi or jsonrpc-c modules) than invite instead of that new dialog. For example OPTIONS -- let's say you want to check if the initial caller is allowed to call, you can send the requests to a billing engine that gives the yes/no.
Depending on the scenario, might be easier to go and code in C a module -- look at async, evapi, jsonrpc-c for examples on how to suspend and resume transactions from inside a module.
Cheers, Daniel
Hello Daniel,
2014-12-12 12:01 GMT+03:00 Daniel-Constantin Mierla miconda@gmail.com:
what do you mean by 'acccept' here, send a 200ok or a 100trying and hold the INVITE in memory for a while?
Well, yes. Desired scenario is send '100 trying' and hold the current invite, then communicate to separate SIP server and then resume a transaction.
If second, then see tmx module for t_suspend()/t_continue().
Thank you for pointing to.
Uac is the module to generate new requests, you can handle the reply to it via reply_route and decide there what to do with parked INVITE.
I know but for some reasons, I'm unable to costruct a new clear invite and manage it.
If possible, I would use a different request (or even protocol, see evapi or jsonrpc-c modules) than invite instead of that new dialog. For example OPTIONS -- let's say you want to check if the initial caller is allowed to call, you can send the requests to a billing engine that gives the yes/no.
Depending on the scenario, might be easier to go and code in C a module -- look at async, evapi, jsonrpc-c for examples on how to suspend and resume transactions from inside a module.
I was thinking about to this solution after trying all of possible ways without writting a new module. Ok, will try to workaround this by some embedded language execution, then work on this module if so...
Cheers, Daniel
Thanks!
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Konstantin M.