[Serusers] [RFC] ideas about new dialog module

[Jan Janak]

Hello,

comments inline.

On 16-01 23:37, 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:

  We are working on dialog support. It is working already but still
  not mature enough to release.

> 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.

  You can match the INVITE and BYE transactions and you have the whole
  call. IMHO it is easier to modify billing software to do this than
  implement it in the proxy.

  From my point of view, dialog support in a proxy should be avoided
  wherever possible. The dialog support includes some additional bottleneck
  to the proxy. The proxy must maintain dialog state for the duration of
  the call and that can be very memory intensive. Our tests show that even
  transaction state can exhaust memory of an extremely loaded proxy in less
  than a minute.

> 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.

  Yes, there is no way to do it, that's a feature, not bug. Dialog support
  is not enough to make this possible. To be able to terminate a call, you must
  implement a back to back user agent. A back to back user agent is an entity
  that maintains two dialog states and acts as a UAS on one side and UAC on
  the other. That means it terminates calls on one side and initiates call
  on the other side. So even if you had dialog support in ser, you would be
  unable to terminate calls.

  Ser has been designed as a proxy, not a user agent.
 
> 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.

  How do you want to terminate a dialog if you are an endpoint
  of the dialog ?


   regards, Jan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20030117/b2be6d00/attachment.pgp>