From: Automerge script Date: Tue, 19 Jun 2012 16:22:39 +0000 (+0000) Subject: Merged revisions 369067 via svnmerge from X-Git-Tag: 10.7.0-digiumphones-rc1~32 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9c05926dca151ddfcaf4d957cc35418671f9fff6;p=thirdparty%2Fasterisk.git Merged revisions 369067 via svnmerge from file:///srv/subversion/repos/asterisk/branches/10 ................ r369067 | mmichelson | 2012-06-19 10:37:37 -0500 (Tue, 19 Jun 2012) | 17 lines Fix request routing issue when outboundproxy is used. Asterisk was incorrectly setting the destination of CANCELs and ACKs for error responses to the URI of the initial INVITE. This resulted in further requests, such as INVITEs with authentication credentials, to be routed incorrectly. Instead, when these CANCEL or ACKs are to be sent, we should simply keep the destination the same as what it previously was. There is no need to alter it any. (closes issue ASTERISK-20008) Reported by Marcus Hunger Patches: ASTERISK-20008.patch uploaded by Mark Michelson (license #5049) ........ Merged revisions 369066 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10-digiumphones@369083 65c4cc65-6c06-0410-ace0-fbb531ad65f3 --- diff --git a/channels/chan_sip.c b/channels/chan_sip.c index 5288f315a6..77ef3e996e 100644 --- a/channels/chan_sip.c +++ b/channels/chan_sip.c @@ -10737,10 +10737,9 @@ static int reqprep(struct sip_request *req, struct sip_pvt *p, int sipmethod, ui * final response. For a CANCEL or ACK, we have to send to the same destination * as the original INVITE. */ - if (sipmethod == SIP_CANCEL || - (sipmethod == SIP_ACK && (p->invitestate == INV_COMPLETED || p->invitestate == INV_CANCELLED))) { - set_destination(p, ast_strdupa(p->uri)); - } else if (p->route) { + if (p->route && + !(sipmethod == SIP_CANCEL || + (sipmethod == SIP_ACK && (p->invitestate == INV_COMPLETED || p->invitestate == INV_CANCELLED)))) { set_destination(p, p->route->hop); add_route(req, is_strict ? p->route->next : p->route); }