[Serusers] SER / MediaProxy / B2BUA

[Greger V. Teigre]

Just to expand a bit on the last messages (a good thread, BTW :-)
- A full B2BUA will be in both the signalling AND the RTP path. 
Mediaproxy is only in the RTP path
- FYI: The new codebase for SEMS is a full B2BUA
- Pre-paid handling and terminating a call can basically be done in 
three ways: The way described in this thread (using an external agent 
that generates a "fake" BYE), a full B2BUA (often a session border 
controller) that keeps both signalling and media and thus can internally 
generate a BYE at will, and using the Session-Timer header (must be 
supported by at least one party, i.e. the gateway) where a reINVITE is 
done every x interval and the call can thus be terminated
- A fourth way has been explored by several people, but I'm not aware of 
any implementations: SER can be made dialog-aware fairly simple and a 
new timer module in CVS head can be used to review ongoing dialogs and 
generate a BYE (the module can generate a BYE using the internal uac 
functionality; also available from FIFO)
- A fifth way would be to implement a signalling-only B2BUA in ex. SEMS 
(and thus avoid the dependency on media going through a central server). 
You would have to have mediaproxy/rtpproxy in addition, and you wouldn't 
be able to detect UAs that suddenly disappear from the call (i.e. no 
RTP) unless you proxy. However, you would be able to terminate the call 
based on credit.

- To Ryan: If you find you want to remove the depedency on sipsak, you 
may want to look at the FIFO uac functionality. There is a ctd.sh script 
in the examples dir that shows how to use it.

g-)

Ryan Pagquil wrote:
> Hi Daniel,
>         Our setup is like what you have. We have SER /Mediaproxy, for 
> the missing BYE's mediaproxy 1.7.2 do the job and to terminate calls 
> we have a perl script that checks the radacct with  zero 
> acctsessiontime and acctstoptime entries then compare it to the 
> current credit of the username and if insufficient the script sends a 
> BYE to both ends where the information came from radacct entry. The 
> perl script uses sipsak to generate BYE message.
>
> Regards,
> Ryan
>
> At 07:31 AM 7/5/2006, Daniel Salama wrote:
>> Thank you for the prompt response and the explanation.
>>
>> Currently, I don't have any code in place. However, I was trying to
>> simplify the whole architecture. I have a SER box talking to Radius
>> for authentication and accounting. I'm also using Mediaproxy as a NAT
>> helper. Then, I have Asterisk for IVR auto attendant and voicemail.
>> Since Mediaproxy is going to be in the media path anyhow to help in
>> NAT, I just don't want to have another Asterisk server in the media
>> path just for the Dial command with the timeout.
>>
>> What would be an elegant alternative? I know that in the ISP dial-up
>> world, Radius is more than capable of specifying max session time.
>> Wouldn't SER/Mediaproxy "understand" the Radius attribute for max
>> session time? I know SER doesn't stay in the media path but by being
>> statefull, it can "listen" to all messages between the end points,
>> including BYE. So, why couldn't SER/Mediaproxy "insert" a BYE message
>> somewhere? Maybe it could be a simple as writing a simple external
>> process that constantly monitors sessions time and "inserts" the BYE
>> message using SER's fifo, in a similar way that serctl talks to SER.
>>
>> Thanks,
>> Daniel
>>
>> On Jul 4, 2006, at 5:03 PM, sip wrote:
>>
>>> All Asterisk B2BUA does, really (I'm referring to the script, not
>>> the Asterisk
>>> patch itself), is authenticate a call coming in, and then lookup in
>>> radius
>>> what the session timeout for that call should be. It then creates
>>> an Asterisk
>>> dial string and sets the call timeout to be X number of seconds
>>> based on the
>>> session-timer attribute in radius.
>>>
>>> If media proxy allows you to set session timers on the fly or has
>>> some sort of
>>> polling system (I don't know, I've never used it), allowing you to
>>> terminate a
>>> call after a certain period of time, then no, you wouldn't need
>>> Asterisk B2BUA.
>>>
>>> We actually ended up only partly using Asterisk B2BUA for our
>>> stuff, because
>>> it didn't quite do everything we wanted (it's really only a B2BUA
>>> and it
>>> relies rather heavily on some odd conventions in radius for
>>> authentication
>>> without a password (not really authentication)), so we coded our
>>> own setup
>>> which keeps track of session timeouts and call costs and the like
>>> and then
>>> uses the Asterisk B2BUA framework to create the Asterisk dial
>>> string.  At this
>>> point, there's no real reason we couldn't replace the whole thing
>>> with our own
>>> code (it became 95% ours in the process, but the process would have
>>> gone
>>> NOwhere without the original code to set us in the right
>>> direction). If you're
>>> in a similar situation with mediaproxy, and it allows session
>>> timers of some
>>> sort, there's no real reason to NOT use your own setup.
>>>
>>> N.
>>>
>>>
>>> On Tue, 4 Jul 2006 16:51:12 -0400, Daniel Salama wrote
>>>> After reading this forum:
>>>>
>>>> http://www.voipuser.org/forum_topic_4468.html
>>>>
>>>> it made me wonder, whether or not you really need B2BUA if you
>>>> already have Mediaproxy in your environment. I know the purpose of
>>>> Mediaproxy is to help with NAT situations. However, given the fact
>>>> that Mediaproxy is always in the media path, couldn't it be ALSO
>>>> used  to "terminate" a call in progress, the same way that B2BUA
>>>> can? And  by B2BUA I refer to the Asterisk B2BUA, all within the
>>>> context of  prepaid type services.
>>>>
>>>> Any comments?
>>>>
>>>> Thanks,
>>>> Daniel
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> Serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>