[reSIProcate] UdpTransport problem

[Scott Godin]

I haven't really looking into it much - but I wonder if the following recent
change could be causing the problem:

http://list.sipfoundry.org/archive/resiprocate-devel/msg01199.html


-----Original Message-----
From: Alan Hawrylyshen [mailto:alan at jasomi.com] 
Sent: Tuesday, August 10, 2004 1:31 PM
To: sharon paisner
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] UdpTransport problem


On Aug 9, 2004, at 11:14, sharon paisner wrote:

> I believe I've found the problem...
> [snip]
> If we receive a 200, and the state is "completed", we don't pass the
> message along to the TU... is this the correct behavior? I would think
> even 200s completing a transaction should be passed up to the UA.
>
> --Sharon
>
>


Sharon;

The 1st 200 will arrive when the TransactionState is NOT in completed.  
This will result in the sendToTU() call. Subsequent 200s will arrive in 
the Completed state and be suppressed by the code you quote. The intent 
of this code is to catch retransmissions at the Transaction Level. This 
code appears to work for us, our product has been using the UDP 
transport and doing both Invite and Non-Invite transactions for over a 
year using this codebase.

It is possible that your SIP messages are not well formed. Do they have 
strict CRLF at the end of each line and a CRLFCRLF pair at the end of 
the headers? This is important.


Alan Hawrylyshen
Jasomi Networks Inc.
http://jasomi.com/
a l a n a t j a s o m i d o t c o m

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel