[Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
Surendra Prajapat
sprajpat at cisco.com
Tue Jan 21 01:56:05 CET 2003
At 02:33 AM 1/21/2003 +0200, Maxim Sobolev wrote:
>On Mon, Jan 20, 2003 at 02:52:22PM -0800, Surendra Prajapat wrote:
> > Comments inline.
> > [...]
> > >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.
>
>I'll try it and let you know then.
Thanks.
> > >> >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.
>
>Yes, we are planning to contribute the feature back, but I am not sure
>it we will make it an option since we are not really interested in keeping
>the current quite unsecure and therefore not generally useable mechanism.
>Would it be possible for you to do an option from it if we will sibmit
>patched that replace current authentification mechanism with one digest
>based?
I think that would be feasible if we have the authentication mechanism
abstracted out.
May be a separate class like AAATransceiver with a generic interface to
AuthAgent.
-Surendra
>-Maxim
>
>
> >
> > 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