[Serusers] Troubles using b2bua as a accounting and call duration limiting module for SER router
18 Jan
2003
18 Jan
'03
7:22 p.m.
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
20 Jan
20 Jan
7:50 p.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
Hi Maxim,
Which version is b2bUa are you running ? 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
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>
8:32 p.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
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>
9:01 p.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
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:
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 ?
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
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>
>
9:27 p.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
On Mon, Jan 20, 2003 at 12:01:52PM -0800, Surendra Prajapat wrote:
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.
-Maxim
Hi Maxim,
See my comments inline.
At 09:32 PM 1/20/2003 +0200, Maxim Sobolev wrote:
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.
On Mon, Jan 20, 2003 at 10:50:42AM -0800, Surendra
Prajapat wrote:
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 ? 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
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>
>
11:52 p.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
Comments inline.
At 10:27 PM 1/20/2003 +0200, Maxim Sobolev wrote:
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
On Mon, Jan 20, 2003 at 12:01:52PM -0800, Surendra
Prajapat wrote:
authorize,
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.
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 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. >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. -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>
> >>
>
21 Jan
21 Jan
1:33 a.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
On Mon, Jan 20, 2003 at 02:52:22PM -0800, Surendra Prajapat wrote:
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?
-Maxim
Comments inline.
[...]
I'll try it and let you know then.
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.
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>
> >>
>
1:56 a.m.
New subject: [Serusers] Re: Troubles using b2bua as a accounting and call duration limiting module for SER router
At 02:33 AM 1/21/2003 +0200, Maxim Sobolev wrote:
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
On Mon, Jan 20, 2003 at 02:52:22PM -0800, Surendra
Prajapat wrote:
MultilegCallControl.cxx
Thanks.
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 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. >>
>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. -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>
> >> >>
> >>
>
7772
days inactive
7775
days old
7 comments
3 participants
participants (3)
-
Maxim Sobolev -
Maxim Sobolev -
Surendra Prajapat