res_pjsip_nat: Rewrite route set when required.
authorMark Michelson <mmichelson@digium.com>
Tue, 23 Jun 2015 22:43:31 +0000 (17:43 -0500)
committerJoshua Colp <jcolp@digium.com>
Fri, 26 Jun 2015 14:53:26 +0000 (09:53 -0500)
commit700606a6598344dc80e5719048bee956d4199fb2
treee1d83196f330368a1c67458286f5e27694ed2767
parent39c79cd6fb661269b8505247a2dea1ae7b7aad81
res_pjsip_nat: Rewrite route set when required.

When performing some provider testing, the rewrite_contact option was
interfering with proper construction of a route set when sending an ACK
after receiving a 200 OK response to an INVITE.

The initial INVITE was sent to address sip:foo. The 200 OK had a Contact
header with URI sip:bar. In addition, the 200 OK had Record-Route
headers for sip:baz and sip:foo, in that order. Since the Record-Route
headers had the lr parameter, the result should have been:

* Set R-URI of the ACK to sip:bar.
* Add Route headers for sip:foo and sip:baz, in that order.

However, the rewrite_contact option resulted in our rewriting the
Contact header on the 200 OK to sip:foo. The result was:

* R-URI remained sip:foo.
* We added Route headers for sip:foo and sip:baz, in that order.

The result was that sip:bar was not indicated in the ACK at all, so the
far end never received our ACK. The call eventually dropped.

The intention of rewrite_contact is to rewrite the most immediate
destination of our SIP request to be the same address on which we
received a request or response. In the case of processing a SIP response
with Record-Route headers, this means that instead of rewriting the
Contact header, we should instead rewrite the bottom-most Record-Route
header. In the case of processing a SIP request with Record-Route
headers, this means we rewrite the top-most Record-route header.
Like when we rewrite the Contact header, we also ensure to update
the dialog's route set if it exists.

ASTERISK-25196 #close
Reported by Mark Michelson

Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f
res/res_pjsip.c
res/res_pjsip_nat.c