On Mon, Jan 20, 2003 at 10:50:42AM -0800, Surendra Prajapat wrote:
Hi Maxim,
Which version is b2bUa are you running ?
1.4.0.
Can you try the test without
SER proxy and see if you still have 200 Ok getting re-transmitted ?
there is an outstanding bug
http://bugzilla.vovida.org/bugzilla/show_bug.cgi?id=425 for
not matching the 200 with Ack. Atleast this test would verify that.
uA1---> B2bUa ---> Ua2
Yes, with B2bUa connected directly to UAs the 200 Ok is not re-transmitted,
so that it is probably the same bug as described in that bug report.
Fortunately, the bug doesn't cause any serious problems, because B2bUa
thinks that the session is estabilished after sending out the first 200 Ok,
while the UA1 thinks that the session is established after receiving the
first 200 Ok.
I've also noticed another problem with SIP stack - when the b2bua
for some reason can't contact second Ua it doesn't send Session Timeout,
as it expected to, therefore relying on uA1 sending Cancel to abort the
transaction. This probably can lead to a memory leak, if for some reason
(i.e. network congession, UA1 power-off etc) no Cancel from UA1 is received
at all.
Yet another problem discovered is that pthreads support is somehow
Linux-specific - when I'm compiling b2bua on FreeBSD with native pthreads
the b2bua dumps core when sending accounting request to the radius. The
problem doesn't pop up when I'm compiling b2bua on FreeBSD using linuxthreads
package for threading. If somebody is willing to help with that problem I
am ready to send stack traces or any other information necessary.
Thank you in advance!
-Maxim
Also if you can capture the B2bUa log with
LOG_DEBUG_STACK mode
./b2bUa -d -v LOG_DEBUG_STACK -c <config_file>
that can also help debug the problem.
-Surendra
At 08:22 PM 1/18/2003 +0200, Maxim Sobolev wrote:
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
<B2BUA_Configuration>
<SIP>
<Local>
<Port>5065</Port>
<Transport>UDP</Transport>
</Local>
<Proxy_Server>
<Address>192.168.1.100</Address>
<Port>5060</Port>
</Proxy_Server>
<Registration>
<Register>no</Register>
<Address>vocal.vovida.org</Address>
<Port>5060</Port>
<Expires>600</Expires>
</Registration>
</SIP>
<RADIUS>
<Local>
<Authentication_Port>1812</Authentication_Port>
<Accounting_Port>1812</Accounting_Port>
</Local>
<Billing_Server>
<Address>170.76.16.48</Address>
<Authentication_Port>8765</Authentication_Port>
<Accounting_Port>8765</Accounting_Port>
<Password>vovida</Password>
</Billing_Server>
</RADIUS>
<PrePaid>
<Billing>
<Option>free</Option>
<Refresh_Time>60</Refresh_Time>
<Extract_User_Id_From>Proxy-Authorization</Extract_User_Id_From>
<User_Id_Decode_Scheme>Basic</User_Id_Decode_Scheme>
</Billing>
<Use_SIP_INFO>no</Use_SIP_INFO>
<Use_HTTP>no</Use_HTTP>
</PrePaid>
<Redundancy />
</B2BUA_Configuration>