Loosing route after re-INVITE when SIP server is behind NAT

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start audio call from device A
2. Accept call on device B
3. Upgrade call to video on device A
4. Try rotate device B or terminate call

What is the expected output? What do you see instead?
No changes on device A.

What version of the product are you using? On what operating system?
Latest doubango used for ios.

Please provide any additional information below.
SIP server is behind NAT. See also Issue 237.

Original issue reported on code.google.com by denis.tr...@gmail.com on 20 Jun 2013 at 3:55

[GoogleCodeExporter]

Please attach network trace (wireshark trace)

Original comment by boss...@yahoo.fr on 26 Jun 2013 at 8:59

• Changed state: Accepted

[GoogleCodeExporter]

Attached. 

Original comment by denis.tr...@gmail.com on 27 Jun 2013 at 6:17

Attachments:

• reinvite.pcap

[GoogleCodeExporter]

- The first INVITE from the client-1 is at pkt #6 and there is no route (src 
port = 50277).
- The final response(200 OK) to the first INVITE is at pkt #26 (dst port = 
50277). There is a record route equal to "<sip:184.69.143.252;lr=on>".
- The second INVITE (pkt #45) is from client-2 instead of client-1 as src port 
= 54734 and request Uri contain src port = 50277.
- The second INVITE is received at client-1 (pkt #48) without record route.
- The 200 OK from client-1 to client-2 (pkt #51) contains record route which is 
correct.
- At pkt #54 an INFO message is sent from client-1 to client and contains a 
route header. This is correct.
- All subsequent INFO messages from client-1 or client-2 contains the route 
header.

For us, all is correct. 
Could you please explain what you think is an issue?
What you mean by "loosing route"?

Original comment by boss...@yahoo.fr on 2 Jul 2013 at 8:28

[GoogleCodeExporter]

"Loosing route" means that packets from device B does not accept device 
A(packet #89 with error 408). I see some differences in INVITE and re-INVITE 
requests: first INVITE has no "Route: <sip:184.69.143.252;lr=on>" field and 
also has no "tag" attribute in "To" field.

Also I attached network trace without reinvite. 

Original comment by denis.tr...@gmail.com on 2 Jul 2013 at 4:35

Attachments:

• only_invite.pcap

[GoogleCodeExporter]

I asked because SIP define route loosing ("lr" parameter) but doesn't mean what 
you're describing.
The differences between the initial and second INVITE is correct.
A- First INVITE there is route because we haven't received a record-route (in 
the 200 OK) yet
B- The tag is missing because it's an un-established dialog (sme apply to 
SUBSCRIBE, REGISTER...)
C- The second INVITE contains route because of the record route in the first 
200 OK.

100% sure that A and B are correct (see RFC 3261). I'll check C.

Original comment by boss...@yahoo.fr on 2 Jul 2013 at 11:39

[GoogleCodeExporter]

I check RFC 3261 and confirm that C is also correct: The reINVITE must contain 
a route header mirroring the record-rooute in the 200 OK.
If you try with any other SIP client you should have same result. There is 
probably a problem in your server configuration.

Original comment by boss...@yahoo.fr on 5 Jul 2013 at 1:16

[GoogleCodeExporter]

You're right. I fixed server configuration. You can close this issue.

Original comment by denis.tr...@gmail.com on 22 Jul 2013 at 9:29

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 22 Jul 2013 at 5:51

• Changed state: Done