17 Jan
2003
17 Jan
'03
1:44 p.m.
Jan Janak wrote:
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.
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.
Hello,
comments inline.
On 16-01 23:37, Maxim Sobolev wrote:
Is it in cvs? If not, how can I obtain it?
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.
See above.
-Maxim
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 ?