[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] SIP stack crash - comments please.
From:       <ravishankar.shiroor () wipro ! com>
Date:       2005-12-26 7:12:19
Message-ID: 135D6BCE62B79145A7645D4F27C251E003D264 () blr-m2-msg ! wipro ! com
[Download RAW message or body]


Asheesh,

Few points to consider:

Was there any difference in the way resip was built for the two
machines?
For example was NDEBUG defined for one of them and not for the other?

It might also help to see where is the assert coming and try to
correlate it to any inconsistencies.

Race conditions can lead to assert aborts in resip (for example if you
hold invalid dialog handler and
Do some operation on it after dialog is terminated from the other end
etc).

Regards,
Ravi.

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Asheesh
Joshi
Sent: Saturday, December 24, 2005 11:04 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] SIP stack crash - comments please.

Hi,
	 I am not sure if this is the right forum to ask this question -
but I will ask anyways as SIP stack is involved here. I have a B2BUA
server on ( reciprocate ) SIP stack running on two machines -  1st  a
Pentium 4 based PC running a
Linux Enterprise server   and 2nd  a Celeron based PC running a Linux
Enterprise server. Both the Linux are same versions.  The B2BUA server
is a multi threaded application running on linux.
	Well the two machines are not clean in the sense that other
installations have been done time and again on these two PCs and hence
libraries may differ.
	Now here is the problem part,   the B2BUA runs pretty well on
the P4, but
it often and frequently crashes on the Celeron machine during our
sanity/system testing. The crashes are as simple as a call being made
and then being disconnected. We typically get a segmentation fault or an
assert abort.
	I want to know does the speed of the machine, or a difference in
libraries or something can cause this behavior indifference between the
two nodes
running the same code ?   Is it that because of Celeron being slower, we
are
seeing some "potential" race conditions when traffice is more which are
not arising in the P4 ?
	Has anyone been through this experience before and suggest some
pointers as to how to go about debugging or finding the cause of such
problems.
-Regards
Asheesh.




-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Sigrid
Thijs
Sent: Friday, December 23, 2005 8:41 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] maddr in From and To headers

Hi,

I have a question about maddr parameters in From and To headers. I read
section 19.1.1 of RFC 3261, and my interpretation is that the
maddr-parameter is a parameter of the uri, and not of a From or To
header.

 From that section I understand that the maddr parameter is not allowed
in the From and To headers and should be ignored.

But what if we receive a request with the maddr parameter as follows:

To: <sip:0043720214980@domain.com>;tag=4944;maddr=host1
From: <sip:5@domain.com>;tag=1215769166;maddr=host2

Syntaxically, it's not incorrect (To and From headers can contain any
'param=value' pair), but I guess it's not the correct use of the maddr
parameter eather?

The problem is that we clone the To and From header (and add a to-tag if
necessary), so if we receive a request with maddr parameter in To and
> From header (or the uri) the maddr parameter is also present in the
response. The question is, should the UA be aware that the maddr
parameter can also occur as a parameter of the From header. Should it be
stripped from the To and From header in the response?

kind regards,
Sigrid Thijs
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


The information contained in this electronic message and any attachments to this \
message are intended for the exclusive use of the addressee(s) and may contain \
proprietary, confidential or privileged information. If you are not the intended \
recipient, you should not disseminate, distribute or copy this e-mail. Please notify \
the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check \
this email and any attachments for the presence of viruses. The company accepts no \
liability for any damage caused by any virus transmitted by this email.

www.wipro.com


[prev in list] [next in list] [prev in thread] [next in thread]