Re: [Sip] [Sip-implementors] Request URI and TO heasder "user" part is different

"WORLEY, DALE R (DALE)" <dworley@avaya.com> Thu, 18 March 2010 17:52 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7613A6900 for <sip@core3.amsl.com>; Thu, 18 Mar 2010 10:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.034
X-Spam-Level:
X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkN4vo7nN4Yk for <sip@core3.amsl.com>; Thu, 18 Mar 2010 10:52:39 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 0DF523A6A2E for <sip@ietf.org>; Thu, 18 Mar 2010 10:52:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.51,268,1267419600"; d="scan'208";a="8106916"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Mar 2010 13:52:50 -0400
X-IronPort-AV: E=Sophos;i="4.51,268,1267419600"; d="scan'208";a="443074584"
Received: from unknown (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Mar 2010 13:52:20 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Thu, 18 Mar 2010 13:52:19 -0400
From: "WORLEY, DALE R (DALE)" <dworley@avaya.com>
To: Nitin Kapoor <nitinkapoorr@gmail.com>, "sip@ietf.org" <sip@ietf.org>, "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu>
Date: Thu, 18 Mar 2010 13:52:19 -0400
Thread-Topic: [Sip-implementors] Request URI and TO heasder "user" part is different
Thread-Index: AcrGqSMShX/o3HM/TsmbMQKjBZnrUgAGcMUD
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21F6E96F5A@DC-US1MBEX4.global.avaya.com>
References: <c80c92d1003180741s31691d6cg7d7f41ebe8bd2c6f@mail.gmail.com>
In-Reply-To: <c80c92d1003180741s31691d6cg7d7f41ebe8bd2c6f@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Sip] [Sip-implementors] Request URI and TO heasder "user" part is different
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2010 17:52:40 -0000

_______________________________________
From: sip-implementors-bounces@lists.cs.columbia.edu [sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor [nitinkapoorr@gmail.com]

To: sip:7139229867@64.245.120.88 <sip%3A7139229867@64.245.120.88>

_______________________________________________

In general, a SIP element should not consider the value of the To header.  However, the To header is required to conform to a specific syntax, and this To header does not.  The basic structure for this type of To header is "display-name <SIP-URI>".  However, if display-name is not quoted, it is restricted to being a "token", and "token" may not contain ":" or "@".  The text between <...> is supposed to be a SIP URI, but the ":" is replaced by "%3A", and there is no escaping defined for that position.  See section 25.1 of RFC 3261 for the details.

So until you correct the To header (who is generating it?) there is no reason to expect any SIP element to accept the request.

Dale