[Serusers] [RFC] ideas about new dialog module

Jiri Kuthan jiri at iptel.org
Mon Jan 20 15:04:07 CET 2003


Maxim,

I think that's a good plan.

Well -- I'm hearing to embarassement of folks to whom I promised we will
never ever even think of b2bua. Let me explain.

I think, that architecturally, the concept of B2BUA is a departure from
Internet's end-2-end model. As some other lessons like NAT show, that
may have very inconvenient consequences in course of the time, even
such we do not predict now (like single point of failure and scalability
issues). 

One can achieve complex services without any such B2BUA with a more 
distributed design -- end-devices just need to be smart enough and
participate in service composition. For example, session-related policy
like maximum call duration and keeping firewalls open can be achieved
using session-timer. Multi-phase conversation with multiple components
may be implemented using call transfer (anouncement component hands over
to PIN-collecting component which hands over to gateway, etc.) I hope
I will be able to give some more details in a memo I'm writing,
Rohan Mahy's cc-framework Internet draft spells some issues very well.

The problem is that many available components (like PSTN gateways) are
quite dumb and do not implement all needed pieces yet. For example, 
a gateway is not able to transfer to an anouncemnt server ("call has 
een cut-off, give me your credit card number") when a session timer hits. 
To utilize such components for service composition, B2BUA is the only way 
to move forward.

Jan is right, that there are some issues with ser -- we want to keep it
reasonably compact and performance has not been optimized for maintenance
of call state. However, as long as the B2BUA is kept in a separate module 
tied to TM via callbacks, it will be still useful, whereas users wishing 
to use compact ser are no way forced to use it.

Just ask us if you need any guidance on TM or whatever.

-Jiri

At 10:37 PM 1/16/2003, Maxim Sobolev wrote:
>Hi,
>
>I am thinking about writing a new module for SER, which will track SIP
>dialogs and will serve as an abstraction layer for other modules, much
>like the tm module now. We need such module for 2 reasons:
>
>1. Call accounting. Our billing engine is based on the assumption that
>a node provides accounting information for completed calls, not for
>individual transactions. It is easier for us to extend proxy with
>similar features than to modify billing engine to do transaction
>matching.
>
>2. Debit card application. Currently, there is no way to use SER for
>debit card applications, where it is necessary to set the maximum
>duration of the call and terminate it forcefully if that duration is
>exceeded.
>
>The raw idea is as follows:
>
>- the module will register callbacks with tm.register_tmcb(), probably
>TMCB_REQUEST_IN and TMCB_REPLY_IN ones and will match INVITEs to BYEs
>keeping information about the state of ongoing sessions in the shared
>memory.
>
>- the module will provide interested modules with ability to register
>several callbacks, i.e. on dialog creation/teardown and yet another
>callback on dialog timeouts (more about that below).
>
>- the module will provide utility functions for forceful termination
>of any ongoing dialog.
>
>- when invoking dialog creation callback function, the module will
>give the function opportunity to install a timer on that dialog, so
>that if the dialog is still active after timer expires, then some
>action is performed. For example, in the debit card applications, in
>such case the accounting module can decide to forcefully terminate a
>dialog.
>
>What do you think?
>
>-Maxim
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers 

--
Jiri Kuthan            http://iptel.org/~jiri/  




More information about the sr-users mailing list