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
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.
- 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.
- 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.
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?
- 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.
- 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.
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 ?
See above.
-Maxim
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.
- 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.
- 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.
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:
- 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.
- 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-
Jan Janak -
Jiri Kuthan -
Maxim Sobolev