Subject: Re: [stir] RFC 8224

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Apr 2021 06:30:21 -0600

Adding to STIR mailing list … 

> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]> 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)
>  
>  
> So Instead of this:
>  
> To: sip:*55;phone-context=[email-masked];user=phone <sip:*55;phone-context=[email-masked];user=phone>
>  
> It should be this
>  
> To: sip:%2A55;phone-context=[email-masked];user=phone <sip:%2A55;phone-context=[email-masked];user=phone>
>  
>  
>  
>  
> Brad Zerr | Sr. Sales Engineer, Communications Market
> Transaction Network Services
> 7311 W 132nd Street | Suite 300 | Overland Park | KS 66213 | USA
>  +1 913 488 2335 |    [email-masked] <mailto:[email-masked]> |   www.tnsi.com <http://www.tnsi.com/>
>  
> 
> 
> 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 <http://www.mimecast.com/>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2021 12:43:21 +0000

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 <[email-masked]> On Behalf Of Cullen Jennings
Sent: tiistai 6. huhtikuuta 2021 15.30
To: Zerr, Brad <[email-masked]>; IETF STIR Mail List <[email-masked]>
Cc: [email-masked]; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: Re: [stir] RFC 8224

On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]<mailto:[email-masked]>> wrote:

Good Morning.

So Instead of this:

To: sip:*55;phone-context=[email-masked];user=phone

It should be this

To: sip:%2A55;phone-context=[email-masked];user=phone

Brad Zerr | Sr. Sales Engineer, Communications Market
Transaction Network Services
7311 W 132nd Street | Suite 300 | Overland Park | KS 66213 | USA
 +1 913 488 2335 |    [email-masked]<mailto:[email-masked]> |   www.tnsi.com<https://protect2.fireeye.com/v1/url?k=ba197ec4-e58247c6-ba193e5f-869a14f4b08c-0184d9b0082e8185&q=1&e=8824b9ee-990d-4fef-9e7d-a89ccab98c9d&u=http%3A%2F%2Fwww.tnsi.com%2F>

________________________________

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<https://protect2.fireeye.com/v1/url?k=ecce9f54-b355a656-eccedfcf-869a14f4b08c-0579e559b1442b89&q=1&e=8824b9ee-990d-4fef-9e7d-a89ccab98c9d&u=http%3A%2F%2Fwww.mimecast.com%2F>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 6 Apr 2021 14:11:32 -0700

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 '#'.

OTOH there is no need to escape '*' as it is part of the `sub-delims` rule.

so

....
....

is fine, but dialing directly an extension would be:

....
To: sip:[email-masked];user=phone
....

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 08:13:56 +0000

Hi,

>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 everythi…

"#" 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

so

....

....

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 13:52:25 +0000

Hi,

´*´ can be used as such in a SIP-URI, but ‘#’ would have to be escaped.

So:

…is ok, but;

To: sip:#55;phone-context=[email-masked];user=phone<sip:*55;phone-context=[email-masked];user=phone>

…is NOT ok. Instead:

To: sip:%2355;phone-context=[email-masked];user=phone

…will have to be used.

Regards,

Christer

From: Zerr, Brad <[email-masked]>
Sent: keskiviikko 7. huhtikuuta 2021 14.27
To: Christer Holmberg <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>
Cc: [email-masked]; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
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=[email-masked];user=phone<sip:*55;phone-context=[email-masked];user=phone>

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 7, 2021 3:14 AM
To: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Cullen Jennings <[email-masked]<mailto:[email-masked]>>; Zerr, Brad <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] RFC 8224

Hi,

Regards,

Christer

so

....

....

On 4/6/21 5:43 AM, Christer Holmberg wrote:
> From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Cullen Jennings
> To: Zerr, Brad <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:
>
> Good Morning.
>

--
Marc Petit-Huguenin
Email: [email-masked]<mailto:[email-masked]>
Blog: https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<https://protect2.fireeye.com/v1/url?k=637df9a8-3ce6c0ad-637db933-86959e472243-f3817145c048b8e8&q=1&e=c8cf1527-7ed0-445d-a2d9-6e029fd3a549&u=http%3A%2F%2Fwww.mimecast.com%2F>
________________________________

---

From: Chris Wendt <[email-masked]>
Date: Wed, 7 Apr 2021 11:09:55 -0400

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 <[email-masked]> wrote:
> 
> Hi,
>  
> To: sip:#55;phone-context=[email-masked];user=phone <sip:*55;phone-context=[email-masked];user=phone>
>  
> …is NOT ok. Instead:
>  
> To: sip:%2355;phone-context=[email-masked];user=phone <sip:%2355;phone-context=[email-masked];user=phone>
>  
> …will have to be used.
>  
> Regards,
>  
> Christer
>  
>  
>  
> To: sip:#55;phone-context=[email-masked];user=phone <sip:*55;phone-context=[email-masked];user=phone>
>  
> From: Christer Holmberg <[email-masked] <mailto:[email-masked]>> 
> To: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Cullen Jennings <[email-masked] <mailto:[email-masked]>>; Zerr, Brad <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> To: sip:[email-masked];user=phone <sip:[email-masked];user=phone>
> ....
> 
> > From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Cullen Jennings
> > To: Zerr, Brad <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> > On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:
> > 
> > Good Morning.
> > 
> Email: [email-masked] <mailto:[email-masked]>
> Blog: https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F <https://protect2.fireeye.com/v1/url?k=980fc57b-c794fc4a-980f85e0-86e2237f51fb-d778e82319b4f5fa&q=1&e=032f1e9f-0aed-459c-b48f-5a5bb8a74467&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F>
> Profile: https://www.linkedin.com/in/petithug <https://www.linkedin.com/in/petithug>
>  
> 
> For more information please visit http://www.mimecast.com <https://protect2.fireeye.com/v1/url?k=637df9a8-3ce6c0ad-637db933-86959e472243-f3817145c048b8e8&q=1&e=c8cf1527-7ed0-445d-a2d9-6e029fd3a549&u=http%3A%2F%2Fwww.mimecast.com%2F>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 15:18:50 +0000

Hi Chris,

Note that the examples are valid tel-URLs. However, as per RFC 2806, they are “local numbers”, not “global numbers”.

Regards,

Christer

From: Chris Wendt <[email-masked]>
Sent: keskiviikko 7. huhtikuuta 2021 18.10
To: Christer Holmberg <[email-masked]>
Cc: Zerr, Brad <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: Re: [stir] RFC 8224

-Chris

On Apr 7, 2021, at 9:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

So:

…is ok, but;

…is NOT ok. Instead:

…will have to be used.

Regards,

Christer

From: Zerr, Brad <[email-masked]<mailto:[email-masked]>>
Sent: keskiviikko 7. huhtikuuta 2021 14.27
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Cullen Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] RFC 8224

Good Morning.

Hi,

Regards,

Christer

so

....

....

---

From: Chris Wendt <[email-masked]>
Date: Wed, 7 Apr 2021 11:23:24 -0400

Yes, sorry you are correct.

> On Apr 7, 2021, at 11:18 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Chris,
>  
> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>  
> From: Zerr, Brad <[email-masked] <mailto:[email-masked]>> 
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Apr 2021 11:27:08 -0400

I’m sure you all haven’t dealt with this yet, but:

The way we usually see telephone numbers is in a SIP URI: sip:[email-masked] <sip:[email-masked]>; user=phone.

SHAKEN deals mostly with the TN.  But 9-1-1 has a use case for the domain part: we send calls directly back to where they came from to increase the probability we will be able to recreate the same media conditions (video, codecs, RTT) etc the original call had.  In 9-1-1, there are no transit networks for the SIP path other than sometimes a specialized service provider, and we can deal with getting them not to rewrite the URI.  It really would be helpful to (eventually) sign the actual FROM/P-A-I with the domain.

If we ever got the messaging super players to support emergency messaging, we would have a similar circumstance.

Brian

> On Apr 7, 2021, at 11:09 AM, Chris Wendt <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Wed, 7 Apr 2021 11:32:23 -0400

Hi Brian,

I suspect with messaging/video/etc SIP URI support will become important/relevant for sure, so not implying that can’t happen by any means.

-Chris

> On Apr 7, 2021, at 11:27 AM, Brian Rosen <[email-masked]> wrote:
> 
>> On Apr 7, 2021, at 11:09 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Chris Wendt <[email-masked]>
Date: Wed, 7 Apr 2021 11:38:05 -0400

We’ve definitely had various discussions about relevant To and From and PAID in context of orig and dest in the past, not with total agreement, although i've advocated that perhaps STI-AS should normalize as best practice to make rules of 8224 verification work correctly on terminating side in these cases.  *55 is not something that seems relevant to escape an originating SIP network in any case.  But interesting to see if i start a war here :)

> On Apr 7, 2021, at 11:26 AM, Zerr, Brad <[email-masked]> wrote:
> 
> 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=[email-masked];user=phone <sip:+xxxxxxxxxx;phone-context=[email-masked];user=phone>SIP/2.0
> To: sip:*99;phone-context=[email-masked];user=phone <sip:*99;phone-context=[email-masked];user=phone>
> From: sip:[email-masked];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405 <sip:[email-masked];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405>
> Call-ID: p65539t1617206731m169121c110882s2
> CSeq: 1 INVITE
> Max-Forwards: 66
> Content-Length: 896
> Via: SIP/2.0/TCP xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
> Via: SIP/2.0/TCP xxxxxxx:5082;branch=z9hG4bK1220390081-337970536
> Route: sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr <sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr>
> Route: sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr <sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr>
> Record-Route: sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2E[email-masked]:5060;maddr=xxxxxxxxx;lr <sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2E[email-masked]: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:[email-masked] <sip:[email-masked]>
> P-Asserted-Identity: tel:xxxxxxxxx <tel:xxxxxxxxx>
> Proxy-Authorization: Digest uri=sip:*99;phone-context=[email-masked];user=phone <sip:*99;phone-context=[email-masked];user=phone>,response="",nonce="",realm="",username=[email-masked] <mailto:[email-masked]>
> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org <http://ims.mnc420.mcc312.3gppnetwork.org/>
> P-Access-Network-Info: 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-cell-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
> Min-SE: 900
> Session-Expires: 1800
> P-Charging-Vector: icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;icid-generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org <http://ims.mncxxx.mccxxx.3gppnetwork.org/>;orig-ioi=ims.mncxxx.mccxxxx.3gppnetwork.org <http://ims.mncxxx.mccxxxx.3gppnetwork.org/>
> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> P-Served-User: sip:[email-masked] <sip:[email-masked]>;sescase=orig;regstate=reg
> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
> P-Early-Media: supported
> Session-ID: 7c386176b888d13d404845e189d6885b
>  
> Sent: Wednesday, April 7, 2021 10:10 AM

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 16:41:00 +0000

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.

Regards,

Christer

From: Zerr, Brad <[email-masked]>
Sent: keskiviikko 7. huhtikuuta 2021 18.26
To: Chris Wendt <[email-masked]>; Christer Holmberg <[email-masked]>
Cc: Marc Petit-Huguenin <[email-masked]>; Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: RE: [stir] RFC 8224

Hi Chris,

INVITE sip:+xxxxxxxxxx;phone-context=[email-masked];user=phone SIP/2.0
To: sip:*99;phone-context=[email-masked];user=phone
From: sip:[email-masked];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405
Call-ID: p65539t1617206731m169121c110882s2
CSeq: 1 INVITE
Max-Forwards: 66
Content-Length: 896
Via: SIP/2.0/TCP xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
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%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
Record-Route: sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2E[email-masked]: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:[email-masked]
P-Asserted-Identity: tel:xxxxxxxxx
Proxy-Authorization: Digest uri=sip:*99;phone-context=[email-masked];user=phone,response="",nonce="",realm="",username=[email-masked]<mailto:[email-masked]>
P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-cell-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
Min-SE: 900
Session-Expires: 1800
P-Charging-Vector: icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;icid-generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org;orig-ioi=ims.mncxxx.mccxxxx.3gppnetwork.org
User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
P-Served-User: sip:[email-masked];sescase=orig;regstate=reg
Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
P-Early-Media: supported
Session-ID: 7c386176b888d13d404845e189d6885b

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 7, 2021 10:10 AM
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Zerr, Brad <[email-masked]<mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Cullen Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] RFC 8224

-Chris

Hi,

So:

…is ok, but;

…is NOT ok. Instead:

…will have to be used.

Regards,

Christer

Good Morning.

Hi,

Regards,

Christer

so

....

....

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<https://protect2.fireeye.com/v1/url?k=f73bbf9b-a8a08749-f73bff00-866132fe445e-a64fcf54962ba2b5&q=1&e=84936e3c-4199-4e8a-8f63-382196b5c5e3&u=http%3A%2F%2Fwww.mimecast.com%2F>
________________________________

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 7 Apr 2021 09:51:08 -0700

> 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…

That is not my understanding of RFC 8224 section 8.1 and 8.3.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 16:54:28 +0000

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.
>

What is your understanding?

Regards,

Christer

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=247f4226-7be47af4-247f02bd-866132fe445e-1643d035697446bf&q=1&e=752f8e22-1054-4dd1-a34b-0b0d5deca043&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 7 Apr 2021 10:25:10 -0700

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:[email-masked];tag=p65539t1617206731m169121c110882s1_1220390100-1617434405
orig2: sip:[email-masked]
orig3: tel:xxxxxxxxx

The destination is always in the To header:

dest: sip:*99;phone-context=[email-masked];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

orig1 and orig2 are canonicalized using section 8.5.  The input is the whole URI:

orig1: sip:[email-masked]
orig2: ip:[email-masked]

3. Section 8.3

Both orig3 and dest are canonicalized by removing everything but digits, '*' and '#':

orig3: xxxxxxxxx (I suppose)
dest: *99

We check that both are globally routable.  It is not possible to say for orig3, but dest is definitively not globally routable (does not start with a leading country code).  That means that we cannot use that for the destination.  The next bullet point could be used to make that string routable, but that's probably something that should have been done before hitting the authentication service.

4. Section 8.4

Both orig1 and orig2 are canonicalized:

orig1: sip:[email-masked]
orig2: sip:[email-masked]

Now local policy chooses between orig1, orig2 and orig3:

"orig":{"uri":"sip:[email-masked]}

"orig":{"uri":"sip:[email-masked]"}

"orig":{"tn":"xxxxxxxxx"}

"dest" cannot be populated.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 17:45:44 +0000

Hi,

>orig2: ip:[email-masked]

Where in Section 8 is it defined that phone-context is removed?

Regards,

Christer

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.
>>
>> Cc: Marc Petit-Huguenin <[email-masked]>; Cullen Jennings 
>> <[email-masked]>; IETF STIR Mail List <[email-masked]>; Eric Rescorla 
>> <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur 
>> <[email-masked]>
>> INVITE 
>> sip:+xxxxxxxxxx;phone-context=[email-masked]
>> x.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>> To: 
>> sip:*99;phone-context=[email-masked]
>> cxxx.3gppnetwork.org;user=phone
>> From: 
>> sip:[email-masked];tag=p65539t161720
>> 6731m169121c110882s1_1220390100-1617434405
>> Via: SIP/2.0/TCP 
>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555
>> yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
>> Route: 
>> sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr
>> Route: 
>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2B
>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40
>> ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>> Record-Route: 
>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.m
>> [email-masked]
>> rg:5060;maddr=xxxxxxxxx;lr
>> Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE, PRACK, 
>> UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
>> Proxy-Authorization: Digest 
>> uri=sip:*99;phone-context=[email-masked]
>> xx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",us
>> ername=[email-masked]<mailto:xxxxx
>> [email-masked]>
>> P-Access-Network-Info: 
>> 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-ce
>> ll-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
>> Min-SE: 900
>> Session-Expires: 1800
>> P-Charging-Vector: 
>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;icid
>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org;orig-ioi=ims.m
>> ncxxx.mccxxxx.3gppnetwork.org
>> P-Served-User: 
>> sip:[email-masked];sescase=orig;regsta
>> te=reg
>> From: Chris Wendt 
>> <[email-masked]<mailto:[email-masked]>>
>> To: Christer Holmberg 
>> <[email-masked]<mailto:[email-masked]
>> >>
>> Cc: Zerr, Brad <[email-masked]<mailto:[email-masked]>>; Marc 
>> Petit-Huguenin 
>> <[email-masked]<mailto:[email-masked]>>; Cullen 
>> Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List 
>> <[email-masked]<mailto:[email-masked]>>; Eric Rescorla 
>> <[email-masked]<mailto:[email-masked]>>; Jon Peterson 
>> <[email-masked]<mailto:[email-masked]>>; Toy, 
>> Arthur <[email-masked]<mailto:[email-masked]>>
>> To: 
>> sip:*55;phone-context=[email-masked]
>> c312.3gppnetwork.org;user=phone
>>
>> …is ok, but;
>>
>> To: 
>> sip:#55;phone-context=[email-masked]
>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc3
>> [email-masked];user=phone>
>>
>> …is NOT ok. Instead:
>>
>> To: 
>> sip:%2355;phone-context=[email-masked].
>> mcc312.3gppnetwork.org;user=phone
>>
>> …will have to be used.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> To: Christer Holmberg 
>> <[email-masked]<mailto:[email-masked]
>> >>; Marc Petit-Huguenin 
>> <[email-masked]<mailto:[email-masked]>>; Cullen 
>> Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List 
>> <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>; Eric 
>> Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson 
>> <[email-masked]<mailto:[email-masked]>>; Toy, 
>> Arthur <[email-masked]<mailto:[email-masked]>>
>> To: 
>> sip:*55;phone-context=[email-masked]
>> c312.3gppnetwork.org;user=phone
>>
>> To: 
>> sip:#55;phone-context=[email-masked]
>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc3
>> [email-masked];user=phone>
>>
>> From: Christer Holmberg 
>> <[email-masked]<mailto:[email-masked]
>> >>
>> To: Marc Petit-Huguenin 
>> <[email-masked]<mailto:[email-masked]>>; Cullen 
>> Jennings <[email-masked]<mailto:[email-masked]>>; Zerr, Brad 
>> <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List 
>> <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>; Eric 
>> Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson 
>> <[email-masked]<mailto:[email-masked]>>; Toy, 
>> Arthur <[email-masked]<mailto:[email-masked]>>
>> To: 
>> sip:*55;phone-context=[email-masked]
>> c312.3gppnetwork.org;user=phone
>> ....
>>
>>> To: Zerr, Brad <[email-masked]<mailto:[email-masked]>>; IETF STIR 
>>> Mail List <[email-masked]<mailto:[email-masked]>>
>>> Cc: [email-masked]<mailto:[email-masked]>; 
>>> Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson 
>>> <[email-masked]<mailto:[email-masked]>>; Toy, 
>>> Arthur <[email-masked]<mailto:[email-masked]>>
>>> 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)
>>>
>>>
>>> So Instead of this:
>>>
>>> To: 
>>> sip:*55;phone-context=[email-masked]
>>> cc312.3gppnetwork.org;user=phone
>>>
>>> It should be this
>>>
>>> To: 
>>> sip:%2A55;phone-context=[email-masked]
>>> .mcc312.3gppnetwork.org;user=phone
>>>
>>>
>>>
>>
>>
> 

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=96defbb0-c945c281-96debb2b-86e2237f51fb-55bc80b699dc4cf0&q=1&e=601eaa03-95ce-4b90-9575-83c0b1641010&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 7 Apr 2021 11:02:58 -0700

> 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:

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"

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 20:06:30 +0000

Hi,

>>> orig1: 
>>> dest: 

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.

Regards,

Christer

8.1:

8.3:

>>> sip:+xxxxxxxxxx;phone-context=[email-masked]
>>> x x.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>>> To:
>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk55555
>>> 5 yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
>>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%4
>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>>> Record-Route:
>>> ername=[email-masked]<mailto:xxxx
>>> x [email-masked]>
>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc
>>> 3 [email-masked];user=phone>
>>>
>>> …is NOT ok. Instead:
>>>
>>> To:
>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc
>>> 3 [email-masked];user=phone>
>>>
>>> From: Christer Holmberg
>>>> 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)
>>>>
>>>>
>>>> So Instead of this:
>>>>
>>>> To:
> Blog: 
> https://protect2.fireeye.com/v1/url?k=96defbb0-c945c281-96debb2b-86e22
> 37f51fb-55bc80b699dc4cf0&q=1&e=601eaa03-95ce-4b90-9575-83c0b1641010&u=
> https%3A%2F%2Fmarc.petit-huguenin.org%2F

--
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://protect2.fireeye.com/v1/url?k=3a64228f-65ff1bee-3a646214-86d8a30ca42b-0ef2b2c3dd3c5070&q=1&e=fd884492-85cb-4ab0-a005-8ee1c82bacb2&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 7 Apr 2021 13:43:08 -0700

> 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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 7 Apr 2021 13:56:10 -0700

> phone-context and the other parameters are removed when applying the first bullet point in 8.3.

In fact after reading again the ABNF in RFC 3966, the first bullet point process in 8.3 would not get rid of the digits after ";phone-context=", as in the example in section 6 of RFC 3966, so that would not work in that case.  But that works in the example below because the context does not contain a number.

So there is something missing.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2021 20:59:50 +0000

Hi,

> 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

>>>> <[email-masked]>; Jon Peterson <[email-masked]>; Toy, 
>>>> Arthur <[email-masked]>
>>>> sip:+xxxxxxxxxx;phone-context=[email-masked]
>>>> x x x.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>>>> To:
>>>> sip:*99;phone-context=[email-masked].
>>>> m
>>>> c
>>>> sip:[email-masked];tag=p65539t1617
>>>> 2
>>>> 0
>>>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%
>>>> 2
>>>> B
>>>> P-Asserted-Identity: 
>>>> sip:[email-masked]
>>>> uri=sip:*99;phone-context=[email-masked]
>>>> c
>>>> x
>>>> xx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",
>>>> u
>>>> s
>>>> ername=[email-masked]<mailto:xxx
>>>> x x [email-masked]>
>>>> 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-
>>>> c
>>>> e
>>>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;ic
>>>> i
>>>> d
>>>> sip:[email-masked];sescase=orig;regs
>>>> t
>>>> a
>>>> te=reg
>>>> <[email-masked]<mailto:[email-masked]
>>>> o
>>>> m
>>>>>>
>>>> sip:#55;phone-context=[email-masked].
>>>> m
>>>> c
>>>> <[email-masked]<mailto:[email-masked]
>>>> o
>>>> m
>>>>>> ; Marc Petit-Huguenin
>>>> sip:#55;phone-context=[email-masked].
>>>> m
>>>> c
>>>> <[email-masked]<mailto:[email-masked]
>>>> o
>>>> m
>>>>>>
>>>>> sip:%2A55;phone-context=[email-masked]
>>>>> 2
>>>>> 0

--
Marc Petit-Huguenin
Email: [email-masked]
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
Profile: https://www.linkedin.com/in/petithug

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2021 19:20:51 +0000

Hi Brad,

The ATIS text you reference is not for the To header.

Regards,

Christer

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Zerr, Brad <[email-masked]>
Sent: Thursday, April 8, 2021 10:16:44 PM
To: Christer Holmberg <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; Chris Wendt <[email-masked]>
Cc: Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
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

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?

From: Christer Holmberg <[email-masked]>
Sent: Wednesday, April 7, 2021 4:00 PM
To: Marc Petit-Huguenin <[email-masked]>; Zerr, Brad <[email-masked]>; Chris Wendt <[email-masked]>
Cc: Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>; Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>; Toy, Arthur <[email-masked]>
Subject: RE: [stir] RFC 8224

Hi,

>>>>> 20
>>>>> mc
>>>>> dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org<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>
>>>>>

Regards,

Christer

>>>> To: Chris Wendt <[email-masked]<mailto:[email-masked]>>; Christer Holmberg
>>>> <[email-masked]<mailto:[email-masked]>>
>>>> Cc: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Cullen Jennings
>>>> <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Eric Rescorla
>>>> <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy,
>>>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%<sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%25>
>>>> 2
>>>> B
>>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr<mailto:ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr>
>>>> Record-Route:
>>>> [email-masked]<mailto:[email-masked]>.
>>>> o
>>>> 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<sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel%3csip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel>>"
>>>> ername=[email-masked]<mailto:xxx<mailto:ername=[email-masked]%3cmailto:xxx>
>>>> x x [email-masked]<mailto:[email-masked]>>
>>>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org<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>
>>>> P-Access-Network-Info:
>>>> ncxxx.mccxxxx.3gppnetwork.org<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>
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
<mailto:[email-masked]%3cmailto:[email-masked]%0b>>>>> o
>>>> m
>>>>>>
>>>> Cc: Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Marc
>>>> Petit-Huguenin
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen
>>>> Jennings <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Eric Rescorla
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy,
>>>> Arthur <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mc<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>
>>>> c
>>>> 3 [email-masked];user=phone<mailto:[email-masked];user=phone>>
>>>>
>>>> …is NOT ok. Instead:
>>>>
>>>> To:
>>>> From: Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
<mailto:[email-masked]%3cmailto:[email-masked]%0b>>>>> o
>>>> m
>>>>>> ; Marc Petit-Huguenin
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen
>>>> Jennings <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>> Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>;
>>>> Eric Rescorla <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy,
>>>> Arthur <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mc<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>
>>>> c
>>>> 3 [email-masked];user=phone<mailto:[email-masked];user=phone>>
>>>>
>>>> From: Christer Holmberg
<mailto:[email-masked]%3cmailto:[email-masked]%0b>>>>> o
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen
>>>> Jennings <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Zerr, Brad
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>> Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>;
>>>> Eric Rescorla <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson
>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy,
>>>> Arthur <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>>> From: stir <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>>> On Behalf Of Cullen Jennings
>>>>> To: Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR
>>>>> Mail List <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>>> Cc: [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>;
>>>>> Eric Rescorla <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson
>>>>> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy,
>>>>> Arthur <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
>>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>> wrote:
>>>>>
>>>>> Good Morning.
>>>>>

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<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>
________________________________

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2021 19:34:25 +0000

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

Sent: torstai 8. huhtikuuta 2021 22.27

Hi Christer,

Can you describe how you determine that.  According to ATIS-1000074-E, the destination claim “tn” states to use the To header.

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 8, 2021 2:21 PM
To: Zerr, Brad <[email-masked]<mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] RFC 8224

Hi Brad,

Regards,

Christer

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Zerr, Brad <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 8, 2021 10:16:44 PM
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] RFC 8224

Hi all,

Recommendations?

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 7, 2021 4:00 PM
To: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>; Zerr, Brad <[email-masked]<mailto:[email-masked]>>; Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: Cullen Jennings <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>; Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Jon Peterson <[email-masked]<mailto:[email-masked]>>; Toy, Arthur <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] RFC 8224

Hi,

Regards,

Christer

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<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>
________________________________

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2021 20:25:13 +0000

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

Sent: torstai 8. huhtikuuta 2021 22.56

Fyi.  Something like this in the document (ATIS-1000074 or 1000082) may go a long way:

Sent: Thursday, April 8, 2021 2:34 PM

Hi Brad,

Regards,

Christer

Hi Christer,

Hi Brad,

Regards,

Christer

Hi all,

Recommendations?

Hi,

Regards,

Christer

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com<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>
________________________________

---

From: Chris Wendt <[email-masked]>
Date: Mon, 19 Apr 2021 15:47:38 -0400

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 <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 <[email-masked]> wrote:
> 
> Hi,
>  
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> To: Zerr, Brad <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> To: Zerr, Brad <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> To: sip:%2355;phone-context=[email-masked] <sip:%2355;phone-context=[email-masked]>.mcc312.3gppnetwork.org;user=phone
>  
> To: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Zerr, Brad <[email-masked] <mailto:[email-masked]>>; Chris Wendt <[email-masked] <mailto:[email-masked]>>
> Cc: Cullen Jennings <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, Arthur <[email-masked] <mailto:[email-masked]>>
> >>>>> sip:[email-masked];tag=p65539t1617 <sip:[email-masked];tag=p65539t1617>
> >>>>> 20
> >>>>> orig2: sip:[email-masked] <sip:[email-masked]>
> >>>>> orig3: tel:xxxxxxxxx <tel:xxxxxxxxx>
> >>>>>
> >>>>> sip:*99;phone-context=[email-masked] <sip:*99;phone-context=[email-masked]>.
> >>>>> mc
> >>>>> cxxx.3gppnetwork.org <http://cxxx.3gppnetwork.org/>;user=phone
> >>>>>
> >>>>> 2. Section 8.1
> >>>>>
> >>>>> dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org <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>
> >>>>>
> >>>>> orig1: sip:[email-masked] <sip:[email-masked]>
> >>>>> orig2: ip:[email-masked] <mailto:[email-masked]>
> >>>>
> >>>> To: Chris Wendt <[email-masked] <mailto:[email-masked]>>; Christer Holmberg 
> >>>> <[email-masked] <mailto:[email-masked]>>
> >>>> Cc: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>; Cullen Jennings 
> >>>> <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>; Eric Rescorla 
> >>>> <[email-masked] <mailto:[email-masked]>>; Jon Peterson <[email-masked] <mailto:[email-masked]>>; Toy, 
> >>>> Arthur <[email-masked] <mailto:[email-masked]>>
> >>>> sip:+xxxxxxxxxx;phone-context=[email-masked] <sip:+xxxxxxxxxx;phone-context=[email-masked]>
> >>>> x x x.mcc3xxx.3gppnetwork.org <http://x.mcc3xxx.3gppnetwork.org/>;user=phone SIP/2.0
> >>>> To:
> >>>> sip:*99;phone-context=[email-masked] <sip:*99;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> cxxx.3gppnetwork.org <http://cxxx.3gppnetwork.org/>;user=phone
> >>>> From:
> >>>> sip:[email-masked];tag=p65539t1617 <sip:[email-masked];tag=p65539t1617>
> >>>> 2
> >>>> 0
> >>>> sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr <sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr>
> >>>> Route:
> >>>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A% <sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%25>
> >>>> 2
> >>>> B
> >>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr <mailto:ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr>
> >>>> Record-Route:
> >>>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims <sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims>.
> >>>> m
> >>>> [email-masked] <mailto:[email-masked]>.
> >>>> o
> >>>> 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 <sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel%3csip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel>>"
> >>>> sip:[email-masked] <sip:[email-masked]>
> >>>> uri=sip:*99;phone-context=[email-masked] <sip:*99;phone-context=[email-masked]>
> >>>> c
> >>>> x
> >>>> xx.mccxxx.3gppnetwork.org <http://xx.mccxxx.3gppnetwork.org/>;user=phone,response="",nonce="",realm="",
> >>>> u
> >>>> s
> >>>> ername=[email-masked]<mailto:xxx <mailto:ername=[email-masked]%3cmailto:xxx>
> >>>> x x [email-masked] <mailto:[email-masked]>>
> >>>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org <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>
> >>>> P-Access-Network-Info:
> >>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org <http://ims.mncxxx.mccxxx.3gppnetwork.org/>;orig-ioi=ims.
> >>>> m
> >>>> ncxxx.mccxxxx.3gppnetwork.org <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>
> >>>> sip:[email-masked];sescase=orig;regs <sip:[email-masked];sescase=orig;regs>
> >>>> t
> >>>> a
> >>>> te=reg
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> Cc: Zerr, Brad <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Marc 
> >>>> Petit-Huguenin 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen 
> >>>> Jennings <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Eric Rescorla 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy, 
> >>>> Arthur <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> sip:*55;phone-context=[email-masked] <sip:*55;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone
> >>>>
> >>>> …is ok, but;
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=[email-masked] <sip:#55;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context=ims.mnc420.mc <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>
> >>>> c
> >>>> 3 [email-masked];user=phone <mailto:[email-masked];user=phone>>
> >>>>
> >>>> …is NOT ok. Instead:
> >>>>
> >>>> To:
> >>>> sip:%2355;phone-context=[email-masked] <sip:%2355;phone-context=[email-masked]>.
> >>>> mcc312.3gppnetwork.org <http://mcc312.3gppnetwork.org/>;user=phone
> >>>>
> >>>> …will have to be used.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>> From: Zerr, Brad <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen 
> >>>> Jennings <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> Cc: [email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>;
> >>>> Eric Rescorla <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy, 
> >>>> Arthur <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> sip:*55;phone-context=[email-masked] <sip:*55;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=[email-masked] <sip:#55;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context=ims.mnc420.mc <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>
> >>>> c
> >>>> 3 [email-masked];user=phone <mailto:[email-masked];user=phone>>
> >>>>
> >>>> From: Christer Holmberg
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Cullen 
> >>>> Jennings <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Zerr, Brad 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR Mail List 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> Cc: [email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>;
> >>>> Eric Rescorla <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson 
> >>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy, 
> >>>> Arthur <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>> sip:*55;phone-context=[email-masked] <sip:*55;phone-context=[email-masked]>.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone
> >>>> ....
> >>>>
> >>>>> From: stir <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>> 
> >>>>> To: Zerr, Brad <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; IETF STIR 
> >>>>> Mail List <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>>> Cc: [email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>;
> >>>>> Eric Rescorla <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Jon Peterson 
> >>>>> <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>; Toy, 
> >>>>> Arthur <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>> wrote:
> >>>>>
> >>>>> Good Morning.
> >>>>>
> >>>>> sip:*55;phone-context=[email-masked] <sip:*55;phone-context=[email-masked]>.
> >>>>> m
> >>>>> cc312.3gppnetwork.org <http://cc312.3gppnetwork.org/>;user=phone
> >>>>>
> >>>>> It should be this
> >>>>>
> >>>>> To:
> >>>>> sip:%2A55;phone-context=[email-masked] <sip:%2A55;phone-context=[email-masked]>
> >>>>> 2
> >>>>> 0
> >>>>> .mcc312.3gppnetwork.org <http://mcc312.3gppnetwork.org/>;user=phone
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> 
> 
> 
> 
> --
> Marc Petit-Huguenin
> 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://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>
> For more information please visit http://www.mimecast.com <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>
>  
> 
> For more information please visit http://www.mimecast.com <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>
>  
> 
> For more information please visit http://www.mimecast.com <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>

---

From: "Zerr, Brad" <[email-masked]>
Date: Mon, 19 Apr 2021 20:33:15 +0000

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.

Sent: Monday, April 19, 2021 2:48 PM

Hi Brad, All,

Since this is IETF list, can anyone justify why we want to sign sip:*99 as dest for any general SIP scenario?

-Chris

On Apr 8, 2021, at 4:25 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Hi Brad,

Regards,

Christer

Hi Christer,

Hi Brad,

Regards,

Christer

Hi all,

To: sip:%2355;phone-context=[email-masked]<sip:%2355;phone-context=[email-masked]>.mcc312.3gppnetwork.org<http://mcc312.3gppnetwork.org>;user=phone

Recommendations?

Hi,

>>>>> cxxx.3gppnetwork.org<http://cxxx.3gppnetwork.org/>;user=phone
>>>>>
>>>>> 2. Section 8.1
>>>>>
>>>>> orig2: ip:[email-masked]<mailto:[email-masked]>
>>>>

Regards,

Christer

>>>> x x x.mcc3xxx.3gppnetwork.org<http://x.mcc3xxx.3gppnetwork.org/>;user=phone SIP/2.0
>>>> To:
>>>> cxxx.3gppnetwork.org<http://cxxx.3gppnetwork.org/>;user=phone
>>>> From:
>>>> xx.mccxxx.3gppnetwork.org<http://xx.mccxxx.3gppnetwork.org/>;user=phone,response="",nonce="",realm="",
>>>> u
>>>> s
>>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org<http://ims.mncxxx.mccxxx.3gppnetwork.org/>;orig-ioi=ims.
>>>> m
>>>> c312.3gppnetwork.org<http://c312.3gppnetwork.org/>;user=phone
>>>>
>>>> …is ok, but;
>>>>
>>>> To:
>>>> sip:#55;phone-context=[email-masked]<sip:#55;phone-context=[email-masked]>.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org<http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context=ims.mnc420.mc<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>
>>>> c
>>>> sip:%2355;phone-context=[email-masked]<sip:%2355;phone-context=[email-masked]>.
>>>> mcc312.3gppnetwork.org<http://mcc312.3gppnetwork.org/>;user=phone
>>>>
>>>> …will have to be used.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> c312.3gppnetwork.org<http://c312.3gppnetwork.org/>;user=phone
>>>>
>>>> To:
>>>> sip:#55;phone-context=[email-masked]<sip:#55;phone-context=[email-masked]>.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org<http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context=ims.mnc420.mc<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>
>>>> c
>>>> c312.3gppnetwork.org<http://c312.3gppnetwork.org/>;user=phone
>>>> ....
>>>>
>>>> To: sip:[email-masked];user=phone<sip:[email-masked];user=phone>
>>>> ....
>>>>
>>>>> cc312.3gppnetwork.org<http://cc312.3gppnetwork.org/>;user=phone
>>>>>
>>>>> It should be this
>>>>>
>>>>> To:
>>>>> .mcc312.3gppnetwork.org<http://mcc312.3gppnetwork.org/>;user=phone
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --

--
Marc Petit-Huguenin
Email: [email-masked]<mailto:[email-masked]>
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://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>
Profile: https://www.linkedin.com/in/petithug<https://www.linkedin.com/in/petithug>

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
---------------------------------------------------------------------------------------

---

From: Chris Wendt <[email-masked]>
Date: Tue, 20 Apr 2021 10:22:03 -0400

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 <[email-masked]> wrote:
> 
> Good afternoon, Chris.
>  
> On Apr 8, 2021, at 4:25 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>  
> To: sip:%2355;phone-context=[email-masked] <sip:%2355;phone-context=[email-masked]>.mcc312.3gppnetwork.org <http://mcc312.3gppnetwork.org/>;user=phone
>  
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context= <sip:*55;phone-context=>ims.mnc420.mc <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>
> >>>> c
> >>>> c312.3gppnetwork.org <http://c312.3gppnetwork.org/>;user=phone<sip:*55;phone-context= <sip:*55;phone-context=>ims.mnc420.mc <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>
> >>>> c

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 20 Apr 2021 14:49:52 +0000

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 <[email-masked]>
Date: Tuesday, April 20, 2021 at 7:22 AM
To: "Zerr, Brad" <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Cullen Jennings <[email-masked]>, IETF STIR Mail List <[email-masked]>, Eric Rescorla <[email-masked]>, "Peterson, Jon" <[email-masked]>, "Toy, Arthur" <[email-masked]>
Subject: Re: [stir] RFC 8224

Hi Brad,

-Chris

On Apr 19, 2021, at 4:33 PM, Zerr, Brad <[email-masked]<mailto:[email-masked]>> wrote:

Good afternoon, Chris.

Hi Brad, All,

-Chris

Hi,

Regards,

Christer

Hi Brad,

Regards,

Christer

Hi Christer,

Hi Brad,

Regards,

Christer

Get Outlook for iOS<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm4_Mp3zA$ >

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=[email-masked]<https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$ >;user=phone

Recommendations?

Hi,

>>>>> cxxx.3gppnetwork.org<https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$ >;user=phone
>>>>>
>>>>> 2. Section 8.1
>>>>>
>>>>> 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$ >
>>>>>

Regards,

Christer

>>>> x x x.mcc3xxx.3gppnetwork.org<https://urldefense.com/v3/__http://x.mcc3xxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm2TTnri4$ >;user=phone SIP/2.0
>>>> To:
>>>> cxxx.3gppnetwork.org<https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$ >;user=phone
>>>> From:
>>>> xx.mccxxx.3gppnetwork.org<https://urldefense.com/v3/__http://xx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmrKVq_1I$ >;user=phone,response="",nonce="",realm="",
>>>> u
>>>> s
>>>> 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:
>>>> -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$ >
>>>> c312.3gppnetwork.org<https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$ >;user=phone
>>>>
>>>> …is ok, but;
>>>>
>>>> To:
>>>> 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
>>>> mcc312.3gppnetwork.org<https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$ >;user=phone
>>>>
>>>> …will have to be used.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> c312.3gppnetwork.org<https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$ >;user=phone
>>>>
>>>> To:
>>>> 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
>>>> c312.3gppnetwork.org<https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$ >;user=phone
>>>> ....
>>>>
>>>>> cc312.3gppnetwork.org<https://urldefense.com/v3/__http://cc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmfRONVeE$ >;user=phone
>>>>>
>>>>> It should be this
>>>>>
>>>>> To:
>>>>> .mcc312.3gppnetwork.org<https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$ >;user=phone
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --

--
Marc Petit-Huguenin
Email: [email-masked]<mailto:[email-masked]>
Blog: 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://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmoI6LC4M$ 

________________________________
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmvaSxUkY$ <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$ >
________________________________

For more information please visit https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmvaSxUkY$ <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 email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmvaSxUkY$ <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 email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit https://urldefense.com/v3/__http://www.mimecast.com__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmvaSxUkY$ <https://urldefense.com/v3/__http://www.mimecast.com/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmLPaDIuo$ >

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Apr 2021 11:10:45 -0400

I have a border question: What if the destination is phone number +
extension as in sip:[email-masked]? 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=
[email-masked]> 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 <[email-masked]>
> *Date: *Tuesday, April 20, 2021 at 7:22 AM
> *To: *"Zerr, Brad" <[email-masked]>
> *Cc: *Christer Holmberg <[email-masked]>, Marc
> Petit-Huguenin <[email-masked]>, Cullen Jennings <[email-masked]>,
> IETF STIR Mail List <[email-masked]>, Eric Rescorla <[email-masked]>,
> "Peterson, Jon" <[email-masked]>, "Toy, Arthur" <[email-masked]>
> *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
>
>
>
> 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.
>
>
>
>
>
>
> *From:* Chris Wendt <[email-masked]>
> *Sent:* Monday, April 19, 2021 2:48 PM
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Zerr, Brad <[email-masked]>; Marc Petit-Huguenin <
> [email-masked]>; Cullen Jennings <[email-masked]>; IETF STIR Mail
> List <[email-masked]>; Eric Rescorla <[email-masked]>; Jon Peterson <
> [email-masked]>; Toy, Arthur <[email-masked]>
> *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.
>
>
>
> 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
>
>
>
>
> 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 <[email-masked]>
> *Sent:* torstai 8. huhtikuuta 2021 22.56
> *To:* Christer Holmberg <[email-masked]>; Marc
> Petit-Huguenin <[email-masked]>; Chris Wendt <
> [email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> *From:* Christer Holmberg <[email-masked]>
> *Sent:* Thursday, April 8, 2021 2:34 PM
> *To:* Zerr, Brad <[email-masked]>; Marc Petit-Huguenin <
> [email-masked]>; Chris Wendt <[email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> 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 <[email-masked]>
> *Sent:* torstai 8. huhtikuuta 2021 22.27
> *To:* Christer Holmberg <[email-masked]>; Marc
> Petit-Huguenin <[email-masked]>; Chris Wendt <
> [email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *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.
>
>
>
>
>
>
> *From:* Christer Holmberg <[email-masked]>
> *Sent:* Thursday, April 8, 2021 2:21 PM
> *To:* Zerr, Brad <[email-masked]>; Marc Petit-Huguenin <
> [email-masked]>; Chris Wendt <[email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *Subject:* Re: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> Get Outlook for iOS
> <https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm4_Mp3zA$>
> ------------------------------
>
> *From:* Zerr, Brad <[email-masked]>
> *Sent:* Thursday, April 8, 2021 10:16:44 PM
> *To:* Christer Holmberg <[email-masked]>; Marc
> Petit-Huguenin <[email-masked]>; Chris Wendt <
> [email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *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=[email-masked].
> 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?
>
>
>
>
>
>
> *From:* Christer Holmberg <[email-masked]>
> *Sent:* Wednesday, April 7, 2021 4:00 PM
> *To:* Marc Petit-Huguenin <[email-masked]>; Zerr, Brad <
> [email-masked]>; Chris Wendt <[email-masked]>
> *Cc:* Cullen Jennings <[email-masked]>; IETF STIR Mail List <[email-masked]>;
> Eric Rescorla <[email-masked]>; Jon Peterson <[email-masked]>;
> Toy, Arthur <[email-masked]>
> *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:
> >>>>> orig3: tel:xxxxxxxxx <xxxxxxxxx>
> >>>>>
> >>>>> 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
> <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$>
> >>>>>
> >> When user=phone is present, the user part is encoded as a
> telephone-subscriber (RFC 2806), which may contain a phone-context.
> >
> 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:
> >
> >>>>> 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.
> >>>>
> >>>> 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.
> >>>>
> >>>> x x x.mcc3xxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://x.mcc3xxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm2TTnri4$>;user=phone
> SIP/2.0
> >>>> To:
> >>>> cxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
> ;user=phone
> >>>> From:
> >>>> 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
> >"
> >>>> Accept-Contact:
> *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
> >>>> P-Asserted-Identity: tel:xxxxxxxxx <xxxxxxxxx>
> >>>> xx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://xx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmrKVq_1I$>
> ;user=phone,response="",nonce="",realm="",
> >>>> u
> >>>> s
> <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:
> >>>> -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
> <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$>
> <[email-masked]%3cmailto:[email-masked]%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>> 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 <
> [email-masked]<mailto:[email-masked]>>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> …is ok, but;
> >>>>
> >>>> To:
> >>>> 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
> >>>> mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>
> >>>> …will have to be used.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> <[email-masked]%3cmailto:[email-masked]%0b>>>>>
> o
> >>>> m
> >>>>>> ; Marc Petit-Huguenin
> >>>> 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.
> >>>>
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> To:
> >>>> 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
> <[email-masked]%3cmailto:[email-masked]%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>>> 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 '#'.
> >>>>
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>> ....
> >>>>
> >>>>> 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
> >>>>> 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
> >>>>>
> >>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <
> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]
> <[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]%3cmailto:[email-masked]>>>>
> wrote:
> >>>>>
> >>>>> Good Morning.
> >>>>>
> >>>>> cc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://cc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmfRONVeE$>
> ;user=phone
> >>>>>
> >>>>> It should be this
> >>>>>
> >>>>> To:
> >>>>> .mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
>
>
>
>
> --
> Marc Petit-Huguenin
> 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$>
> <https://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmoI6LC4M$>
>
>
> ------------------------------
>
>
> ------------------------------
>
> <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$>
> ------------------------------
>
>
> ------------------------------
>
>
> ------------------------------
>
> <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$>
> ------------------------------
>
>
> ------------------------------
>
>
> ------------------------------
>
> <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$>
> ------------------------------
>
>
>
>
> ------------------------------
>
>
> ------------------------------
>
> <https://urldefense.com/v3/__http://www.mimecast.com/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmLPaDIuo$>
>
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 Apr 2021 08:10:00 -0700

I think that the issue is not how to canonicalize these dialstrings -- RFC 8224 is already telling us what to do, and that's also the case for numbers like "*55".  The problem is that these dialstring should not even be signed in the first place, and that's what is missing in RFC 8224.

Basically there should be an additional step that says phone numbers that are not already E.164 numbers (in a SIP URI with a user=phone extension, or in a TEL URI), they should be rejected by the authentication service.  As it is written, RFC 8224 accepts everything and try to canonicalize, which is IMO the issue.

In concrete terms:

- Bullet points 2 and 3 of section 8.3 should be removed.
- Section 8.3 should add a paragraph that says that there is a 3rd category beyond Telephone Numbers and URIS: Non-routeable Telephone Numbers (NTN), and that if an INVITE contains an NTN then the INVITE should be rejected.
- Bullet points 2 and 3 of section 8.3 should be reworked as informative text that explains what a service *before* the authentication service could do with such rejection -- which can be 1) bypassing the authentication service, 2) convert the NTN into a routable number and resubmit it to the authentication service or 3) propagate the rejection back to the caller.