-------- Mensaje original -------- Return-Path: sr-users-bounces@lists.sip-router.org Delivered-To: a_villacis@palosanto.com Received: from palosanto.com by mail.palosanto.com (Dovecot) with LMTP id 1RBBAn9f2VPPOgAA3RMWGw for a_villacis@palosanto.com; Wed, 30 Jul 2014 16:14:09 -0500 Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with ESMTP id BD82513C027E for a_villacis@palosanto.com; Wed, 30 Jul 2014 16:14:09 -0500 (ECT) X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-1000 required=6.31 tests=[AWL=-0.333, BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, WEIRD_PORT=0.001] autolearn=unavailable Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEfbzVEOoMof for a_villacis@palosanto.com; Wed, 30 Jul 2014 16:14:04 -0500 (ECT) Received: from www.kamailio.org (main.kamailio.org [193.22.119.66]) by palosanto.com (Postfix) with ESMTPS id 4412B13C0280 for a_villacis@palosanto.com; Wed, 30 Jul 2014 16:13:56 -0500 (ECT) Received: from localhost ([127.0.0.1] helo=main.kamailio.org ident=list) by www.kamailio.org with esmtp (Exim 4.72) (envelope-from sr-users-bounces@lists.sip-router.org) id 1XCbCY-0000J5-PL; Wed, 30 Jul 2014 23:14:22 +0200 Received: from lab2.palosanto.com ([201.234.196.173] helo=palosanto.com) by www.kamailio.org with esmtp (Exim 4.72) (envelope-from a_villacis@palosanto.com) id 1XCbCU-0000II-SD for sr-users@lists.sip-router.org; Wed, 30 Jul 2014 23:14:19 +0200 Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with ESMTP id 5BC5613C0280 for sr-users@lists.sip-router.org; Wed, 30 Jul 2014 16:13:43 -0500 (ECT) X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY5HkVjL2_h0 for sr-users@lists.sip-router.org; Wed, 30 Jul 2014 16:13:39 -0500 (ECT) Received: from avillacis.palosanto.com (avillacis.palosanto.com [192.168.3.2]) by palosanto.com (Postfix) with ESMTPSA id 3DFFD13C0279 for sr-users@lists.sip-router.org; Wed, 30 Jul 2014 16:13:39 -0500 (ECT) Message-ID: 53D96020.2040508@palosanto.com Date: Wed, 30 Jul 2014 16:14:08 -0500 From: Alex Villací­s Lasso a_villacis@palosanto.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org Content-Type: multipart/mixed; boundary="------------030501020507030206060205" Subject: [SR-Users] kamailio routes packets with invalid From/To headers with uac.restore_mode=auto when incoming packet does not use exact same replaced From/To header X-BeenThere: sr-users@lists.sip-router.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Kamailio (SER) - Users Mailing List sr-users@lists.sip-router.org List-Id: "Kamailio (SER) - Users Mailing List" <sr-users.lists.sip-router.org> List-Unsubscribe: http://lists.sip-router.org/cgi-bin/mailman/options/sr-users, mailto:sr-users-request@lists.sip-router.org?subject=unsubscribe List-Archive: http://lists.sip-router.org/pipermail/sr-users List-Post: mailto:sr-users@lists.sip-router.org List-Help: mailto:sr-users-request@lists.sip-router.org?subject=help List-Subscribe: http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users, mailto:sr-users-request@lists.sip-router.org?subject=subscribe Sender: sr-users-bounces@lists.sip-router.org Errors-To: sr-users-bounces@lists.sip-router.org

I am currently handling a system that runs kamailio and asterisk in the same machine. The kamailio instances are being used to emulate multiple SIP domains, by means of From/To mangling of incoming packets, which are then routed to Asterisk. The attached kamailio.cfg does this work.

There is an problem when handling SUBSCRIBE requests (as required for BLF and voicemail indications). My configuration is written so that these SUBSCRIBE requests are not handled by kamailio, but instead routed to asterisk. There is a failure to check From/To headers to see whether NOTIFY packets generated as part of a subscription can be restored using the information in Record-Route. The end result is that kamailio ends up sending packets with garbled tags that are (rightly) rejected by the SIP endpoint.

The following is an example that demonstrates the issue (using Jitsi as endpoint):

After registration, Jitsi sends a SUBSCRIBE request:

SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0 Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE From: "avillacisIM" sip:avillacisIM@pbx.villacis.com;tag=bf427f4a To: "avillacisIM" sip:avillacisIM@pbx.villacis.com Max-Forwards: 70 Contact: "avillacisIM" sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Event: message-summary Accept: application/simple-message-summary Expires: 3600 Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Proxy-Authorization: Digest username="avillacisIM",realm="pbx.villacis.com",nonce="U9lZJlPZV/r06Xep/ukc1UzAIO0V3TbS",uri="sip:avillacisIM@pbx.villacis.com",response="0e18f4913c2693f6154c91f158fb17fe" Content-Length: 0

This packet is mangled by the configuration, and is sent to asterisk like this:

SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0 Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE From: "avillacisIM" sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080;tag=bf427f4a To: "avillacisIM" sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080 Max-Forwards: 69 Contact: "avillacisIM" sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com User-Agent: Jitsi2.5.5255Linux Event: message-summary Accept: application/simple-message-summary Expires: 3600 Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0 Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Content-Length: 0

The asterisk response for the SUBSCRIBE:

SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0;received=127.0.0.1;rport=5060 Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes From: "avillacisIM" sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080;tag=bf427f4a To: "avillacisIM" sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080;tag=as5562e95e Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE Server: Asterisk PBX 11.11.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Expires: 3600 Contact: sip:avillacisIM@127.0.0.1:5080;expires=3600 Content-Length: 0

This is in turn transformed back by kamailio, and sent to Jitsi like this:

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes From: "avillacisIM" sip:avillacisIM@pbx.villacis.com;tag=bf427f4a To: "avillacisIM" sip:avillacisIM@pbx.villacis.com;tag=as5562e95e Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE Server: Asterisk PBX 11.11.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Expires: 3600 Contact: sip:avillacisIM@127.0.0.1:5080;alias=127.0.0.1~5080~1;expires=3600 Content-Length: 0

Now asterisk wants to send a NOTIFY to the endpoint for the subscription. The NOTIFY looks like this:

NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport Max-Forwards: 70 Route: sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes,sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes From: "asterisk" sip:asterisk@127.0.0.1:5080;tag=as5562e95e To: sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=bf427f4a Contact: sip:asterisk@127.0.0.1:5080 Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 102 NOTIFY User-Agent: Asterisk PBX 11.11.0 Event: message-summary Content-Type: application/simple-message-summary Subscription-State: active Content-Length: 89

Messages-Waiting: no Message-Account: sip:*97@127.0.0.1:5080 Voice-Message: 0/0 (0/0)

Here is where the bug appears. The autoprocessing does not recognize that the From header (From: "asterisk" sip:asterisk@127.0.0.1:5080;tag=as5562e95e) from the above request has nothing to do with the saved information (vsf parameter). Instead, it blindly mangles the From header, and does not even run a sanity check on the result before routing it. The end result is shown below.

NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: sip:192.168.2.18;r2=on;lr=on;ftag=as5562e95e Record-Route: sip:127.0.0.1;r2=on;lr=on;ftag=as5562e95e Via: SIP/2.0/UDP 192.168.2.18;branch=z9hG4bK8333.8bfe7bc2bd554a8631f0d00d463b28ee.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport=5080 Max-Forwards: 69 From: "asterisk" sip:asterisk@12(.0.0.1:5080.....@127.0.0.1:5080;tag=as5562e95e To: sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com;tag=bf427f4a Contact: sip:asterisk@127.0.0.1:5080 Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 102 NOTIFY User-Agent: Asterisk PBX 11.11.0 Event: message-summary Content-Type: application/simple-message-summary Subscription-State: active Content-Length: 89

Messages-Waiting: no Message-Account: sip:*97@127.0.0.1:5080 Voice-Message: 0/0 (0/0)

From examination of the source code, the vsf and vst strings are base64 encodings of the result of XORing the byte strings of the old and new tags. For this to work, the headers of future packets should match. However, here kamailio does not realize that the header does not match (by the ftag), and also does not check that the resulting "restored" header is a valid header.