Re: [stir] RFC 8224

Roman Shpount <roman@telurix.com> Tue, 20 April 2021 15:11 UTC

Return-Path: <roman@telurix.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727A3A277B for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 08:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lrfxueA8_ke for <stir@ietfa.amsl.com>; Tue, 20 Apr 2021 08:11:03 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9043A2779 for <stir@ietf.org>; Tue, 20 Apr 2021 08:11:03 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id q136so18686901qka.7 for <stir@ietf.org>; Tue, 20 Apr 2021 08:11:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RNdfAbFX+YbNTNQae6yAHU3tXc1PJGuGFsKk9vmSJAY=; b=u8St2foFdAJnxfpxWmnAdQMbC6eNj0tY+BAoyJBpKVehMYuQ1iatjNFHd+pY8Fn94x sVeG6F2EKoCRInBrtykySjaJ6faeHa1MviVU9Qt5jZtPBnhZNIWEzs3u4h1Xsp2+10bu w6KS3XVJHl3m3vQZKORBk/aXuLbDOh77D0ha9rkEds/fOvj2+IZxWNLDjQMCWiFFXfak QHjiV+ZwxBlii+189Evlq2hcPQbbGRI6yC2HPurudPmKlozDTpGdcZC7afufs3jZ31wY FM70hccSuhXMxWP3vEKTt99M2RMl3aLxyFfv0CmHPyiWc5QUcVdTgtJXl0e9owXGe4Dv W42w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RNdfAbFX+YbNTNQae6yAHU3tXc1PJGuGFsKk9vmSJAY=; b=ZLE6xTRjeKWYHaHwA47+ho8ZryZqWSrU2RuOO0bA2DXYJMmq8oTCjuuwwoylvlU7/d 4rX4u7BJok0I0A+jJ5Se5QniCWnHXbbHCz+s/HpeC6KTpFPlDGW0eqTiZt4Vd06LkW11 HDogGHO9EtpyXfJQz8R4kfnDsP80GXvYbrVxKgW9PHQlLpJjl2rJ56oy+BFqhf1yeqT9 YDmoeBXpOyWNkeAu4Enay4vSpYhjrIdgk1AKSChDiMxqDLIhY5tAJeEAFWljC0I2kZXY miOjbqhGxw7NeKFKWSkYnmgg5LbR1KaGR5KICzPbqzWLSixQkt5AM1eIKpIiEsQM7oX9 WcUw==
X-Gm-Message-State: AOAM530cgq7pL24+Jln4PJnBBoUoK6fbbwfbdhvD5jxAbgvohekBk4ep UADesI+kAr6DdcHW1XDFbWYXecQYCENaww==
X-Google-Smtp-Source: ABdhPJzz9aW6XYI0MY6MJ8WKqZDiw5VPkZVFIbrize6Nm4lPGYgqezuPGjpTjUKVBBQ+jXcRVO+05A==
X-Received: by 2002:a37:6606:: with SMTP id a6mr10717589qkc.165.1618931460243; Tue, 20 Apr 2021 08:11:00 -0700 (PDT)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id j9sm479762qtl.12.2021.04.20.08.10.58 for <stir@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 08:10:58 -0700 (PDT)
Received: by mail-yb1-f171.google.com with SMTP id g38so43366843ybi.12 for <stir@ietf.org>; Tue, 20 Apr 2021 08:10:58 -0700 (PDT)
X-Received: by 2002:a25:6c8a:: with SMTP id h132mr25418477ybc.454.1618931457814; Tue, 20 Apr 2021 08:10:57 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR15MB4108EDAC1D320CA0132CFFE3C8779@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB3860D8B8F633F8AD911CA47893759@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB4108A6CF60DB1FB40C427C7FC8759@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38609183F83C41834AC0BDB493759@AM0PR07MB3860.eurprd07.prod.outlook.com> <5BE0F62B-2DE2-4073-BB7D-47DA2E1584B4@chriswendt.net> <DM6PR15MB41081CB035395CBE61904150C8759@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38609494607756BB997F14D293759@AM0PR07MB3860.eurprd07.prod.outlook.com> <e91411bb-e524-8532-8df5-8658ba552a68@petit-huguenin.org> <AM0PR07MB3860CAF8EA7ACA8B65B0729D93759@AM0PR07MB3860.eurprd07.prod.outlook.com> <e5abeb7e-c192-11ad-b534-13e614547327@petit-huguenin.org> <AM0PR07MB38602BD2C8FE4111C1414E2893759@AM0PR07MB3860.eurprd07.prod.outlook.com> <bae50385-4b4c-5893-5155-2e808b3afc5b@petit-huguenin.org> <AM0PR07MB3860A69297A5911013FF341B93759@AM0PR07MB3860.eurprd07.prod.outlook.com> <7cd2574f-ddee-3001-c0ae-420b7198baab@petit-huguenin.org> <AM0PR07MB38605E6633E95419244D696193759@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB4108B0D599C3319A140113B3C8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB3860CD5984E899362BE7833493749@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB410820BCCADE717BE76BF53FC8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB3860BB92288C2BCF00B7633E93749@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB41089C5F2D124EDE43252E2DC8749@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38604B120B9D1264EA9468D693749@AM0PR07MB3860.eurprd07.prod.outlook.com> <F53A0233-30E4-4CB1-B176-676443C96237@chriswendt.net> <DM6PR15MB4108B0A2531BD2AEBE838867C8499@DM6PR15MB4108.namprd15.prod.outlook.com> <82A3D2D6-F066-4C1F-9CAC-6314D6232805@chriswendt.net> <710508DF-BE69-44E7-8704-CDC8B98E3259@team.neustar>
In-Reply-To: <710508DF-BE69-44E7-8704-CDC8B98E3259@team.neustar>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 20 Apr 2021 11:10:45 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt9UfMr4oSt7PUcJ9Bx+MTEM8NTyQnLmGw4Omn_9yTa1g@mail.gmail.com>
Message-ID: <CAD5OKxt9UfMr4oSt7PUcJ9Bx+MTEM8NTyQnLmGw4Omn_9yTa1g@mail.gmail.com>
To: "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>
Cc: Chris Wendt <chris-ietf@chriswendt.net>, "Zerr, Brad" <BZerr@tnsi.com>, Eric Rescorla <ekr@rtfm.com>, Marc Petit-Huguenin <marc@petit-huguenin.org>, Christer Holmberg <christer.holmberg@ericsson.com>, IETF STIR Mail List <stir@ietf.org>, Cullen Jennings <fluffy@iii.ca>, "Toy, Arthur" <atoy@tnsi.com>
Content-Type: multipart/alternative; boundary="00000000000075760d05c068da16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/z-4VizbMiDHyK6i45V9oUxzLv7Y>
Subject: Re: [stir] RFC 8224
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 15:11:09 -0000

I have a border question: What if the destination is phone number +
extension as in sip:+11231231212%231212@provider.com? The portion after the
# has no meaning for transit providers but can be interpreted by the
destination PBX.

Best regards.
_____________
Roman Shpount


On Tue, Apr 20, 2021 at 10:50 AM Peterson, Jon <jon.peterson=
40team.neustar@dmarc.ietf.org> wrote:

>
>
> I certainly think it was the intention of the canonicalization procedures
> to resolve dial strings into globally routable numbers. While there are
> always going to be some exceptions to this (service codes is an example, or
> certain non-geographic freephone numbers, say), I think Chris is hitting on
> the right point here. We sign calls so that a relying party on the
> terminating side can validate them. If what the relying party receives is a
> dial string that has no meaning in their network, what are we accomplishing?
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Chris Wendt <chris-ietf@chriswendt.net>
> *Date: *Tuesday, April 20, 2021 at 7:22 AM
> *To: *"Zerr, Brad" <BZerr@tnsi.com>
> *Cc: *Christer Holmberg <christer.holmberg@ericsson.com>om>, Marc
> Petit-Huguenin <marc@petit-huguenin.org>rg>, Cullen Jennings <fluffy@iii.ca>ca>,
> IETF STIR Mail List <stir@ietf.org>rg>, Eric Rescorla <ekr@rtfm.com>om>,
> "Peterson, Jon" <jon.peterson@team.neustar>ar>, "Toy, Arthur" <atoy@tnsi.com>
> *Subject: *Re: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> I think maybe you are addressing the local mechanics since you are likely
> focused on getting implementation correct, but i’m asking more high level
> about why we are signing dialing codes as a dest, when this is application
> specific and there is no chance this will mean anything to a terminating
> provider or customer across NNI interface.  In fact, seems like a real
> potential security threat, which is why i’d like to get some feedback on
> whether i’m not seeing why this would be potentially useful in the case of
> STIR generically let alone STIR/SHAKEN specifically.
>
>
>
> -Chris
>
>
>
> On Apr 19, 2021, at 4:33 PM, Zerr, Brad <BZerr@tnsi.com> wrote:
>
>
>
> Good afternoon, Chris.
>
>
>
> I am a visual person, so thought it would be nice to lead off with the
> call flow scenario to put this into context.  This is a pretty typical call
> flow scenario for ADC (abbreviated dialing codes / short codes).  I fit
> into the green box below.  As you can see, there is a lot of escaping and
> putting # back into the correct fields.
>
>
>
> <image001.png>
>
>
>
> *From:* Chris Wendt <chris-ietf@chriswendt.net>
> *Sent:* Monday, April 19, 2021 2:48 PM
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>
> *Cc:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
> marc@petit-huguenin.org>gt;; Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail
> List <stir@ietf.org>rg>; Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <
> jon.peterson@neustar.biz>gt;; Toy, Arthur <atoy@tnsi.com>
> *Subject:* Re: [stir] RFC 8224
>
>
>
> Hi Brad, All,
>
>
>
> 1000082 is a technical report and not a normative document, however
> doesn’t mean that fixes can’t or shouldn’t happen, but you or the folks
> that participate should bring this back to IPNNI group.
>
>
>
> But maybe to take it up a level, I’m still struggling why you are sending
> this dial string, signed back to a peering point.  I’m just wondering do we
> have something broken here and is this an IETF stir issue or IPNNI issue.
>
>
>
> Since this is IETF list, can anyone justify why we want to sign sip:*99 as
> dest for any general SIP scenario?
>
>
>
> I really think part of STIR/SHAKEN initiative should be thinking about
> what telephone identity is being used in To/From/PAID, and it think this is
> something that needs cleaning up, especially across NNI, but i would argue
> even intra network too, but I realize that is harder argument.
>
>
>
> So, not sure i’m missing something, but i’m a little puzzled why others
> are not questioning this as well, thus i’m asking the question.
>
>
>
> -Chris
>
>
>
>
> On Apr 8, 2021, at 4:25 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>
>
> Hi,
>
>
>
> I am not making ATIS contributions, but I am sure there is someone else
> who can help you with that :)
>
>
>
> I still think the processing of the phone-context parameter is a question
> mark, though. Maybe we need to add some text somewhere (unless I’ve missed
> it).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Zerr, Brad <BZerr@tnsi.com>
> *Sent:* torstai 8. huhtikuuta 2021 22.56
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
> chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Fyi.  Something like this in the document (ATIS-1000074 or 1000082) may go
> a long way:
>
>
>
> <image001.png>
>
>
>
> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
> *Sent:* Thursday, April 8, 2021 2:34 PM
> *To:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
> marc@petit-huguenin.org>gt;; Chris Wendt <chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> You take the telephone number from the To header, and place it into the
> “dest”/”tn” claim of the PASSport.
>
>
>
> But, unfortunately # has to be escaped in the To header, and un-escaped in
> the “dest”/”tn” claim, so you need to do a escaped-to-un-escaped conversion
> when placing the phone number in the PASSport.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Zerr, Brad <BZerr@tnsi.com>
> *Sent:* torstai 8. huhtikuuta 2021 22.27
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
> chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi Christer,
>
>
>
> Can you describe how you determine that.  According to ATIS-1000074-E, the
> destination claim “tn” states to use the To header.
>
>
>
> <image002.png>
>
>
>
> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
> *Sent:* Thursday, April 8, 2021 2:21 PM
> *To:* Zerr, Brad <BZerr@tnsi.com>om>; Marc Petit-Huguenin <
> marc@petit-huguenin.org>gt;; Chris Wendt <chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* Re: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> The ATIS text you reference is not for the To header.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Get Outlook for iOS
> <https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm4_Mp3zA$>
> ------------------------------
>
> *From:* Zerr, Brad <BZerr@tnsi.com>
> *Sent:* Thursday, April 8, 2021 10:16:44 PM
> *To:* Christer Holmberg <christer.holmberg@ericsson.com>om>; Marc
> Petit-Huguenin <marc@petit-huguenin.org>rg>; Chris Wendt <
> chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi all,
>
>
>
> From previous conversations, it was recommended that the # character in
> the TO header needed to be escaped with %23
>
>
>
> To: sip:%2355;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
>
>
>
> This seems to be at odds with ATIS 1000082 stating what the allowed
> characters are.  As you can see below from 1000082, the % is not as part of
> this list.
>
>
>
> Recommendations?
>
>
>
> <image003.png>
>
>
>
> *From:* Christer Holmberg <christer.holmberg@ericsson.com>
> *Sent:* Wednesday, April 7, 2021 4:00 PM
> *To:* Marc Petit-Huguenin <marc@petit-huguenin.org>rg>; Zerr, Brad <
> BZerr@tnsi.com>gt;; Chris Wendt <chris-ietf@chriswendt.net>
> *Cc:* Cullen Jennings <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>;
> Eric Rescorla <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>;
> Toy, Arthur <atoy@tnsi.com>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi,
>
> >>>>> 1. Section 8.1:
> >>>>>
> >>>>> The origin is either in the From header or in the
> P-Asserted-Identity header, in the example below we have both, but which
> one to use is a matter of local policy, so we are going to process all 3
> (one in the From, two in the PAI):
> >>>>>
> >>>>> orig1:
> >>>>> sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617
> >>>>> 20
> >>>>> 6731m169121c110882s1_1220390100-1617434405
> >>>>> orig2: sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
> >>>>> orig3: tel:xxxxxxxxx <xxxxxxxxx>
> >>>>>
> >>>>> The destination is always in the To header:
> >>>>>
> >>>>> dest:
> >>>>> sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.
> >>>>> mc
> >>>>> cxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
> ;user=phone
> >>>>>
> >>>>> 2. Section 8.1
> >>>>>
> >>>>> Per this section, SIP URIs containing a user=phone parameter or tel
> URI contain a phone numbers. Everything else does not contain a phone
> number.
> >>>>>
> >>>>> Here only orig3 and dest contains a phone number, and need to be
> canonicalized using section 8.3. The part subject to canonicalization is
> the user part of the URI:
> >>>>>
> >>>>> orig3: xxxxxxxxx
> >>>>> dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=7c40792e-23db4012-7c4039b5-86b1886cfa64-568f8cb842251179&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mncxxx.mccxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm9qz1or8$>
> >>>>>
> >>>>> orig1 and orig2 are canonicalized using section 8.5. The input is
> the whole URI:
> >>>>>
> >>>>> orig1: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org
> >>>>> orig2: ip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
> >>>>
> >>>> Where in Section 8 is it defined that phone-context is removed?
> >>>
> >>> It is removed by not being part of the username (or user part) portion
> of a SIP URI:
> >>
> >> It is part of the user part.
> >>
> >> When user=phone is present, the user part is encoded as a
> telephone-subscriber (RFC 2806), which may contain a phone-context.
> >
> > Right, I was thinking of user=phone.
> >
> > phone-context and the other parameters are removed when applying the
> first bullet point in 8.3.
>
> well, the bullet only talks about specific characters, which means numeric
> characters of the phone-context would remain...
>
> I think there should be explicit text about tel-URL parameters (in
> addition to phone-context there are also others).
>
> Regards,
>
> Christer
>
>
>
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >
> >
> > 8.1:
> >
> > "First, implementations will ascertain if the user portion of the URI
> > constitutes a telephone number. Telephone numbers most commonly
> > appear in SIP header field values in the username portion of a SIP
> > URI"
> >
> > 8.3:
> >
> > "Once an implementation has identified a telephone number, it must
> > construct a number string."
> >
> > "o Implementations MUST drop any "+"s, internal dashes, parentheses,
> > or other non-numeric characters, except for the "#" or "*" keys
> > used in some special service numbers"
> >
> >
> >>
> >>
> >>
> >> On 4/7/21 9:54 AM, Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>>>> Maybe the problem with the To header is the phone-context parameter.
> >>>>> The RFC 8224 procedures do not cover the presence of the parameter:
> the parameter is not removed, nor is it added to the tn. And, the generic
> SIP canonicalization procedures does not remove the parameter either.
> >>>>
> >>>> That is not my understanding of RFC 8224 section 8.1 and 8.3.
> >>>
> >>> What is your understanding?
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>> From: Zerr, Brad <BZerr@tnsi.com>
> >>>> Sent: keskiviikko 7. huhtikuuta 2021 18.26
> >>>> To: Chris Wendt <chris-ietf@chriswendt.net>et>; Christer Holmberg
> >>>> <christer.holmberg@ericsson.com>
> >>>> Cc: Marc Petit-Huguenin <marc@petit-huguenin.org>rg>; Cullen Jennings
> >>>> <fluffy@iii.ca>ca>; IETF STIR Mail List <stir@ietf.org>rg>; Eric Rescorla
> >>>> <ekr@rtfm.com>om>; Jon Peterson <jon.peterson@neustar.biz>iz>; Toy,
> >>>> Arthur <atoy@tnsi.com>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Hi Chris,
> >>>>
> >>>> Here is a little background that got this conversation going.
> >>>>
> >>>> One of our customers sent us a SIP INVITE so we could perform the
> Stir-Shaken Signing for them. The customer performed the translations on
> their MMTEL TAS to translate *55 to a 10 digit number. When we receive the
> SIP INVITE for signing, it had the REQ-URI with the 10 digit number and the
> TO header with *55, see below. Our applications rejected this because of
> the TO header (whether it is right or wrong is to be determined). So we
> start questioning how * and # short codes should be handled.
> >>>>
> >>>> FYI, I “x” out information to keep anonymous
> >>>>
> >>>> INVITE
> >>>> sip:+xxxxxxxxxx;phone-context=imsmncXXXmccXXXXgppnetworkorg@ims.mnc
> >>>> x x x.mcc3xxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://x.mcc3xxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm2TTnri4$>;user=phone
> SIP/2.0
> >>>> To:
> >>>> sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.
> >>>> m
> >>>> c
> >>>> cxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
> ;user=phone
> >>>> From:
> >>>> sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617
> >>>> 2
> >>>> 0
> >>>> 6731m169121c110882s1_1220390100-1617434405
> >>>> Call-ID: p65539t1617206731m169121c110882s2
> >>>> CSeq: 1 INVITE
> >>>> Max-Forwards: 66
> >>>> Content-Length: 896
> >>>> Via: SIP/2.0/TCP
> >>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk5555
> >>>> 5
> >>>> 5 yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
> >>>> Via: SIP/2.0/TCP xxxxxxx:5082;branch=z9hG4bK1220390081-337970536
> >>>> Route:
> >>>> sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr
> >>>> Route:
> >>>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%
> >>>> 2
> >>>> B
> >>>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%
> >>>> 4
> >>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
> >>>> Record-Route:
> >>>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.
> >>>> m
> >>>> ncxxx.mccxxx.3gppnetwork.org@scscf2.ims.mncxxxx.mccxxxx.3gppnetwork.
> >>>> o
> >>>> rg:5060;maddr=xxxxxxxxx;lr
> >>>> Contact:
> sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype="cellular";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel<sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel
> >"
> >>>> Content-Type: application/sdp
> >>>> Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE, PRACK,
> >>>> UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
> >>>> Accept-Contact:
> *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
> >>>> Supported: timer, 100rel, path, precondition, replaces
> >>>> P-Asserted-Identity:
> >>>> sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
> >>>> P-Asserted-Identity: tel:xxxxxxxxx <xxxxxxxxx>
> >>>> Proxy-Authorization: Digest
> >>>> uri=sip:*99;phone-context=ims.mnc4xxx.mccxxx.3gppnetwork.org@ims.mn
> >>>> c
> >>>> x
> >>>> xx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://xx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmrKVq_1I$>
> ;user=phone,response="",nonce="",realm="",
> >>>> u
> >>>> s
> >>>> ername=xxxxxxxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org<mailto:xxx
> >>>> x x xxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org>
> >>>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=34ec8226-6b77bb1a-34ecc2bd-86b1886cfa64-e171fd55781981c8&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mcc312.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm_E69mA8$>
> >>>> P-Access-Network-Info:
> >>>> 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-
> >>>> c
> >>>> e
> >>>> ll-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
> >>>> Min-SE: 900
> >>>> Session-Expires: 1800
> >>>> P-Charging-Vector:
> >>>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;ic
> >>>> i
> >>>> d
> >>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://ims.mncxxx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmzkbVY5k$>
> ;orig-ioi=ims.
> >>>> m
> >>>> ncxxx.mccxxxx.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=eeef46a8-b1747f94-eeef0633-86b1886cfa64-e50d414254cbb27d&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fncxxx.mccxxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmmgQ1NYU$>
> >>>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
> >>>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> >>>> P-Served-User:
> >>>> sip:xxxxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org;sescase=orig;regs
> >>>> t
> >>>> a
> >>>> te=reg
> >>>> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
> >>>> P-Early-Media: supported
> >>>> Session-ID: 7c386176b888d13d404845e189d6885b
> >>>>
> >>>> From: Chris Wendt
> >>>> <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
> >>>> Sent: Wednesday, April 7, 2021 10:10 AM
> >>>> To: Christer Holmberg
> >>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>> Cc: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; Marc
> >>>> Petit-Huguenin
> >>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
> >>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List
> >>>> <stir@ietf.org<mailto:stir@ietf.org>>; Eric Rescorla
> >>>> <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
> >>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
> >>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
> >>>> Subject: Re: [stir] RFC 8224
> >>>>
> >>>> This is a legit question for RFC8224 and agree with the answers, but
> just in case it’s relevant you would not send these types of SIP URIs as
> dest in context of STIR/SHAKEN (over NNI/peering relationship) which only
> supports tel URIs currently. That may not be your use-case but just wanted
> to clarify in case it was relevant. I would be curious to know the context
> if you are willing to share though, i am guessing intra network use case
> between device and app server? Definitely interested in those cases, for me
> in context of delegate certs.
> >>>>
> >>>> -Chris
> >>>>
> >>>>
> >>>>
> >>>> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <
> christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be
> escaped.
> >>>>
> >>>> So:
> >>>>
> >>>> To:
> >>>> sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> …is ok, but;
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=de790f19-81e23625-de794f82-86b1886cfa64-8040fe565ed6c82c&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmXz7Bjus$>
> >>>> c
> >>>> 3 12.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
> >>>>
> >>>> …is NOT ok. Instead:
> >>>>
> >>>> To:
> >>>> sip:%2355;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>
> >>>> …will have to be used.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>> From: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>
> >>>> Sent: keskiviikko 7. huhtikuuta 2021 14.27
> >>>> To: Christer Holmberg
> >>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>> ; Marc Petit-Huguenin
> >>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
> >>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List
> >>>> <stir@ietf.org<mailto:stir@ietf.org>>
> >>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
> >>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
> >>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
> >>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Good Morning.
> >>>>
> >>>> Would you mind providing an example of what the TO header should look
> like for both a * and # dial to help clear up? Assume they are leading
> characters in the TO header.
> >>>>
> >>>> Example of what is being sent today:
> >>>>
> >>>> To:
> >>>> sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=8b69ba29-d4f28315-8b69fab2-86b1886cfa64-770258b0ccf0eabc&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmuZBnGaY$>
> >>>> c
> >>>> 3 12.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
> >>>>
> >>>> From: Christer Holmberg
> >>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.c
> <christer.holmberg@ericsson.com%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>> Sent: Wednesday, April 7, 2021 3:14 AM
> >>>> To: Marc Petit-Huguenin
> >>>> <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen
> >>>> Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; Zerr, Brad
> >>>> <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR Mail List
> >>>> <stir@ietf.org<mailto:stir@ietf.org>>
> >>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
> >>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
> >>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
> >>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Hi,
> >>>>
> >>>>> I think the question was about the format to use before
> canonicalization.
> >>>>>
> >>>>> My understanding of RFC 3986 is that `#` should be escaped because
> it is the delimiter for an URI fragment. Fragments are not defined in SIP
> URIs, but a generic URI parser may still remove everything after and
> including '#'.
> >>>>
> >>>> "#" will have to be escaped in a SIP-URI, e.g., in a To header field.
> >>>>
> >>>> But, Section 8.3 of RFC 8224 has nothing to do with a SIP-URI or the
> To header field.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> OTOH there is no need to escape '*' as it is part of the `sub-delims`
> rule.
> >>>>
> >>>> so
> >>>>
> >>>> ....
> >>>> To:
> >>>> sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>> ....
> >>>>
> >>>> is fine, but dialing directly an extension would be:
> >>>>
> >>>> ....
> >>>> To: sip:+14085550460%2377@example.org;user=phone
> >>>> ....
> >>>>
> >>>> On 4/6/21 5:43 AM, Christer Holmberg wrote:
> >>>>> Hi,
> >>>>>
> >>>>> %2A is not the ASCII format of *, it is the escaped (see RFC 3261).
> >>>>>
> >>>>> And, the syntax allows both * and #, so no need to escape (in fact,
> it is not even possible to escape in this case):
> >>>>>
> >>>>> tn-spec = 1*tn-char
> >>>>> tn-char = "#" / "*" / DIGIT
> >>>>>
> >>>>> Also, note that RFC 8224 does not define the syntax of the To header
> field - that is done in RFC 3261. The telephone number described in Section
> 8.3 of RFC 8224 will be included in the PASSPort (RFC 8225).
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> >>>>> From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>>
> >>>>> On Behalf Of Cullen Jennings
> >>>>> Sent: tiistai 6. huhtikuuta 2021 15.30
> >>>>> To: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR
> >>>>> Mail List <stir@ietf.org<mailto:stir@ietf.org>>
> >>>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>;
> >>>>> Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson
> >>>>> <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy,
> >>>>> Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
> >>>>> Subject: Re: [stir] RFC 8224
> >>>>>
> >>>>>
> >>>>> Adding to STIR mailing list …
> >>>>>
> >>>>>
> >>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <
> BZerr@tnsi.com<mailto:BZerr@tnsi.com<mailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com
> <BZerr@tnsi.com%3cmailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com>>>>
> wrote:
> >>>>>
> >>>>> Good Morning.
> >>>>>
> >>>>> This may not be the correct process, so let me know if I should ask
> this in a different forum.
> >>>>>
> >>>>> I had a question regarding section 8.3 when it comes to * and #
> >>>>> handling. Is this stating that when a * or # proceeds a digit
> >>>>> string (i.e. *55), it should be in ASCI Format for the * (i.e.
> >>>>> %2A)
> >>>>>
> >>>>> <image001.png>
> >>>>>
> >>>>> So Instead of this:
> >>>>>
> >>>>> To:
> >>>>> sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.
> >>>>> m
> >>>>> cc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://cc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmfRONVeE$>
> ;user=phone
> >>>>>
> >>>>> It should be this
> >>>>>
> >>>>> To:
> >>>>> sip:%2A55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc4
> >>>>> 2
> >>>>> 0
> >>>>> .mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
>
>
>
>
> --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog:
> https://protect2.fireeye.com/v1/url?k=28d0d527-774bedc5-28d095bc-86073b36ea28-f2c358423b8421cd&q=1&e=78d08abe-b951-45e0-a93d-4a2bc670a4be&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=28d0d527-774bedc5-28d095bc-86073b36ea28-f2c358423b8421cd&q=1&e=78d08abe-b951-45e0-a93d-4a2bc670a4be&u=https*3A*2F*2Fmarc.petit-huguenin.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm6Ydzy3k$>
> Profile: https://www.linkedin.com/in/petithug
> <https://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmoI6LC4M$>
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=42ec3a2d-1d770311-42ec7ab6-86b1886cfa64-3d8237f494010d10&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmQbUy4sM$>
> ------------------------------
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=020077dc-5d9b4ef1-02003747-8692dc8284cb-ec95acff01abac94&q=1&e=1f14ae7d-a5b2-43c1-b945-f0c630ffb408&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmjtmQmno$>
> ------------------------------
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=d374985c-8cefa160-d374d8c7-86b1886cfa64-26115e6a3e22c2ad&q=1&e=776a0e59-f4eb-4d9d-9834-6391c543254b&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm-WDhmgg$>
> ------------------------------
>
>
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__http://www.mimecast.com/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmLPaDIuo$>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>