Dear Sirs,
I am having some strange problems when trying to use b2bua for
accounting and call duration limiting with SER proxy server. The idea
is simple: since the SER can route SIP messages depending on their
source address, we can force incoming SIP messages to be passed to
B2BUA for accounting purposes first, and after the same request
re-enters the proxy from B2BUA pass it to the final destination. Call
flow looks like the following:
-----
|UA2|
-----
^
|
|4
|
----- 3 -------
----- 1 | |<-----------| |
|UA1|---->|SER| 2 |B2BUA|
----- | |----------->| |
----- -------
For some reason, it doesn't work in such configuration. The problem is
that B2BUA's UAC keeps resending `200 OK' replies ingnoring ACKs it
receives from UA2 until timeout hits, after which it considers the
call dead, despite the fact that both UA1 and UA2 think that the call
is established. Maybe it has something to do with the fact that it
sends to and receives messages from the same host (SER), but I don't
think that this should be a problem, since those two call legs have
different call id's, so that b2bua should be able to distinguish
between them easily. Attached please find tcpdump logs of one such
session, here 192.168.1.1 is UA1 (originating), 192.168.0.9 is UA2,
192.168.1.100 is the host running both SER and B2BUA (the former uses
port 5060, while the latter - 5065). There are two files:
ser-b2bua.log is the log of udp exchange between SER and B2BUA and
ser-ua1ua2.log - log of exchange between SER and UA1/UA2.
Any ideas are appreciated.
Thanks!
-Maxim
On Mon, Jan 20, 2003 at 03:22:33PM +0100, Jiri Kuthan wrote:
> At 09:53 PM 1/13/2003, you wrote:
> >Attached please find the patch, which implements t_on_positive()
> >approach. Now my config looks like the following and everything now
> >works as expected:
>
> thanks for the patch -- I will try to integrate it as I move ahead
> with other changes to TM. Does your nathelper module work now?
Attached please find more fresh patch with several bugs smashed. It
is probably the last one on this topic, because it works reasonably
well and we now have moved to adjusting b2bua for our needs (mostly
radius auth/acc). In addition to nathelper module, this patch
implements rport support as specified in the correstponding IETF
draft.
Thanks!
-Maxim
Folks,
I've noticed that there are multiple potential memory leaks in SER.
The problem is that if a insert_new_lump*() function returns a NULL
for some reason (currently the only condition is memory allocation
error), it doesn't free the memory buffer passed to it and most of
the code doesn't care to deallocate that buffer after NULL is returned.
It could be easily fixed and probably needs to before the next version
is released.
Thanks!
-Maxim
I'm thinking that the 'forceful termination' should have options for
redirection, i.e. to an announcements (or other media) server, etc. Is this
in line with your thoughts?
-Benson
> -----Original Message-----
> From: Maxim Sobolev [mailto:sobomax@portaone.com]
> Sent: Thursday, January 16, 2003 3:37 PM
> To: serusers(a)lists.iptel.org; kapitan(a)portaone.com
> Subject: [Serusers] [RFC] ideas about new dialog module
>
>
> 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(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
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
hi,
I have a problem with radius_auth, i use raidus_auth module as www-authentication ,but something is wrong, the free-radius server need the PW_PASSWORD attribute for authentication,
while the ser's radius_auth module doesn't send the PW_PASSWORD attribute, i can't find the password from the REGISTER message, there is a NONCE like
nonce="3e1947180000000040c0e6240c7f8145a64eb654ce9a14e0" and encrypted with MD5.
Do i need get the user's password and how to get user's the password? please help.
thanks.
Dear Sirs,
I am having some strange problems when trying to use b2bua for
accounting and call duration limiting with SER proxy server. The idea
is simple: since the SER can route SIP messages depending on their
source address, we can force incoming SIP messages to be passed to
B2BUA for accounting purposes first, and after the same request
re-enters the proxy from B2BUA pass it to the final destination. Call
flow looks like the following:
-----
|UA2|
-----
^
|
|4
|
----- 3 -------
----- 1 | |<-----------| |
|UA1|---->|SER| 2 |B2BUA|
----- | |----------->| |
----- -------
For some reason, it doesn't work in such configuration. The problem is
that B2BUA's UAC keeps resending `200 OK' replies ingnoring ACKs it
receives from UA2 until timeout hits, after which it considers the
call dead, despite the fact that both UA1 and UA2 think that the call
is established. Maybe it has something to do with the fact that it
sends to and receives messages from the same host (SER), but I don't
think that this should be a problem, since those two call legs have
different call id's, so that b2bua should be able to distinguish
between them easily. Attached please find tcpdump logs of one such
session, here 192.168.1.1 is UA1 (originating), 192.168.0.9 is UA2,
192.168.1.100 is the host running both SER and B2BUA (the former uses
port 5060, while the latter - 5065). There are two files:
ser-b2bua.log is the log of udp exchange between SER and B2BUA and
ser-ua1ua2.log - log of exchange between SER and UA1/UA2.
Any ideas are appreciated.
Thanks!
-Maxim
Hello,
your messages about CISCO ATA reminds me that I have also one (a preproduction
unit originally made by Komodo), so I upgraded firmware to 2.15 and tried it
behind a symmetric NAT. It works, I had to enable portforwarding for signalling
and media and setup properly outer address of the NAT box in the phone.
Once you finish your NAThelper module, I would like to give it a try and see
if it works without modifications of the NAT box. So I can help you to test the
code if you want.
regards, Jan.
Folks,
While playing with SER I found that I can trigger repeatable crash when
doing REGISTER multiple times. Quick glance at the code in question
revealed that indeed, when constructing reply to REGISTER message,
SER uses fixed-lengh buffer to put all non-expired contacts for that
user and doesn't bother to check for overflow. The bug could be easily
exploited by a complete stranger on servers that don't perform
authentification of REGISTER requests, and by an user with a valid
credintals on server that do authentification. Mounting attack leads
to denial of service.
Attached please find fake REGISTER message, which if sent to open
server kills it (nc -u my.sip.server 5060 < register.killser),
and patch to fix the problem.
-Maxim