Thread: [OpenSIPStack] OpenSBC terminate connection
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
|
From: André M. <an...@ma...> - 2008-10-24 14:18:33
|
Hello, I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is as follows: The OpenSBC is configured in B2BUAUpperReg mode. I place a call from a SIP client (A) to a PSTN Phone (B). The connection is established whithout any problems. A goes on hook and sends a BYE to which the SBC immediately replies with a 200 OK. Another BYE message is being sent out to the softswitch platform. The softswitch challenges authentication and therefore responds with a 401 unauthorized message. Since the SBC, at least that's my assumption, has already successfully terminated the internal connection there is no match and the requested authenticated BYE will never be send out. This behavior results in ghost connections and the billing runs until B goes on-hook as well. I have tested the same scenario with my SIP client directly connected to our softswitch platform and did not detect the problem there. Upon receiving the 401 unauthorized message, the client resends the BYE containing the authentication information. I have checked the RFC 3261 this morning and tried to find out whether it is a regular behavior to reply to a BYE message with authentication challenge or not. I could not find any hint there. How difficult is it to change this behavior and wait for confirmation before terminating the entire connection ? Regards, Andre |
|
From: <jo...@op...> - 2008-10-25 14:47:30
|
Andre, This is a known problem area in OpenSBC. Since we are a B2BUA and not a proxy we terminate our dialogs based on successful processing of a BYE request. OpenSBC does not wait for a final response before it destroys connections. This ensures that the SBC does not end up with ghost sessions as well if a certain UA is not able to handle authenticated BYE requests. This is the second time I have received this report regarding this problem. Can you provide me a with a level 5 log for this problematic call offlist? I'll see if an easy workaround is possible. If you could, please also attach a wire shark capture of the successful call you made using a UA directly calling your softswitch. My e-mail address is jo...@op... Joegen André Mamitzsch wrote: > Hello, > > I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is > as follows: > > The OpenSBC is configured in B2BUAUpperReg mode. > > I place a call from a SIP client (A) to a PSTN Phone (B). The connection > is established whithout any problems. A goes on hook and sends a BYE to > which the SBC immediately replies with a 200 OK. > > Another BYE message is being sent out to the softswitch platform. > > The softswitch challenges authentication and therefore responds with a > 401 unauthorized message. Since the SBC, at least that's my assumption, > has already successfully terminated the internal connection there is no > match and the requested authenticated BYE will never be send out. This > behavior results in ghost connections and the billing runs until B goes > on-hook as well. > > I have tested the same scenario with my SIP client directly connected to > our softswitch platform and did not detect the problem there. Upon > receiving the 401 unauthorized message, the client resends the BYE > containing the authentication information. > > I have checked the RFC 3261 this morning and tried to find out whether > it is a regular behavior to reply to a BYE message with authentication > challenge or not. I could not find any hint there. > > How difficult is it to change this behavior and wait for confirmation > before terminating the entire connection ? > > Regards, > > Andre > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM > > |
|
From: <jo...@op...> - 2008-10-27 10:26:49
|
André, Please try patches in CVS and update the mailing list about the result of your test. I think by simply resending the original Authorization header sent in the initial INVITE doe subsequent in-dialog requests should do the trick in your case. Thanks. Joegen André Mamitzsch wrote: > Hello Joegen, > > many thanks for your help in respect to this topic. Please find the > requested traces attached. The archive contains the following files: > > 1. diagram.txt - ladder logic digram inc. all IP Addresses > 2. b2bua-2008-10-27-24959.log - Level 5 trace from OpenSBC > 3. trace_20081027_sbc_sip.cap - Wireshark trace from OpenSBC for the > call in question > 4. trace_20081027_bts10200.cap - Wireshark trace for call with UA > directly connected to BTS10200 > > If you need anything else, please let me know. > Andre, > > This is a known problem area in OpenSBC. Since we are a B2BUA and not a > proxy we terminate our dialogs based on successful processing of a BYE > request. OpenSBC does not wait for a final response before it destroys > connections. This ensures that the SBC does not end up with ghost > sessions as well if a certain UA is not able to handle authenticated BYE > requests. This is the second time I have received this report regarding > this problem. Can you provide me a with a level 5 log for this > problematic call offlist? I'll see if an easy workaround is possible. > If you could, please also attach a wire shark capture of the successful > call you made using a UA directly calling your softswitch. My e-mail > address is jo...@op... > > Joegen > > André Mamitzsch wrote: > >> Hello, >> >> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is >> as follows: >> >> The OpenSBC is configured in B2BUAUpperReg mode. >> >> I place a call from a SIP client (A) to a PSTN Phone (B). The connection >> is established whithout any problems. A goes on hook and sends a BYE to >> which the SBC immediately replies with a 200 OK. >> >> Another BYE message is being sent out to the softswitch platform. >> >> The softswitch challenges authentication and therefore responds with a >> 401 unauthorized message. Since the SBC, at least that's my assumption, >> has already successfully terminated the internal connection there is no >> match and the requested authenticated BYE will never be send out. This >> behavior results in ghost connections and the billing runs until B goes >> on-hook as well. >> >> I have tested the same scenario with my SIP client directly connected to >> our softswitch platform and did not detect the problem there. Upon >> receiving the 401 unauthorized message, the client resends the BYE >> containing the authentication information. >> >> I have checked the RFC 3261 this morning and tried to find out whether >> it is a regular behavior to reply to a BYE message with authentication >> challenge or not. I could not find any hint there. >> >> How difficult is it to change this behavior and wait for confirmation >> before terminating the entire connection ? >> >> Regards, >> >> Andre >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM >> >> >> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.3/1746 - Release Date: 10/25/2008 5:55 PM > > |
|
From: voice <vo...@ne...> - 2008-10-27 16:22:40
|
Hi Joegen Using sipX 3.10.2 SBC and Gateway setup, i have gotten inGate's firewall/siparator to facilitate/register Grandstream phones and make and receive calls. I was thinking if i sent you my working inGate Dial Plan and other related setups that you might find them helpful to document OSBC Howto sipX. |
|
From: <jo...@op...> - 2008-10-27 16:40:15
|
Hi, First, can I get your name so I can refer to you in a more personal manner? I am not familiar with ingate although there might be use for it for those who are using ingate already and would want to migrate to OSBC. If you are interested, we could start this systematically by you providing a network diagram of each of the setup you would want to accomplish. I would recommend dia http://www.gnome.org/projects/dia/ so we have a common editor. I could then provide the necessary configuration to make such setup work. You test the configuration and see if it satisfies your need. We then compile the docs and commit it in OpenSBC CVS under docs directory as well as publish an online version in the OSS forum. If you are amenable to this, we can do this in a regular basis until all your scenarios are satisfied. Joegen voice wrote: > Hi Joegen > > Using sipX 3.10.2 SBC and Gateway setup, i have gotten inGate's > firewall/siparator to facilitate/register Grandstream phones and make and > receive calls. > > I was thinking if i sent you my working inGate Dial Plan and other related > setups that you might find them helpful to document OSBC Howto sipX. > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.4/1749 - Release Date: 10/27/2008 7:57 AM > > |
|
From: André M. <an...@ma...> - 2008-10-27 11:29:32
|
Hello Joegen,
I have compiled the latest version from CVS. There is a small typo in
opensbc/SBCB2BUAEndPoint.h which must be corrected to get it working.
--- SBCB2BUAEndPoint.h.orig 2008-10-27 12:15:46.000000000 +0100
+++ SBCB2BUAEndPoint.h 2008-10-27 12:03:28.000000000 +0100
@@ -50,7 +50,7 @@
#ifndef SBCB2BUAENDPOINT_H
#define SBCB2BUAENDPOINT_H
-#include "B2BUAendPoint.h"
+#include "B2BUAEndPoint.h"
namespace B2BUA
{
I have tested the call scenario again, but it still fails. The
softswitch is responding with a "400 Bad Request" to the BYE message
now. I have sent you the wireshark offline.
Regards,
Andre
jo...@op... schrieb:
> Andre,
>
> This is a known problem area in OpenSBC. Since we are a B2BUA and not a
> proxy we terminate our dialogs based on successful processing of a BYE
> request. OpenSBC does not wait for a final response before it destroys
> connections. This ensures that the SBC does not end up with ghost
> sessions as well if a certain UA is not able to handle authenticated BYE
> requests. This is the second time I have received this report regarding
> this problem. Can you provide me a with a level 5 log for this
> problematic call offlist? I'll see if an easy workaround is possible.
> If you could, please also attach a wire shark capture of the successful
> call you made using a UA directly calling your softswitch. My e-mail
> address is jo...@op...
>
> Joegen
>
> André Mamitzsch wrote:
>> Hello,
>>
>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is
>> as follows:
>>
>> The OpenSBC is configured in B2BUAUpperReg mode.
>>
>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection
>> is established whithout any problems. A goes on hook and sends a BYE to
>> which the SBC immediately replies with a 200 OK.
>>
>> Another BYE message is being sent out to the softswitch platform.
>>
>> The softswitch challenges authentication and therefore responds with a
>> 401 unauthorized message. Since the SBC, at least that's my assumption,
>> has already successfully terminated the internal connection there is no
>> match and the requested authenticated BYE will never be send out. This
>> behavior results in ghost connections and the billing runs until B goes
>> on-hook as well.
>>
>> I have tested the same scenario with my SIP client directly connected to
>> our softswitch platform and did not detect the problem there. Upon
>> receiving the 401 unauthorized message, the client resends the BYE
>> containing the authentication information.
>>
>> I have checked the RFC 3261 this morning and tried to find out whether
>> it is a regular behavior to reply to a BYE message with authentication
>> challenge or not. I could not find any hint there.
>>
>> How difficult is it to change this behavior and wait for confirmation
>> before terminating the entire connection ?
>>
>> Regards,
>>
>> Andre
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM
>>
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
|
|
From: <jo...@op...> - 2008-10-27 12:08:42
|
Ok I see the fault. Thanks for the wireshark capture. Fix will be in
shortly.
André Mamitzsch wrote:
> Hello Joegen,
>
> I have compiled the latest version from CVS. There is a small typo in
> opensbc/SBCB2BUAEndPoint.h which must be corrected to get it working.
>
> --- SBCB2BUAEndPoint.h.orig 2008-10-27 12:15:46.000000000 +0100
> +++ SBCB2BUAEndPoint.h 2008-10-27 12:03:28.000000000 +0100
> @@ -50,7 +50,7 @@
> #ifndef SBCB2BUAENDPOINT_H
> #define SBCB2BUAENDPOINT_H
>
> -#include "B2BUAendPoint.h"
> +#include "B2BUAEndPoint.h"
>
> namespace B2BUA
> {
>
> I have tested the call scenario again, but it still fails. The
> softswitch is responding with a "400 Bad Request" to the BYE message
> now. I have sent you the wireshark offline.
>
> Regards,
>
> Andre
>
>
> jo...@op... schrieb:
>> Andre,
>>
>> This is a known problem area in OpenSBC. Since we are a B2BUA and
>> not a proxy we terminate our dialogs based on successful processing
>> of a BYE request. OpenSBC does not wait for a final response before
>> it destroys connections. This ensures that the SBC does not end up
>> with ghost sessions as well if a certain UA is not able to handle
>> authenticated BYE requests. This is the second time I have received
>> this report regarding this problem. Can you provide me a with a
>> level 5 log for this problematic call offlist? I'll see if an easy
>> workaround is possible. If you could, please also attach a wire
>> shark capture of the successful call you made using a UA directly
>> calling your softswitch. My e-mail address is jo...@op...
>>
>> Joegen
>>
>> André Mamitzsch wrote:
>>> Hello,
>>>
>>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The
>>> scenario is as follows:
>>>
>>> The OpenSBC is configured in B2BUAUpperReg mode.
>>>
>>> I place a call from a SIP client (A) to a PSTN Phone (B). The
>>> connection is established whithout any problems. A goes on hook and
>>> sends a BYE to which the SBC immediately replies with a 200 OK.
>>>
>>> Another BYE message is being sent out to the softswitch platform.
>>>
>>> The softswitch challenges authentication and therefore responds with
>>> a 401 unauthorized message. Since the SBC, at least that's my
>>> assumption, has already successfully terminated the internal
>>> connection there is no match and the requested authenticated BYE
>>> will never be send out. This behavior results in ghost connections
>>> and the billing runs until B goes on-hook as well.
>>>
>>> I have tested the same scenario with my SIP client directly
>>> connected to our softswitch platform and did not detect the problem
>>> there. Upon receiving the 401 unauthorized message, the client
>>> resends the BYE containing the authentication information.
>>>
>>> I have checked the RFC 3261 this morning and tried to find out
>>> whether it is a regular behavior to reply to a BYE message with
>>> authentication challenge or not. I could not find any hint there.
>>>
>>> How difficult is it to change this behavior and wait for
>>> confirmation before terminating the entire connection ?
>>>
>>> Regards,
>>>
>>> Andre
>>>
>>>
>>> -------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus
>>> Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM
>
>
|
|
From: <jo...@op...> - 2008-10-27 12:42:40
|
Hi André,
It turned out that merely resending the authorization header from the
first INVITE is not enough if the UAC and the UAS both supports
qop="auth". Please try the new patch in CVS and confirm if your server
and OpenSBC can now properly inter-operate.
Joegen
André Mamitzsch wrote:
> Hello Joegen,
>
> I have compiled the latest version from CVS. There is a small typo in
> opensbc/SBCB2BUAEndPoint.h which must be corrected to get it working.
>
> --- SBCB2BUAEndPoint.h.orig 2008-10-27 12:15:46.000000000 +0100
> +++ SBCB2BUAEndPoint.h 2008-10-27 12:03:28.000000000 +0100
> @@ -50,7 +50,7 @@
> #ifndef SBCB2BUAENDPOINT_H
> #define SBCB2BUAENDPOINT_H
>
> -#include "B2BUAendPoint.h"
> +#include "B2BUAEndPoint.h"
>
> namespace B2BUA
> {
>
> I have tested the call scenario again, but it still fails. The
> softswitch is responding with a "400 Bad Request" to the BYE message
> now. I have sent you the wireshark offline.
>
> Regards,
>
> Andre
>
>
> jo...@op... schrieb:
>
>> Andre,
>>
>> This is a known problem area in OpenSBC. Since we are a B2BUA and not a
>> proxy we terminate our dialogs based on successful processing of a BYE
>> request. OpenSBC does not wait for a final response before it destroys
>> connections. This ensures that the SBC does not end up with ghost
>> sessions as well if a certain UA is not able to handle authenticated BYE
>> requests. This is the second time I have received this report regarding
>> this problem. Can you provide me a with a level 5 log for this
>> problematic call offlist? I'll see if an easy workaround is possible.
>> If you could, please also attach a wire shark capture of the successful
>> call you made using a UA directly calling your softswitch. My e-mail
>> address is jo...@op...
>>
>> Joegen
>>
>> André Mamitzsch wrote:
>>
>>> Hello,
>>>
>>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is
>>> as follows:
>>>
>>> The OpenSBC is configured in B2BUAUpperReg mode.
>>>
>>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection
>>> is established whithout any problems. A goes on hook and sends a BYE to
>>> which the SBC immediately replies with a 200 OK.
>>>
>>> Another BYE message is being sent out to the softswitch platform.
>>>
>>> The softswitch challenges authentication and therefore responds with a
>>> 401 unauthorized message. Since the SBC, at least that's my assumption,
>>> has already successfully terminated the internal connection there is no
>>> match and the requested authenticated BYE will never be send out. This
>>> behavior results in ghost connections and the billing runs until B goes
>>> on-hook as well.
>>>
>>> I have tested the same scenario with my SIP client directly connected to
>>> our softswitch platform and did not detect the problem there. Upon
>>> receiving the 401 unauthorized message, the client resends the BYE
>>> containing the authentication information.
>>>
>>> I have checked the RFC 3261 this morning and tried to find out whether
>>> it is a regular behavior to reply to a BYE message with authentication
>>> challenge or not. I could not find any hint there.
>>>
>>> How difficult is it to change this behavior and wait for confirmation
>>> before terminating the entire connection ?
>>>
>>> Regards,
>>>
>>> Andre
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com
>>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM
>>>
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM
>
>
|
|
From: André M. <an...@ma...> - 2008-10-27 13:40:43
|
Hello Joegen, I have tested against the latest CVS version, 1.1.5-27, still no success. The softswitch still responds with a "400 Bad Request". Regards, Andre jo...@op... schrieb: > Andre, > > This is a known problem area in OpenSBC. Since we are a B2BUA and not a > proxy we terminate our dialogs based on successful processing of a BYE > request. OpenSBC does not wait for a final response before it destroys > connections. This ensures that the SBC does not end up with ghost > sessions as well if a certain UA is not able to handle authenticated BYE > requests. This is the second time I have received this report regarding > this problem. Can you provide me a with a level 5 log for this > problematic call offlist? I'll see if an easy workaround is possible. > If you could, please also attach a wire shark capture of the successful > call you made using a UA directly calling your softswitch. My e-mail > address is jo...@op... > > Joegen > > André Mamitzsch wrote: >> Hello, >> >> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is >> as follows: >> >> The OpenSBC is configured in B2BUAUpperReg mode. >> >> I place a call from a SIP client (A) to a PSTN Phone (B). The connection >> is established whithout any problems. A goes on hook and sends a BYE to >> which the SBC immediately replies with a 200 OK. >> >> Another BYE message is being sent out to the softswitch platform. >> >> The softswitch challenges authentication and therefore responds with a >> 401 unauthorized message. Since the SBC, at least that's my assumption, >> has already successfully terminated the internal connection there is no >> match and the requested authenticated BYE will never be send out. This >> behavior results in ghost connections and the billing runs until B goes >> on-hook as well. >> >> I have tested the same scenario with my SIP client directly connected to >> our softswitch platform and did not detect the problem there. Upon >> receiving the 401 unauthorized message, the client resends the BYE >> containing the authentication information. >> >> I have checked the RFC 3261 this morning and tried to find out whether >> it is a regular behavior to reply to a BYE message with authentication >> challenge or not. I could not find any hint there. >> >> How difficult is it to change this behavior and wait for confirmation >> before terminating the entire connection ? >> >> Regards, >> >> Andre >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM >> >> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel |
|
From: <jo...@op...> - 2008-10-27 13:53:09
|
Andre, If it's not much trouble. Please provide level 5 log and wireshark capture from the sbc box. Joegen André Mamitzsch wrote: > Hello Joegen, > > I have tested against the latest CVS version, 1.1.5-27, still no > success. The softswitch still responds with a "400 Bad Request". > > Regards, > > Andre > > jo...@op... schrieb: > >> Andre, >> >> This is a known problem area in OpenSBC. Since we are a B2BUA and not a >> proxy we terminate our dialogs based on successful processing of a BYE >> request. OpenSBC does not wait for a final response before it destroys >> connections. This ensures that the SBC does not end up with ghost >> sessions as well if a certain UA is not able to handle authenticated BYE >> requests. This is the second time I have received this report regarding >> this problem. Can you provide me a with a level 5 log for this >> problematic call offlist? I'll see if an easy workaround is possible. >> If you could, please also attach a wire shark capture of the successful >> call you made using a UA directly calling your softswitch. My e-mail >> address is jo...@op... >> >> Joegen >> >> André Mamitzsch wrote: >> >>> Hello, >>> >>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is >>> as follows: >>> >>> The OpenSBC is configured in B2BUAUpperReg mode. >>> >>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection >>> is established whithout any problems. A goes on hook and sends a BYE to >>> which the SBC immediately replies with a 200 OK. >>> >>> Another BYE message is being sent out to the softswitch platform. >>> >>> The softswitch challenges authentication and therefore responds with a >>> 401 unauthorized message. Since the SBC, at least that's my assumption, >>> has already successfully terminated the internal connection there is no >>> match and the requested authenticated BYE will never be send out. This >>> behavior results in ghost connections and the billing runs until B goes >>> on-hook as well. >>> >>> I have tested the same scenario with my SIP client directly connected to >>> our softswitch platform and did not detect the problem there. Upon >>> receiving the 401 unauthorized message, the client resends the BYE >>> containing the authentication information. >>> >>> I have checked the RFC 3261 this morning and tried to find out whether >>> it is a regular behavior to reply to a BYE message with authentication >>> challenge or not. I could not find any hint there. >>> >>> How difficult is it to change this behavior and wait for confirmation >>> before terminating the entire connection ? >>> >>> Regards, >>> >>> Andre >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - http://www.avg.com >>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM >>> >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM > > |
|
From: Andre M. <an...@ma...> - 2008-10-27 15:38:07
|
Hi Joegen, my tests against the latest CVS version were successfull. Calls are properly terminated now - we do not see ghost connections anymore. Many thanks for the help and the quick fix. Andre jo...@op... schrieb: > Andre, > > If it's not much trouble. Please provide level 5 log and wireshark > capture from the sbc box. > > Joegen > > André Mamitzsch wrote: >> Hello Joegen, >> >> I have tested against the latest CVS version, 1.1.5-27, still no >> success. The softswitch still responds with a "400 Bad Request". >> >> Regards, >> >> Andre >> >> jo...@op... schrieb: >> >>> Andre, >>> >>> This is a known problem area in OpenSBC. Since we are a B2BUA and not a >>> proxy we terminate our dialogs based on successful processing of a BYE >>> request. OpenSBC does not wait for a final response before it destroys >>> connections. This ensures that the SBC does not end up with ghost >>> sessions as well if a certain UA is not able to handle authenticated BYE >>> requests. This is the second time I have received this report regarding >>> this problem. Can you provide me a with a level 5 log for this >>> problematic call offlist? I'll see if an easy workaround is possible. >>> If you could, please also attach a wire shark capture of the successful >>> call you made using a UA directly calling your softswitch. My e-mail >>> address is jo...@op... >>> >>> Joegen >>> >>> André Mamitzsch wrote: >>> >>>> Hello, >>>> >>>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is >>>> as follows: >>>> >>>> The OpenSBC is configured in B2BUAUpperReg mode. >>>> >>>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection >>>> is established whithout any problems. A goes on hook and sends a BYE to >>>> which the SBC immediately replies with a 200 OK. >>>> >>>> Another BYE message is being sent out to the softswitch platform. >>>> >>>> The softswitch challenges authentication and therefore responds with a >>>> 401 unauthorized message. Since the SBC, at least that's my assumption, >>>> has already successfully terminated the internal connection there is no >>>> match and the requested authenticated BYE will never be send out. This >>>> behavior results in ghost connections and the billing runs until B goes >>>> on-hook as well. >>>> >>>> I have tested the same scenario with my SIP client directly connected to >>>> our softswitch platform and did not detect the problem there. Upon >>>> receiving the 401 unauthorized message, the client resends the BYE >>>> containing the authentication information. >>>> >>>> I have checked the RFC 3261 this morning and tried to find out whether >>>> it is a regular behavior to reply to a BYE message with authentication >>>> challenge or not. I could not find any hint there. >>>> >>>> How difficult is it to change this behavior and wait for confirmation >>>> before terminating the entire connection ? >>>> >>>> Regards, >>>> >>>> Andre >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> opensipstack-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - http://www.avg.com >>>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM >> >> > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel |
|
From: <jo...@op...> - 2008-10-27 15:47:24
|
Thanks to you, too for giving a comprehensive bug report. Andre Mamitzsch wrote: > Hi Joegen, > > my tests against the latest CVS version were successfull. Calls are > properly terminated now - we do not see ghost connections anymore. > Many thanks for the help and the quick fix. > > Andre > > jo...@op... schrieb: > >> Andre, >> >> If it's not much trouble. Please provide level 5 log and wireshark >> capture from the sbc box. >> >> Joegen >> >> André Mamitzsch wrote: >> >>> Hello Joegen, >>> >>> I have tested against the latest CVS version, 1.1.5-27, still no >>> success. The softswitch still responds with a "400 Bad Request". >>> >>> Regards, >>> >>> Andre >>> >>> jo...@op... schrieb: >>> >>> >>>> Andre, >>>> >>>> This is a known problem area in OpenSBC. Since we are a B2BUA and not a >>>> proxy we terminate our dialogs based on successful processing of a BYE >>>> request. OpenSBC does not wait for a final response before it destroys >>>> connections. This ensures that the SBC does not end up with ghost >>>> sessions as well if a certain UA is not able to handle authenticated BYE >>>> requests. This is the second time I have received this report regarding >>>> this problem. Can you provide me a with a level 5 log for this >>>> problematic call offlist? I'll see if an easy workaround is possible. >>>> If you could, please also attach a wire shark capture of the successful >>>> call you made using a UA directly calling your softswitch. My e-mail >>>> address is jo...@op... >>>> >>>> Joegen >>>> >>>> André Mamitzsch wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is >>>>> as follows: >>>>> >>>>> The OpenSBC is configured in B2BUAUpperReg mode. >>>>> >>>>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection >>>>> is established whithout any problems. A goes on hook and sends a BYE to >>>>> which the SBC immediately replies with a 200 OK. >>>>> >>>>> Another BYE message is being sent out to the softswitch platform. >>>>> >>>>> The softswitch challenges authentication and therefore responds with a >>>>> 401 unauthorized message. Since the SBC, at least that's my assumption, >>>>> has already successfully terminated the internal connection there is no >>>>> match and the requested authenticated BYE will never be send out. This >>>>> behavior results in ghost connections and the billing runs until B goes >>>>> on-hook as well. >>>>> >>>>> I have tested the same scenario with my SIP client directly connected to >>>>> our softswitch platform and did not detect the problem there. Upon >>>>> receiving the 401 unauthorized message, the client resends the BYE >>>>> containing the authentication information. >>>>> >>>>> I have checked the RFC 3261 this morning and tried to find out whether >>>>> it is a regular behavior to reply to a BYE message with authentication >>>>> challenge or not. I could not find any hint there. >>>>> >>>>> How difficult is it to change this behavior and wait for confirmation >>>>> before terminating the entire connection ? >>>>> >>>>> Regards, >>>>> >>>>> Andre >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>> _______________________________________________ >>>>> opensipstack-devel mailing list >>>>> ope...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG - http://www.avg.com >>>>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> opensipstack-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - http://www.avg.com >>> Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM >>> >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM > > |
|
From: OpenSIPStack F. <ope...@op...> - 2008-11-17 11:52:20
|
I have the exact same problem with the latest CVS version 1.1.5-36.
The softswitch replies to the BYE with a "400 Bad Request".
I'll provide level 5 log and wireshark capture.
Regards.
Antonio.
> {quote:title=Guest wrote:}{quote}Andre,
>
> If it's not much trouble. Please provide level 5 log and wireshark
> capture from the sbc box.
>
> Joegen
>
> André Mamitzsch wrote:
> > Hello Joegen,
> >
> > I have tested against the latest CVS version, 1.1.5-27, still no
> > success. The softswitch still responds with a "400 Bad Request".
> >
> > Regards,
> >
> > Andre
> >
> > jo...@op... schrieb:
> >
> > > Andre,
> > >
> > > This is a known problem area in OpenSBC. Since we are a B2BUA and not a
> > > proxy we terminate our dialogs based on successful processing of a BYE
> > > request. OpenSBC does not wait for a final response before it destroys
> > > connections. This ensures that the SBC does not end up with ghost
> > > sessions as well if a certain UA is not able to handle authenticated BYE
> > > requests. This is the second time I have received this report regarding
> > > this problem. Can you provide me a with a level 5 log for this
> > > problematic call offlist? I'll see if an easy workaround is possible.
> > > If you could, please also attach a wire shark capture of the successful
> > > call you made using a UA directly calling your softswitch. My e-mail
> > > address is jo...@op...
> > >
> > > Joegen
> > >
> > > André Mamitzsch wrote:
> > >
> > > > Hello,
> > > >
> > > > I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is
> > > > as follows:
> > > >
> > > > The OpenSBC is configured in B2BUAUpperReg mode.
> > > >
> > > > I place a call from a SIP client (A) to a PSTN Phone (B). The connection
> > > > is established whithout any problems. A goes on hook and sends a BYE to
> > > > which the SBC immediately replies with a 200 OK.
> > > >
> > > > Another BYE message is being sent out to the softswitch platform.
> > > >
> > > > The softswitch challenges authentication and therefore responds with a
> > > > 401 unauthorized message. Since the SBC, at least that's my assumption,
> > > > has already successfully terminated the internal connection there is no
> > > > match and the requested authenticated BYE will never be send out. This
> > > > behavior results in ghost connections and the billing runs until B goes
> > > > on-hook as well.
> > > >
> > > > I have tested the same scenario with my SIP client directly connected to
> > > > our softswitch platform and did not detect the problem there. Upon
> > > > receiving the 401 unauthorized message, the client resends the BYE
> > > > containing the authentication information.
> > > >
> > > > I have checked the RFC 3261 this morning and tried to find out whether
> > > > it is a regular behavior to reply to a BYE message with authentication
> > > > challenge or not. I could not find any hint there.
> > > >
> > > > How difficult is it to change this behavior and wait for confirmation
> > > > before terminating the entire connection ?
> > > >
> > > > Regards,
> > > >
> > > > Andre
> > > > -----
> > > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > > > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > > > Grand prize is a trip for two to an Open Source event anywhere in the world
> > > > [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
> > > > _______________________________________________
> > > > opensipstack-devel mailing list
> > > > ope...@li...
> > > > [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
> > > > -----
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - [http://www.avg.com]
> > > > Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM
> > > >
> > > >
> > > >
> > > >
> > > > -----
> > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > > Grand prize is a trip for two to an Open Source event anywhere in the world
> > > [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
> > > _______________________________________________
> > > opensipstack-devel mailing list
> > > ope...@li...
> > > [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]-----
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
> > _______________________________________________
> > opensipstack-devel mailing list
> > ope...@li...
> > [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
> > -----
> >
> > No virus found in this incoming message.
> > Checked by AVG - [http://www.avg.com]
> > Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM
> >
> >
> >
>
>
> -----
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
|
|
From: <jo...@op...> - 2008-11-17 16:15:56
|
Got your log. Same case, but not quite. In your case the UA which
offered QOP did not send "any" authorization header in BYE. This is a
UA problem, not OpenSBC. Your UA should have sent a new authorization
header to update the previous authorization send in the INVITE
challenge. OpenSBC does not participate in mid dialog request
authentication except acting as a relay. It is also impossible for
OpenSBC to reproduce the QOP state without knowing the exact password
used to produce the original response. If OpenSBC "CAN" do this, then
QOP is in big trouble for obvious reasons.
OpenSIPStack Forum wrote:
> I have the exact same problem with the latest CVS version 1.1.5-36.
>
>
> The softswitch replies to the BYE with a "400 Bad Request".
>
>
> I'll provide level 5 log and wireshark capture.
>
>
> Regards.
>
>
> Antonio.
>
>
>
>
>
>> {quote:title=Guest wrote:}{quote}Andre,
>>
>> If it's not much trouble. Please provide level 5 log and wireshark
>> capture from the sbc box.
>>
>> Joegen
>>
>> André Mamitzsch wrote:
>>
>>> Hello Joegen,
>>>
>>> I have tested against the latest CVS version, 1.1.5-27, still no
>>> success. The softswitch still responds with a "400 Bad Request".
>>>
>>> Regards,
>>>
>>> Andre
>>>
>>> jo...@op... schrieb:
>>>
>>>
>>>> Andre,
>>>>
>>>> This is a known problem area in OpenSBC. Since we are a B2BUA and not a
>>>> proxy we terminate our dialogs based on successful processing of a BYE
>>>> request. OpenSBC does not wait for a final response before it destroys
>>>> connections. This ensures that the SBC does not end up with ghost
>>>> sessions as well if a certain UA is not able to handle authenticated BYE
>>>> requests. This is the second time I have received this report regarding
>>>> this problem. Can you provide me a with a level 5 log for this
>>>> problematic call offlist? I'll see if an easy workaround is possible.
>>>> If you could, please also attach a wire shark capture of the successful
>>>> call you made using a UA directly calling your softswitch. My e-mail
>>>> address is jo...@op...
>>>>
>>>> Joegen
>>>>
>>>> André Mamitzsch wrote:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> I have seen a strange behavior with the OpenSBC1.1.5RC1. The scenario is
>>>>> as follows:
>>>>>
>>>>> The OpenSBC is configured in B2BUAUpperReg mode.
>>>>>
>>>>> I place a call from a SIP client (A) to a PSTN Phone (B). The connection
>>>>> is established whithout any problems. A goes on hook and sends a BYE to
>>>>> which the SBC immediately replies with a 200 OK.
>>>>>
>>>>> Another BYE message is being sent out to the softswitch platform.
>>>>>
>>>>> The softswitch challenges authentication and therefore responds with a
>>>>> 401 unauthorized message. Since the SBC, at least that's my assumption,
>>>>> has already successfully terminated the internal connection there is no
>>>>> match and the requested authenticated BYE will never be send out. This
>>>>> behavior results in ghost connections and the billing runs until B goes
>>>>> on-hook as well.
>>>>>
>>>>> I have tested the same scenario with my SIP client directly connected to
>>>>> our softswitch platform and did not detect the problem there. Upon
>>>>> receiving the 401 unauthorized message, the client resends the BYE
>>>>> containing the authentication information.
>>>>>
>>>>> I have checked the RFC 3261 this morning and tried to find out whether
>>>>> it is a regular behavior to reply to a BYE message with authentication
>>>>> challenge or not. I could not find any hint there.
>>>>>
>>>>> How difficult is it to change this behavior and wait for confirmation
>>>>> before terminating the entire connection ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Andre
>>>>> -----
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>>> [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
>>>>> _______________________________________________
>>>>> opensipstack-devel mailing list
>>>>> ope...@li...
>>>>> [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
>>>>> -----
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG - [http://www.avg.com]
>>>>> Version: 8.0.175 / Virus Database: 270.8.2/1743 - Release Date: 10/24/2008 8:33 AM
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>>
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>> [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
>>>> _______________________________________________
>>>> opensipstack-devel mailing list
>>>> ope...@li...
>>>> [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]-----
>>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
>>> -----
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - [http://www.avg.com]
>>> Version: 8.0.175 / Virus Database: 270.8.3/1748 - Release Date: 10/26/2008 7:53 PM
>>>
>>>
>>>
>>>
>>
>>
>> -----
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> [http://moblin-contest.org/redirect.php?banner_id=100&url=/]
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> [https://lists.sourceforge.net/lists/listinfo/opensipstack-devel]
>>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.9.4/1793 - Release Date: 11/16/2008 7:58 PM
>
>
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-11-18 14:28:53
|
Thanks for the clarification. I tried Sjphone and Kapanga and the problem occurs. With other phones/softphones no problem. I don't know... I'll investigate to know if those softphone are bugged. For now thanks for the support.
Regards,
Antonio.
> {quote:title=Guest wrote:}{quote}Got your log. Same case, but not quite. In your case the UA which
> offered QOP did not send "any" authorization header in BYE. This is a
> UA problem, not OpenSBC. Your UA should have sent a new authorization
> header to update the previous authorization send in the INVITE
> challenge. OpenSBC does not participate in mid dialog request
> authentication except acting as a relay. It is also impossible for
> OpenSBC to reproduce the QOP state without knowing the exact password
> used to produce the original response. If OpenSBC "CAN" do this, then
> QOP is in big trouble for obvious reasons.
>
> OpenSIPStack Forum wrote:
> > I have the exact same problem with the latest CVS version 1.1.5-36.
> >
> > The softswitch replies to the BYE with a "400 Bad Request".
> >
> >
> >
> > I'll provide level 5 log and wireshark capture.
> >
> >
> >
> > Regards.
> >
> >
> >
> > Antonio.
> >
> >
> >
> >
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X