ReINVITE during the call upgrade overrides record-route with an empty value when the client is behind the NAT

[GoogleCodeExporter]

a) Before posting your issue you MUST answer to the questions otherwise it
will be rejected (invalid status) by us
b) Please check the issue tacker to avoid duplication
c) Please provide network capture (wireshark) or Android log (DDMS output)
if you want quick response

What steps will reproduce the problem?
1. Start an audio call 
2. Upgrade this call to video call
3. Getting an error that results in the client, which didn't initiate the 
upgrade, no longer receives any SIP commands. 

What is the expected output? What do you see instead?

Expect the usage of the initial record-route entry, which was created during 
the initial call. Instead, we get record-route being overwritten by the 
reINVITE, which makes it empty, therefore we get the error.

What version of the product or source code revision are you using? On what
operating system?

Version 2.0 revision 667
Running on iOS versions 5.0.1 and 4.3.5

Please provide any additional information below.

We already contacted you by email about the problem together with wireshark 
file. Here we file the formal issue.   

Original issue reported on code.google.com by maksa...@cs.ubc.ca on 13 Dec 2011 at 10:42

Attachments:

• sip_filtered.save

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 14 Dec 2011 at 9:48

• Changed state: Accepted

[GoogleCodeExporter]

We have some problem to understand what is the exact issue with the routes. In 
your capture there is only the initial INVITE and the reINVITE is missing. 
According to wireshark: [1388 bytes missing in capture file]
I guess the 200 OK of the reINVITE is at packet 44 because the CSeq doesn't 
match the initial INVITE. The record-route is inside the 183 response with lr 
enabled and I don't see why you expect them in the reINVITE.

Original comment by boss...@yahoo.fr on 14 Dec 2011 at 4:20

[GoogleCodeExporter]

After the initial INVITE (audio call), SIP server requests, if a client is 
behind the NAT, have a field "Route" filled in and everything works.  After 
reINVITE all the following requests don't have the "Route" field at all and the 
SIP server cannot find the client. We figured out that the SIP client 
(Doubango) sets the Route to null or empty string during the reINVITE. 
According to a server configuration, it doesn't expect nullification and the 
Route field is expected to contain initial value/shouldn't be cleared. We made 
a server hack to force sending the hardcoded record-route value during the 
reINVITE (same as during the INVITE) to test our hypothesis and it was 
confirmed. Sorry for the faulty wireshark file, I attached another one here.

Original comment by maksa...@cs.ubc.ca on 14 Dec 2011 at 11:04

Attachments:

• sip_unfiltered.save

[GoogleCodeExporter]

Sorry but still don't understand the issue :(
I don't see the relation between the client and the NAT. The client don't have 
any information about the NAT. It's up to the server to handle the NAT issue by 
adding the "record-routes" if needed and the client will copy them in the next 
request in reverse order as "routes".
The initial Route (The Proxy-CSCF address) in the INVITE is not for the NAT but 
a special case for 3GPP IMS scenario and is only added in the initial request. 
All is explained here: 
http://code.google.com/p/doubango/source/browse/branches/2.0/doubango/tinySIP/sr
c/dialogs/tsip_dialog.c#339. You can remove the "if" if you want to have the 
route in subsequent requests but it will not be conform to the standard.
In the attached capture, the reINVITE (pkt 1193) contains the routes, is it a 
patched version?
For example, the routes are added in the PRAK (pkt 124) request because the 
server returns the record routes in the 180 (pkt 119).

Original comment by boss...@yahoo.fr on 15 Dec 2011 at 12:42

[GoogleCodeExporter]

We know that NAT is handled by the server, that was not questionable. What I'm 
trying to explain is that after initial INVITE all following SIP requests to 
the server contain Route field because INVITE had Record-Route field in it, 
i.e. 693 INFO packet. But after reINVITE all following commands TO the SIP 
server FROM Doubango do NOT have Route field, i.e. packet 2480, BYE 5247, while 
they suppose to have this field. And it stops working properly.

Original comment by maksa...@cs.ubc.ca on 16 Dec 2011 at 9:20

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 6 Aug 2013 at 7:22

• Changed state: Invalid