INVITE/CANCEL may be sent to different servers than the INVITE when DNS SRV is used (thanks Alexei Kuznetsov for the report)

[bennylp]

RFC 3263 says:

the ACK for non-2xx SIP responses to INVITE MUST be sent to the same host. Furthermore, a CANCEL for a particular SIP request MUST be sent to the same SIP server that the SIP request was delivered to.

With PJSIP, CANCEL initiates a fresh DNS SRV hence it's possible that it may resolve to different server than the original INVITE.

ACK for non-3xx belongs to the same transaction as the INVITE hence it will reuse the transaction's transport and destination address.

This also fixed the problem where INVITE with authentication may be sent to different server due to DNS SRV, after 401/407 response is received.

See also ticket #936

[bennylp]

Provisional patch, fixing the issue by inserting a hidden Route header to the CANCEL and INVITE request. This patch will not work if strict route is used, hence alternative solution is needed.

[bennylp]

Fixed ticket #917, #936, and #967:

• #917: CANCEL may be sent to different servers than the INVITE when DNS SRV is used (thanks Alexei Kuznetsov for the report)
• #936: CANCEL must be sent with TCP if the INVITE was sent with TCP because of 1300 bytes message size/MTU limit (thanks Johan Lantz for the report)
• #967: Wrong Route header generation in CANCEL request with strict route

Save the server address(es) found by resolution process to tx_data, which is copied to CANCEL request. CANCEL request then uses this address rather than starting a fresh server resolution.

Also fix the problem with swapped Route/request URI in the CANCEL request when strict route is used (ticket #967)

[bennylp]

The above was in r2932

[bennylp]

Note:

• the above fix also affects request retry because of authentication (the 401 and 407 response). With the fix above, the request retry will not trigger DNS resolution.