Re: [OpenSIPS-Devel] About b2b_entities

2010-11-04 Thread Anca Vamanu
Hi,

Please update the code from svn trunk- I have fixed this issue with 
Update in the commit I made yesterday.

Regards,

-- 
Anca Vamanu
www.voice-system.ro



On 11/03/2010 03:15 PM, Emmanuel BUU wrote:
Le 02/11/10 17:46, Olivier Détour a écrit :

 Hi,

 I'm using v1.6 from SVN, and I would like to report an UPDATE in my
 b2b client module, but entities reply on INVITE with 491 error code.
 Here is my test (from RFC 3311):

 Caller  INVITE---   B2B
 ---180
 --UPDATE--
 -- 491---

 In sources, this reply happen when the call state is proceeding, but I
 don't think it is RFC compliant ?

  
 Hello,

 To my knowledge, it is RFC compliant. UDPATE has been added to enable
 call to be reconfigured before and after dialog is open.
 This is the main difference with re - INVITE

 Emmanuel


___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] About b2b_entities

2010-11-04 Thread Anca Vamanu
Hi Olivier,

This means that the ACK is not matched with the transaction. Can you 
send a network trace with the 3 packages? Maybe there is something wrong 
with the ACK.

Regards,

-- 
Anca Vamanu
www.voice-system.ro



On 11/03/2010 07:08 PM, Olivier Détour wrote:
 Hi,

 I found another bug today:
 If I create an UAS and reject call, the 4XX Reply is resent. I release
 my UAS after the ACK.

 Caller  INVITE---  B2B
   ---4XX
   ACK---
   -- 4XX---
   -- 4XX---
   -- 4XX---
   -- 4XX---
   


 Regards,





___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] About b2b_entities

2010-11-04 Thread Olivier Détour
Here is my PCAP.

On Thu, Nov 4, 2010 at 12:18 PM, Anca Vamanu a...@opensips.org wrote:
 Hi Olivier,

 This means that the ACK is not matched with the transaction. Can you
 send a network trace with the 3 packages? Maybe there is something wrong
 with the ACK.

 Regards,

 --
 Anca Vamanu
 www.voice-system.ro



 On 11/03/2010 07:08 PM, Olivier Détour wrote:
 Hi,

 I found another bug today:
 If I create an UAS and reject call, the 4XX Reply is resent. I release
 my UAS after the ACK.

 Caller  INVITE---  B2B
           ---4XX
           ACK---
           -- 4XX---
           -- 4XX---
           -- 4XX---
           -- 4XX---
           


 Regards,





 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




-- 
Olivier Détour


404_not_found.pcap
Description: Binary data
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] bug in t_msgbuilder.c

2010-11-04 Thread Kennard White
Another developer was doing some client-side development, and noticed the
extra byte at the end of a CANCEL message.

Kennard

On Thu, Nov 4, 2010 at 2:59 AM, Bogdan-Andrei Iancu
bog...@voice-system.rowrote:

 Hi Kennard,

 Thanks for the fix - it a very stupid bug...hard to imagine how 1 ended
 up instead of 0 :-/

 I applied your patch with the fix only - I try to sync the code with the
 1.6 branch to make the backporting easier.

 BTW, how you spotted it - some trailing chars in ACKs and CANCELs ?

 REgards,
 Bogdan

 Kennard White wrote:
  Hi,
 
  There appears to be a minor bug in t_msgbuilder.c in HEAD. The
  build_local() function is off-by-one when computing the length of the
  message it is going to build. End result is that locally generated
  messages (CANCEL and some ACKs) have an extra garbage byte at end of
  message. The garbage byte happens to be a null. Other SIP stacks
  complain about this extra byte.
 
  The problem is this:
 (Trans-extra_hdrs.s?Trans-extra_hdrs.len:1)
  The 1 should be a 0 to be consistent with the later code.
 
  I've included patch that fixed this and changes the length computation
  to match the order in which the message it built. It also breaks up
  the length computation into groups. Goal is to make it easier to find
  future length computation errors -- took 4 hours to find this
  relatively simple error. I also added a final assert -- not sure what
  the opensips policy is on asserts.
 
  Thanks,
  Kennard
 
 
 
  
 
  ___
  Devel mailing list
  Devel@lists.opensips.org
  http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
 


 --
 Bogdan-Andrei Iancu
 OpenSIPS Bootcamp
 15 - 19 November 2010, Edison, New Jersey, USA
 www.voice-system.ro


 ___
 Devel mailing list
 Devel@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel