[Serusers] [RFC] ideas about new dialog module

[Jan Janak]

On 17-01 13:44, Maxim Sobolev wrote:
> Jan Janak wrote:
> > 
> > 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.
> 
> Is it in cvs? If not, how can I obtain it?

Not yet, I will put it in the CVS once I make sure that it works as expected.

> > > 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.
> 
> Well, since some entity (B2B UA) will have to maintain call state
> anyway, this will only move botleneck to that entity, not eliminate
> it. Therefore, I don't see why introducing that another entity and
> additional level of indirection associated with it, when it is
> possible to do it right in the proxy. After all, I am planning to do
> it as a module, so that if somebody doesn't need this functionality he
> will not load the module and have the full raw power of the ser at his
> hands.
> 
  Sure, you cannot eliminate the bottleneck but at least you can move it
  to another entity which could be optimized as B2BUA, this is not true
  for ser. It is not possible to do really good implementation of B2BUA
  in ser, but nothing prevents you from implementing a module doing that as
  long as it doesn't require significant changes to other parts.
  
> > > 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.
> 
> I disagree - who prohibits you to send two BYEs to both parties once
> the timer is expired impersonating itself as UAS for one party's UAC
> and UAC for another party's UAS? Since you was in the middle of the
> call flow, you obviously have every piece of information necessary for
> doing it.

  As I have told you, you will need a B2BUA to implement this. ser is a
  proxy and many features that a user agent has to do are missing there.
  If you are looking for a hack that will be able to terminate a call only,
  that should be possible, but I personally don't like it, in my opinion ser
  should stay transaction-stateful only, dialog support and things that use
  it will only bloat it. We will probably distille dialog support and code
  that will use it from ser in the future.


    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/20030118/19aa243c/attachment.pgp>