Re: [OpenSIPStack] OpenSBC UpperRegistration Query

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I meant the OpenSIPStack library.  Not OpenSBC.  Are you using the latest 
library as well?

--------------------------------------------------
From: "Ramu" <con...@gm...>
Sent: Tuesday, April 14, 2009 2:42 PM
To: "Joegen Baclor" <jb...@so...>
Cc: <ope...@li...>
Subject: Re: [OpenSIPStack] OpenSBC UpperRegistration Query

> Hi,
>
> Yes Am using latest version.  Following are my version details:
>
> [root@as1 distrib]# ./opensbc -v
> Product Name: OpenSBC
> Manufacturer: opensipstack.org
> Version     : 1.1.5-96
> System      : Linux-i686 2.6.18-92.1.18.el5.028stab060.2PAE
> Release-Date: Mar 30 2009 16:27:46
>
>
> On Tue, Apr 14, 2009 at 11:26 AM, Joegen Baclor 
> <joe...@gm...>wrote:
>
>> Ramu,
>>
>> By any chance, are you using the recent version of the OpenSIPStack 
>> library
>> as well?  There was a bug in record-routing in previous commits where the
>> port is not sepcified in the Record-Route.   It seems the log indicates 
>> that
>> you are suffering from this bug
>>
>> Joegen
>>
>> --------------------------------------------------
>> From: "Joegen Baclor" <joe...@gm...>
>> Sent: Tuesday, April 14, 2009 1:17 PM
>> To: "Ramu" <con...@gm...>; <
>> ope...@li...>
>>
>> Subject: Re: [OpenSIPStack] OpenSBC UpperRegistration Query
>>
>>  I GREPed all the ACKs sent by opensbc from the log you sent.  Which 
>> among
>>> this ACK requests are getting sent to the the wrong destination (DST:)?
>>>
>>> 2009/04/02 15:45:59.029 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 59.93.81.139:55128:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=421
>>> 2009/04/02 15:45:59.035 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:45:59.039 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:45:59.540 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:45:59.545 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:46:00.041 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:46:00.350 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:46:01.045 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:46:01.354 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:46:03.054 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:46:03.363 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:46:03.557 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:46:03.866 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>> 2009/04/02 15:46:04.060 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5070:UDP  SRC: 66.42.9.197:6060 enc=0
>>> bytes=496
>>> 2009/04/02 15:46:04.369 INF: [CID=0x9a9e4b05] >>> ACK
>>> sip:2000@59.93.81.139:55128;rinstance=67ffc600210dc67d SIP/2.0
>>> Method(ACK) DST: 66.42.9.197:5060:UDP  SRC: 66.42.9.197:5062 enc=0
>>> bytes=466
>>>
>>>
>>> From: Ramu
>>> Sent: Tuesday, April 14, 2009 12:58 PM
>>> To: Joegen Baclor ; ope...@li...
>>> Subject: Re: [OpenSIPStack] OpenSBC UpperRegistration Query
>>>
>>>
>>> Hi,
>>>
>>> Thanks for your quick reply.
>>>
>>> I am here with attaching level 5 log files
>>> 1) opensbc-invite-private-contact.zip file, it shows ACK problem (ACK is
>>> going to private contact)
>>> 2) opensbc-register.zip file, it shows REGISTER log file.
>>>
>>>
>>>
>>> On Tue, Apr 14, 2009 at 6:38 AM, Joegen Baclor <joe...@gm...>
>>> wrote:
>>>
>>>  I don't get it.  ACK is a mid-dialog request and has nothing to do with
>>> the
>>>  Registration contact.  The registration contact would only be 
>>> significant
>>>  when routing INVITE.   The fact that the call reaches the destination 
>>> UA
>>>  proves that everything is in order as far as routing through the
>>> registrar
>>>  is concerned.   Please send an ethereal capture as well as the level 5
>>> log
>>>  of OpenSBC so we can see what is exactly happening to the ACK.
>>>
>>>  Joegen
>>>
>>>  --------------------------------------------------
>>>
>>>  From: "Ramu" <con...@gm...>
>>>
>>>  Sent: Tuesday, April 14, 2009 1:05 AM
>>>
>>>  To: <ope...@li...>
>>>
>>>  Subject: [OpenSIPStack] OpenSBC UpperRegistration Query
>>>
>>>
>>>  > Hi,
>>>  >
>>>  > We are using OpenSBC in upper registration mode.
>>>  >
>>>  > When we register phones OpenSBC storing private contact (please see 
>>> the
>>>  > attachment)
>>>  >
>>>  > As it is storing private contact when we try to make calls to
>>> registered
>>>  > user ACK is going to private contact which is not reaching phone.
>>>  >
>>>  > Please see full details of this problem in below thread.
>>>  >
>>>  > http://www.opensourcesip.org:8080/clearspacex/message/9442
>>>  >
>>>  > I appreciate your hep.
>>>  >
>>>  > Thanks,
>>>  > Ramu
>>>  >
>>>
>>>
>>>
>>>
>>>  >
>>> ------------------------------------------------------------------------------
>>>  > This SF.net email is sponsored by:
>>>  > High Quality Requirements in a Collaborative Environment.
>>>  > Download a free trial of Rational Requirements Composer Now!
>>>  > http://p.sf.net/sfu/www-ibm-com
>>>
>>>
>>>
>>>  > _______________________________________________
>>>  > opensipstack-devel mailing list
>>>
>>>  > ope...@li...
>>>
>>>  > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>  >
>>>
>>>
>>>
>>>  >
>>>  > No virus found in this incoming message.
>>>  > Checked by AVG - www.avg.com
>>>  > Version: 8.0.238 / Virus Database: 270.11.54/2055 - Release Date:
>>> 04/12/09
>>>  > 13:14:00
>>>  >
>>>
>>>
>>>  ------------------------------------------------------------------------------
>>>  This SF.net email is sponsored by:
>>>  High Quality Requirements in a Collaborative Environment.
>>>  Download a free trial of Rational Requirements Composer Now!
>>>  http://p.sf.net/sfu/www-ibm-com
>>>  _______________________________________________
>>>  opensipstack-devel mailing list
>>>
>>>  ope...@li...
>>>
>>>  https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>>
>>>
>>>
>>> --
>>> Ramu
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.238 / Virus Database: 270.11.55/2057 - Release Date: 
>>> 04/13/09
>>> 17:56:00
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> High Quality Requirements in a Collaborative Environment.
>>> Download a free trial of Rational Requirements Composer Now!
>>> http://p.sf.net/sfu/www-ibm-com
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>
>>
>>
>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.238 / Virus Database: 270.11.55/2057 - Release Date: 
>>> 04/13/09
>>> 17:56:00
>>>
>>>
>
>
> -- 
> Ramu
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>

>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.11.55/2057 - Release Date: 04/13/09 
> 17:56:00
> 