[Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
Surendra Prajapat
sprajpat at cisco.com
Mon Jan 20 21:01:52 CET 2003
Hi Maxim,
See my comments inline.
At 09:32 PM 1/20/2003 +0200, Maxim Sobolev wrote:
>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,
The session time-out is sent only when two parties in call. However in
scenario you
are describing when b2bua can not connect to second UA or fail to authorize,
the request time-outs or auth failed would trigger the cancel from b2bUa.
Have you tried
the scenario when UA2 is not on-line and b2bUa tried reaching it ? Do you
see the behavior different ?
>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
May be someone in community may help on this.
-Surendra
>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>
> >
More information about the sr-users
mailing list