Re: [reSIProcate] Here is a less verbose rendition of my problem.
Alan Hawrylyshen wrote:
On 2006.03.22, at 02:26 , John Draper wrote:
This is the problem...
/Volumes/TFKCrunch/Crunch/Development/newSipTestApp/resiprocate/
TransactionS
tate.cxx:357 | discarding stray response: SipResp: 200
tid=OnIn4420eef60913 cseq=INVITE
contact=213.167.79.25:5060 / 1 from(wire)
Why would resip consider my 200 OK response a stray and disgard it?
Could it be a timeout issue? If so, then how do I lengthen the time
I wait for the other party to answer?
Because the branch parameter does not match the original invite?
Check the top-most via's branch parameter in the INVITE you send. I
assure you it was NOT OnIn4420eef60913, as is shown here in the
response.
In fact it was magic-cookie-OnIn....., which is NOT a reSIProcate
generated branch parameter.
So, do you think this is the SIP server changing the branch parameter.
I also tested this
using the X-Lite SIP phone on the Mac. It also rejected the call. I'll
spare you the logs,
but they are similar... IE: 100 trying (twice) 180 ringing (twice)
100 trying (once)
408 error. So I'm suspecting it's their sip server. I was referring to the
special "Call test" number they implemented for testing our stuff.
In sip, requests and responses are matched using the branch parameter.
(Except 2543bis9 devices, which are hopefully dying)
What SIP implementation is this 'test device'?
I also found out the sip server was written custom... it's not a Canned or
packaged one. Not sure what box it's running on... I try not to be too
inquisitive... They also have an Audio relay proxy server, in instances
when it's determined the NAT is symmetrical.
We are not using STUN, instead I'm sending them special packets which
they use to determine our network type.... and firewall checks. Then,
under certain conditions, the Audio Relay server kicks in and sends me
a different sdp record, assuming I'm able to talk to the SIP
server and not the remote client for whatever reason.
John