ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app

This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
    only transfer channels to a SIP URI, i.e., you had to pass
    'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
    still supported, it is somewhat unintuitive - particularly in a world full
    of endpoints. As such, we now also support specifying the PJSIP endpoint to
    transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
    updating its Contact header. Alas, that resulted in the forwarding
    destination set by the dialplan application/ARI resource/whatever being
    rewritten with very incorrect information. Hence, we now don't bother
    updating an outgoing response if it is a 302. Since this took a looong time
    to find, some additional debug statements have been added to those modules
    that update the Contact headers.

Review: https://reviewboard.asterisk.org/r/4316/

ASTERISK-24015 #close
Reported by: Private Name

ASTERISK-24703 #close
Reported by: Matt Jordan



git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431717 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 4 insertions, 1 deletions

diff --git a/res/res_pjsip_multihomed.c b/res/res_pjsip_multihomed.c
index ca56b7c47..e1abff34f 100644
--- a/res/res_pjsip_multihomed.c
+++ b/res/res_pjsip_multihomed.c
@@ -146,12 +146,15 @@ static pj_status_t multihomed_on_tx_message(pjsip_tx_data *tdata)
 	if (tdata->msg->type == PJSIP_REQUEST_MSG || !(cseq = pjsip_msg_find_hdr(tdata->msg, PJSIP_H_CSEQ, NULL)) ||
 		pj_strcmp2(&cseq->method.name, "REGISTER")) {
 		pjsip_contact_hdr *contact = pjsip_msg_find_hdr(tdata->msg, PJSIP_H_CONTACT, NULL);
-		if (contact && (PJSIP_URI_SCHEME_IS_SIP(contact->uri) || PJSIP_URI_SCHEME_IS_SIPS(contact->uri))) {
+		if (contact && (PJSIP_URI_SCHEME_IS_SIP(contact->uri) || PJSIP_URI_SCHEME_IS_SIPS(contact->uri))
+			&& !(tdata->msg->type == PJSIP_RESPONSE_MSG && tdata->msg->line.status.code / 100 == 3)) {
 			pjsip_sip_uri *uri = pjsip_uri_get_uri(contact->uri);
 
 			/* prm.ret_addr is allocated from the tdata pool OR the transport so it is perfectly fine to just do an assignment like this */
 			pj_strassign(&uri->host, &prm.ret_addr);
 			uri->port = prm.ret_port;
+			ast_debug(4, "Re-wrote Contact URI host/port to %.*s:%d\n",
+				(int)pj_strlen(&uri->host), pj_strbuf(&uri->host), uri->port);
 
 			pjsip_tx_data_invalidate_msg(tdata);
 		}