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>