[OpenSIPS-Users] Parking a Call using b2b modules

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Jun 18 15:58:39 CEST 2014


Jayesh,

Using the t_was_cancelled() function in failure route will tell you if 
the CANCEL was local or received from the caller side:
http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295325

The call_center module is designed to reject calls if there is no agent 
logged in. Even if we change that, to be sure the right call is 
distributed to right agent, you will end up creating one flow/queue per 
user, which is not really scalable.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 18.06.2014 14:02, Jayesh Nambiar wrote:
> Hi Bogdan,
> Thanks for your response. I get your idea of sending the call to an 
> unexisting destination which might work in my case. Would the failure 
> route have a way to distinguish between the CANCEL generated by the 
> script and the caller itself, such that I might not end up trying to 
> route a call to the callee, when the caller has Cancelled it !!
>
> Another hypothetical question which may or may not be related:
> I see a new callcenter module which queues the caller till the call is 
> answered by an Agent with registered endpoint. Can't the callcenter 
> module queue a call, if there are no agents logged in?? Because if it 
> can, it looks similar to the problem I mentioned, which waits for the 
> agent to be registered and route the call as soon as the user 
> registers (logs in as an agent).
>
> Just a thought for figuring out a neater solution to my problem. 
> Thanks for all your suggestions.
>
> --- Jayesh
>
>
>
>
>
>
> On Wed, Jun 18, 2014 at 2:51 PM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Jayesh,
>
>     I see your point - if you do not want to send media to the caller
>     (while in park), when you decide to park the call you can simply
>     send back an 180 ringing and then relay to call to a fake
>     unexisting destination with timeout == "how long to keep the call
>     in parking". That branch will timeout (as there is no UAS) and
>     return to failure route (if not picked up in the mean while). if
>     the target user registers in the mean while, you do the cancel
>     stuff as initially described.
>
>     Once again, the b2b is not useful here - why? as there you your
>     handling is at transaction level (call is not accepted, you play
>     with multiple branches) and not at call level (handling 1 or more
>     accepted calls)
>
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>     On 18.06.2014 08:42, Jayesh Nambiar wrote:
>>     Hi Bogdan,
>>     Thanks for the reply. But the challenge with me is that I don't
>>     want to use an additional component like a Media Server in this
>>     setup. The idea is to get away with too many components which can
>>     act like point of failures. Hence I was exploring the idea of
>>     parking the call in Opensips itself and do the routing within
>>     Opensips without the need of an external media server.
>>     Any possibility of this being done within opensips?? And the only
>>     option that I can see for this is the b2b modules.
>>
>>     --- Jayesh
>>
>>
>>     On Tue, Jun 17, 2014 at 8:44 PM, Bogdan-Andrei Iancu
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>>         Hi Jayesh,
>>
>>         For such scenario you do not need b2b at all. You can do it
>>         at signaling level. How ?
>>         - determine that the incoming call needs to be parked
>>         - send the call to a media server to play some ringing via
>>         183 early media (call still not accepted); also push DB
>>         record to with the callid + user the call belongs to;
>>         - if target user registers -> check in DB for parked calls ->
>>         if yes, run a script to trigger the cancelling of that branch
>>         to media server (see t_uac_cancel MI command
>>         http://www.opensips.org/html/docs/modules/1.11.x/tm.html#id295912)
>>
>>         - original call will go into failure route (because of the
>>         canceling) -> from there you can create a new branch to the
>>         newly registered user.
>>
>>         I haven't tried, but it should work :)
>>
>>         Regards,
>>
>>         Bogdan-Andrei Iancu
>>         OpenSIPS Founder and Developer
>>         http://www.opensips-solutions.com
>>
>>         On 17.06.2014 12:57, Jayesh Nambiar wrote:
>>>         Hello All,
>>>         I was trying to explore an option of parking a call on
>>>         opensips using b2b modules with a trying or ringing
>>>         response. More precisely, I was trying to do something like
>>>         this:
>>>         http://lists.opensips.org/pipermail/users/2010-October/014849.html
>>>
>>>         As soon as the call comes in, use b2b_logic to park the
>>>         call. If the called user is registered, route the call; else
>>>         keep the caller parked for 45 seconds, and within this
>>>         duration if the called user registers, raise a E_REGISTERED
>>>         event.
>>>         Identify if there is a call parked for the user that just
>>>         registered and if yes route the call or else respond with
>>>         408 timeout to the caller.
>>>         I thought, it should be possible using the b2b modules and
>>>         the event interface that opensips got. Am I thinking in the
>>>         right direction from possibility perspective?? Can someone
>>>         help me understand if this logic can be implemented within
>>>         the script??
>>>
>>>         Thanks in advance,
>>>
>>>         --- Jayesh
>>>
>>>
>>>         _______________________________________________
>>>         Users mailing list
>>>         Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140618/65e69292/attachment-0001.htm>


More information about the Users mailing list