RE: [reSIProcate] UdpTransport problem
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@xxxxxxxxxx]
Sent: Tuesday, August 10, 2004 1:31 PM
To: sharon paisner
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel