[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 23:52:22 CET 2003
Comments inline.
At 10:27 PM 1/20/2003 +0200, Maxim Sobolev wrote:
>On Mon, Jan 20, 2003 at 12:01:52PM -0800, Surendra Prajapat wrote:
> > 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 ?
>
>This is exactly the scenario I am having problem with. Seemingly, when UA2 is
>off-line, B2BUA tries to contact it several times, but then just gives up
>without sending 4xx Request Timeout message to UA1 as it is expected to.
Looks like 408 for request time-out would reach to the other side of
b2bUa, but it is just
sending 408 to the other side (UA1). See line 156 in MultilegCallControl.cxx
I think the 408 should be treated differently and a cancel should be
generated for
all the peers. Can you try the fix and send me the patch if that works for you.
> > >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.
>
>Would be really nice.
>
>BTW, is there any ongoing work on adding support for Digest-based radius
>authentification into b2bua as specified in the RADIUS Extension for
>Digest Authentification IETF draft? Since it is necessary for us we already
>started implementing it, but reinventing the wheel is not the thing we are
>interested in.
No plans yet but it is in todo list. Would it be possible for you to contribute
it back ? Would be nice if we can configure the option via config file.
thanks
Surendra
>-Maxim
>
> >
> > -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