Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Jul 2013 17:53:10 +0000

>>I don't think I've heard anyone here (yet,
>> anyway) proposing an alternative architecture, just a change to the
>> digest-string and an addition to the types of signing authority.
>
>Choosing between publishing credentials versus publishing public keys is
>at least one example of competing choices that are quite basic in the
>design model for this authorization validation service.
>
>So, for example, using a DKIM-derived scheme is quite a different
>architecture from the one you've proposed.

Actually, RFC4474 is totally agnostic to how credentials are acquired, as
I've said several times in this thread. The URI in Identity-Info is always
just a hint, RFC4474 says you can ignore it if you already have a
credential or have an alternate means of acquiring credentials. I've also
pointed out that Identity-Info can already point to the DNS. So it's not
clear to me in what sense DKIM's key delivery falls outside this model.

>> The changes we need to make in STIR to the digest-string are, with one
>> exception, changes we would make regardless of whether or not the From
>> header field value contained a telephone number. They are changes that
>> will make this work with existing deployments. The one exception is the
>> canonicalization algorithm for telephone numbers we've discussed on the
>> list: that work is specific to telephone numbers.
>
>The experience with canonicalization algorithms for DKIM -- and it, too,
>had to deal with in-transit modifications -- makes clear that it's a
>topic with challenges and compromises.  (Hmmm.  "compromises" might be a
>pun, here.)

The variety of canonicalization under discussion here (over in that "URI
Format" thread), where the originator and terminator must synthesize
identical copies of a string that does not appear in the message itself,
has no corollary in any email practice I'm aware of.

>> If we're fixing the rest
>> of the digest-string for the TN case, though, we should also fix it for
>> the greenfield case. The greenfield case doesn¹t introduce any new
>> requirements for this, say. It would not save us any work to treat this
>>as
>> a separate effort from obsoleting the digest-string of RFC4474.
>
>I'm not understanding how concern for RFC4474 affects the technical work
>on this.

This is basically an administrative question about how we steer and
organize the work.

>> The addition of a new category of signing authority for telephone
>>numbers
>> isn't even a wire protocol change, as I've previously pointed out.
>
>"new category of signing authority"?  Sorry for my confusion, but I
>don't know what that means.

Signers that have authority for telephone numbers.

>> Identity-Info is already quite flexible in terms of what URI types it
>> supports (including potentially dns URIs). The new work that needs to be
>
>I missed where the DNS URI (dns:xxxxx) construct of RFC 4501 came into
>the discussion or how it's relevant.

As a URI in Identity-Info (again, this has been discussed several times
now).

>> done here is on how we compare the (canonicalized) From telephone number
>> with the authority of the signer.
>
>"compare the...number with the authority of the signer"?  Apologies
>again but I'm not understanding what that means.  How is "comparison
>with [an] authority" likely to play into validation?

To ascertain the reference integrity of the identity with the authority of
the signature.

>> But even the logic that inspects the
>>>From field to determine if it contains a telephone number needs to be
>> cognizant of the existence of greenfield identifiers, and trying to cast
>> this such that it operates in complete isolation from the world of
>> greenfield SIP URIs will not be conducive to a robust solution.
>
>Specify what it is to look for and that it is to ignore everything else,
>and things get pretty simple.  It's like ignoring header fields that the
>processor doesn't know.  And it has the advantage that it's both robust
>and simple.

Being able to differentiate a user part that is a phone number from a user
part that is not is not entirely trivial, as has been previously discussed
in this thread. A verifier that receives a request needs to figure out if
the user part is a telephone number or not. Ideally, the verifier would
understand the handling of the case where it is not.

>By the way, you seem to be using 'greenfield" as a well-recognized
>qualifier, but I can't find explanatory reference to it.  Please explain.

I mean SIP URIs with a user@domain format, where the user part is not a
telephone number.

>> I have a
>> hard time seeing an argument that it would be better to deploy
>> verification services that can only understand telephone numbers, given
>> the enormous overlap in functionality with understanding native SIP
>>URIs,
>> and the fact that the standardization work on that is already done.
>
>If you said "large scale deployment and use work that is already done",
>that might be more telling...
>
>As for the referenced overlap, that bodes well for making the later,
>incremental work tractable.

Again, this is a question of whether greenfield identifiers are
incremental work beyond STIR, or if STIR is incremental work beyond
greenfield identifiers. By historical accident, it turns out to be the
latter.

Jon Peterson
Neustar, Inc.

>
>d/
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 12:10:28 -0700

Jon,

> Actually, RFC4474 is totally agnostic to how credentials are

Using the word "credential" highlights the disconnect happening here.
DKIM doesn't use credentials.  But again, my core point was that we are
already seeing quite a bit of technical debate across many aspects of
the current, narrower topic.

As for being agnostic, that's an example of the distraction that RFC4474
provides for the current discussion.  Lots of detail, much of which is
not relevant to the current topic, /and/ not enough detail to be a
complete service.

> I've said several times in this thread. The URI in Identity-Info is
> always just a hint, RFC4474 says you can ignore it if you already
> have a

I don't understand how that's relevant to my note.

To the extent that you are citing the presence of even more choice,
that's exactly the problem.

There's more than enough to debate and specify, within the narrow
confines of the very specific problem that's been posed here.  It does
not need the additional baggage of an un-deployed, old specification
that is both broad and -- as you've just highlighted as 'agnostic' --
incomplete.

>> The experience with canonicalization algorithms for DKIM -- and it,
>> too, had to deal with in-transit modifications -- makes clear that
>> it's a topic with challenges and compromises.  (Hmmm.
>> "compromises" might be a pun, here.)
> 
> The variety of canonicalization under discussion here (over in that
> "URI Format" thread), where the originator and terminator must
> synthesize identical copies of a string that does not appear in the
> message itself, has no corollary in any email practice I'm aware of.

So the current situation does not involve challenges and compromises?
That was, after all, all that I said about the experience with DKIM
canonicalization.

Your insisting that the current situation has more variety -- and
presumably therefore more challenges -- actually emphasizes nicely the
point I was making, which is that the current effort has more than
enough work to do, by staying strictly within the confines of the
current task.

>>> If we're fixing the rest of the digest-string for the TN case,
>>> though, we should also fix it for the greenfield case. The
>>> greenfield case doesn¹t introduce any new requirements for this,
>>> say. It would not save us any work to treat this as a separate
>>> effort from obsoleting the digest-string of RFC4474.
>> 
>> I'm not understanding how concern for RFC4474 affects the technical
>> work on this.
> 

I have no idea what that response means.

I cited a question of relevance to technical work and you somehow
converted that to an 'administrative' concern, whatever that means.

>>> The addition of a new category of signing authority for
>>> telephone numbers isn't even a wire protocol change, as I've
>>> previously pointed out.
>> 
>> "new category of signing authority"?  Sorry for my confusion, but
>> I don't know what that means.
> 

ack.

Just to be clear, since you cite 'addition of a new' category, who was
the 'old' category of signing authority and what was being signed?

>>> Identity-Info is already quite flexible in terms of what URI
>>> types it supports (including potentially dns URIs). The new work
>>> that needs to be
>> 
>> I missed where the DNS URI (dns:xxxxx) construct of RFC 4501 came
>> into the discussion or how it's relevant.
> 
> As a URI in Identity-Info (again, this has been discussed several
> times now).

Jon, I looked and didn't find a reference to the DNS URI in the current
documents and don't recall any in the mailing list discussion.

I'm asking for a pointer that is more precise than "it's been discussed
before".

>>> done here is on how we compare the (canonicalized) From telephone
>>> number with the authority of the signer.
>> 
>> "compare the...number with the authority of the signer"?
>> Apologies again but I'm not understanding what that means.  How is
>> "comparison with [an] authority" likely to play into validation?
> 
> To ascertain the reference integrity of the identity with the
> authority of the signature.

Sorry, I'm still confused.  Perhaps you merely mean verify authorization
to use the number -- that is, that the signature proves authorization?

>>> cognizant of the existence of greenfield identifiers, and trying
>>> to cast this such that it operates in complete isolation from the
>>> world of greenfield SIP URIs will not be conducive to a robust
>>> solution.
>> 
>> Specify what it is to look for and that it is to ignore everything
>> else, and things get pretty simple.  It's like ignoring header
>> fields that the processor doesn't know.  And it has the advantage
>> that it's both robust and simple.
> 
> Being able to differentiate a user part that is a phone number from a
> user part that is not is not entirely trivial, as has been previously
> discussed in this thread. A verifier that receives a request needs to
> figure out if the user part is a telephone number or not. Ideally,
> the verifier would understand the handling of the case where it is
> not.

1. To the extent that ascertaining the telephone number is really a
heuristic, it's unlikely the service will work globally -- heuristics
aren't deterministic and therefore they fail sometimes; to the extent
that there is a deterministic algorithm, that's a hassle, but it can work.

2. As for your 'ideally' sentence, happily that's out of scope for this
work.

> I mean SIP URIs with a user@domain format, where the user part is not
> a telephone number.

oh.  (Is that documented anywhere?)

>>> I have a hard time seeing an argument that it would be better to
>>> deploy verification services that can only understand telephone
>>> numbers, given the enormous overlap in functionality with
>>> understanding native SIP URIs, and the fact that the
>>> standardization work on that is already done.
>> 
>> If you said "large scale deployment and use work that is already
>> done", that might be more telling...
>> 
>> As for the referenced overlap, that bodes well for making the
>> later, incremental work tractable.
> 
> greenfield identifiers. By historical accident, it turns out to be
> the latter.

You mean the work that hasn't gained deployment 6 years after
standardization?

Sometimes baggage is a boat anchor.

On 7/1/2013 10:57 AM, Peterson, Jon wrote:
>> So are you saying that verifiers can basically just ignore the HTTP URL?
>> I hadn't noticed that exception before in RFC 4474.  
...
> That has always been true in RFC4474, yes. See the language in
> Section 6, step 1: "SIP entities SHOULD discover this certificate by 

That's rather less casual a normative statement that was implied by your
comment here.  Deviating from a 'should' is supposed to be exceptional
and based on very high levels of specialized knowledge.

d/

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 09:50:20 -0400

Catching up (I was out for a week)
On Jun 28, 2013, at 7:09 PM, Dave Crocker <[email-masked]> wrote:

> The experience with canonicalization algorithms for DKIM -- and it, too, had to deal with in-transit modifications -- makes clear that it's a topic with challenges and compromises.  (Hmmm.  "compromises" might be a pun, here.)
e.164s are much more constrained than the email address issues DKIM has to deal with.  We could have challenges with local dial plans, and we've been discussing those issues, but the easy way out on those is that they may not be covered if both ends don't understand the dial plan the same way.

So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant.

Brian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jul 2013 07:10:18 -0700

> So far, while we have one issue I'm concerned with (verifier not being able to extract a canonical e.164 from the content of "From"), I don't think the DKIM experience is particularly relevant.

Brian,

Thanks.  Good to hear.

I assume there is a document that specifies all of the variations that 
will be encountered and how to deterministically and successfully 
transform them into the single, canonical representation?

Absent that, this topic remains a likely source of non-interoperability.

d/

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 10:22:58 -0400

There are a lot of local variations out there, but they all have the property that in order to route them, you need to be able to figure out at least the "left" part of the e.164 is, and the right part has to pass unscathed in order to work.  Since everyone, and I mean everyone, dealing with these systems knows what e.164s are, and how they work, I don't think it's necessary, or even possible to describe all of the various ways the strings might appear and what to do with them.

All we need say is that in order to work, the header contents has to be able to have the canonical e.164 extracted with no knowledge at the validator, and validations can occur anywhere in the call path.  We'll dress up that text a lot I am sure, but the notion that we could write, or need a document describing all possible variations of how telephone numbers may appear and how to extract the e.164 in each of them seems to me to be silly.

It may be possible to specify an algorithm however.

Brian

On Jul 3, 2013, at 10:10 AM, Dave Crocker <[email-masked]> wrote:

> I assume there is a document that specifies all of the variations that will be encountered and how to deterministically and successfully transform them into the single, canonical representation?
>

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 10:39:01 -0400

Could someone provide a few examples?  I have to say I find this thread hard to follow.  I trust the individuals making the arguments to be knowledgeable and honest, but personally I have little experience with this "FROM header manipulation" that I'm told is so rampant.  

The only example I can think of is the "SIP trunking" use case I raised previously (user part of URI in FROM and/or TO header may be significant only within the dial plan of the associated Enterprise) which was ruled out of scope for this activity.  So I'm puzzled, what use cases there are that (a) are in scope for this exercise, and (b) involve manipulation of the user part of the URI in the FROM header.

Apologies in advance if this is obvious to everyone else and I'm the only one who doesn't "get it".

Thanks,

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 9:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

> Absent that, this topic remains a likely source of non-interoperability.

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 3 Jul 2013 16:44:44 +0200

> Apologies in advance if this is obvious to everyone else and I'm the only one who doesn't "get it".
RFC 3966 on the Tel URI got some good reading.
http://tools.ietf.org/html/rfc3966#section-5.1.4

Think of it as "anything that starts with a country code".  In every platform I have installed, we have those algorithms.

/O

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 10:54:48 -0400

The From problem is lack of country codes, and maybe worse.  Consider these possible From: contents 
5551212
2025551212
12025551212
+12025551212
and of course all the variations with parens, spaces, hyphens, commas, periods, etc.

Although the first is getting really rare, I think it still happens

The problem with these is when they appear in From on an international call - the first 2 are the real problems.  They would have to be rewritten.

With To:, you get the variations with dial 9/8/... in enterprise systems, and the 011 style prefix 

Brian

---

From: Dan York <[email-masked]>
Date: Wed, 3 Jul 2013 14:58:14 +0000

Tim,

On 7/3/13 10:39 AM, "Dwight, Timothy M (Tim)" <[email-masked]>
wrote:

>Could someone provide a few examples?  I have to say I find this thread
>hard to follow.  I trust the individuals making the arguments to be
>knowledgeable and honest, but personally I have little experience with
>this "FROM header manipulation" that I'm told is so rampant.

Hadriel wrote up a draft on this a few years back that identifies a couple
of instances where this occurs:

http://tools.ietf.org/html/draft-kaplan-sip-uris-change-00

He wrote that up back in 2008 when we were having an earlier debate about
how we could improve RFC 4474.

Dan

---

From: <[email-masked]>
Date: Wed, 3 Jul 2013 15:08:07 +0000

I agree, I'm not sure I would go as far as calling the idea of defining all possible variations "silly" but if, as I understand it, the idea was (at least) to come up with an algorithm/mapping to describe how a CLI expressed in the dialing plan (or the national portion of the E.164 number) can be converted into a full E.164 form for example, I think this would indeed be overly ambitious. 

For example, I regularly deal with a public dialling plan that requires about 20 if/then/else clauses on the value of the national Subscriber Number to do just that. And that's only for one (arguably quite complex yet closed) national dialling plan. There are more than 200 of these on the planet, each of which potentially has its own national variations and change over time.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 4:55 PM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 15:13:40 +0000

All,

It helps to read E.164.
It is a string of digits, max 15, no other characters, with CC, NDC, and SN.
(There are variations on the names for those parts, but the concept is the
same.)
If you provide a specification that unambiguously delimits that, you are
golden.

Do not inject confusion by introducing dialing sting prefixes.
Do not inject confusion by introducing trunking indicators.
Do not inject confusion by introducing methods to group digits.

If you want the phone number to get anywhere globally, you need to know how
to generate the E.164.
Any domain worth its salt knows how to go from a local representation to a
canonical one.
(And there are local representation secret sauce folks who know how to do
that.)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Wednesday, July 03, 2013 10:55 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

The From problem is lack of country codes, and maybe worse.  Consider these
possible From: contents 
5551212
2025551212
12025551212
+12025551212
and of course all the variations with parens, spaces, hyphens, commas,
periods, etc.

The problem with these is when they appear in From on an international call
- the first 2 are the real problems.  They would have to be rewritten.

With To:, you get the variations with dial 9/8/... in enterprise systems,
and the 011 style prefix 

Brian

hard to follow.  I trust the individuals making the arguments to be
knowledgeable and honest, but personally I have little experience with this
"FROM header manipulation" that I'm told is so rampant.  
> 
> The only example I can think of is the "SIP trunking" use case I raised
previously (user part of URI in FROM and/or TO header may be significant
only within the dial plan of the associated Enterprise) which was ruled out
of scope for this activity.  So I'm puzzled, what use cases there are that
(a) are in scope for this exercise, and (b) involve manipulation of the user
part of the URI in the FROM header.
> There are a lot of local variations out there, but they all have the
property that in order to route them, you need to be able to figure out at
least the "left" part of the e.164 is, and the right part has to pass
unscathed in order to work.  Since everyone, and I mean everyone, dealing
with these systems knows what e.164s are, and how they work, I don't think
it's necessary, or even possible to describe all of the various ways the
strings might appear and what to do with them.
> 
> All we need say is that in order to work, the header contents has to be
able to have the canonical e.164 extracted with no knowledge at the
validator, and validations can occur anywhere in the call path.  We'll dress
up that text a lot I am sure, but the notion that we could write, or need a
document describing all possible variations of how telephone numbers may
appear and how to extract the e.164 in each of them seems to me to be silly.
>>>> The experience with canonicalization algorithms for DKIM -- and it,
too, had to deal with in-transit modifications -- makes clear that it's a
topic with challenges and compromises.  (Hmmm.  "compromises" might be a
pun, here.)
>>> e.164s are much more constrained than the email address issues DKIM has
to deal with.  We could have challenges with local dial plans, and we've
been discussing those issues, but the easy way out on those is that they may
not be covered if both ends don't understand the dial plan the same way.
>>> 
>>> So far, while we have one issue I'm concerned with (verifier not being
able to extract a canonical e.164 from the content of "From"), I don't think
the DKIM experience is particularly relevant.
>> I assume there is a document that specifies all of the variations that
will be encountered and how to deterministically and successfully transform
them into the single, canonical representation?

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 11:18:46 -0400

Sure, but you get that the To has to go through rewrite to get it routed, but the From doesn't.

It's all well and good to wave your hands and say "all SIP UAs must put full e.164s in From" but it doesn't happen, and it's not going to happen.

Today, rewrites of From happen, but not always to e.164s.  We're either going to have to have those rewrites occur always to an e.164, include a full e.164 in a new header, or use P-A-I and require it be a full e.164 (or a combination).

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 15:18:30 +0000

The advantage we have is that the conversion of the From is done close to the origin, i.e., by somebody with local knowledge, even if it requires algorithms that are country-specific. For the reasons mentioned several times (CNAM, SS7, intercarrier compensation, voicemail, 911 ALI for wireless, etc.), this seems to work well enough in practice, even without a formal standard beyond E.164. I have no objection to describing common cases, but I don't think this is a major concern for interoperability as long as everyone agrees what the canonical form is. Only the canonical form matters for interoperability, i.e., the receiver doesn't have to understand in detail how it was arrived at and how much programmer sweat was involved.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 03, 2013 11:08 AM
To: Brian Rosen; Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 4:55 PM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 15:19:56 +0000

I don't think we need to define all the variations.
I don't think we need to define how to do the mapping.
We only need to define that the value used for validation be an E.164
number.
Then those systems can figure out how to convert.
After all, we need to define an interoperable spec, not someone's
implementation.

Mike

-----Original Message-----
[email-masked]

I agree, I'm not sure I would go as far as calling the idea of defining all
possible variations "silly" but if, as I understand it, the idea was (at
least) to come up with an algorithm/mapping to describe how a CLI expressed
in the dialing plan (or the national portion of the E.164 number) can be
converted into a full E.164 form for example, I think this would indeed be
overly ambitious. 

For example, I regularly deal with a public dialling plan that requires
about 20 if/then/else clauses on the value of the national Subscriber Number
to do just that. And that's only for one (arguably quite complex yet closed)
national dialling plan. There are more than 200 of these on the planet, each
of which potentially has its own national variations and change over time.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----

Brian

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 15:22:27 +0000

Then that tells me From is the wrong answer.

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Sure, but you get that the To has to go through rewrite to get it routed,
but the From doesn't.

It's all well and good to wave your hands and say "all SIP UAs must put full
e.164s in From" but it doesn't happen, and it's not going to happen.

Today, rewrites of From happen, but not always to e.164s.  We're either
going to have to have those rewrites occur always to an e.164, include a
full e.164 in a new header, or use P-A-I and require it be a full e.164 (or
a combination).

Brian

On Jul 3, 2013, at 11:13 AM, Michael Hammer <[email-masked]>
wrote:

> If you provide a specification that unambiguously delimits that, you 
> are golden.
> 
> If you want the phone number to get anywhere globally, you need to 
> know how to generate the E.164.
> Any domain worth its salt knows how to go from a local representation 
> to a canonical one.
> previously (user part of URI in FROM and/or TO header may be 
> significant only within the dial plan of the associated Enterprise) 
> which was ruled out of scope for this activity.  So I'm puzzled, what 
> use cases there are that
> (a) are in scope for this exercise, and (b) involve manipulation of 
> the user part of the URI in the FROM header.
>> 
>> Apologies in advance if this is obvious to everyone else and I'm the 
>> only
> one who doesn't "get it".
>> 
>> Thanks,
>> 
>> Tim
>> 
> property that in order to route them, you need to be able to figure 
> out at least the "left" part of the e.164 is, and the right part has 
> to pass unscathed in order to work.  Since everyone, and I mean 
> everyone, dealing with these systems knows what e.164s are, and how 
> they work, I don't think it's necessary, or even possible to describe 
> all of the various ways the strings might appear and what to do with them.
>> 
> validator, and validations can occur anywhere in the call path.  We'll 
> dress up that text a lot I am sure, but the notion that we could 
> write, or need a document describing all possible variations of how 
> telephone numbers may appear and how to extract the e.164 in each of them
seems to me to be silly.
> it's a topic with challenges and compromises.  (Hmmm.  "compromises" 
> might be a pun, here.)
> to deal with.  We could have challenges with local dial plans, and 
> we've been discussing those issues, but the easy way out on those is 
> that they may not be covered if both ends don't understand the dial plan
the same way.
> able to extract a canonical e.164 from the content of "From"), I don't 
> think the DKIM experience is particularly relevant.
>>> 
>>> 
>>> Brian,
>>> 
>>> Thanks.  Good to hear.
>>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 3 Jul 2013 17:31:01 +0200

> Then that tells me From is the wrong answer.
Or that having the UA sign anything is the wrong answer.

I think the UA in most cases has no idea on the E.164, it might be configured
as "steve's phone" or "74747". There is a session boarder where the SIP call
leaves one domain and enters another where the E.164 needs to be in place
and be verified/certified/something-ified.

/O

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 11:36:07 -0400

Leaving aside whether the UA signs, the UA creates the From.

It may well be true that the PBX or SP on the origination can determine the e.164 of From given the string the UA put in there to sign.  The problem isn't there.   The problem is when the call gets to the termination side and is being verified.  The verifier has to be able to extract the e.164 from the string.

If the variations are small enough, or a rewrite happens in the origination, we're okay.   If not, we have to do something else.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 15:37:39 +0000

We're retreading the same territory, but I don't think anybody is talking about rewriting From. The process is

Identity = Hash-and-sign(convert-to-E.164(From))

As long as the receiver can perform the same operation and get the same result, this works. For the reasons now repeated several times, receivers do seem to be able to make sense of inter-provider From information, as they use it mechanically for a variety of purposes.

I just don't see the real problem - if From (and their SS7 kin) didn't work, callerID would fail altogether. It obviously doesn't, for almost all calls.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

On Jul 3, 2013, at 11:13 AM, Michael Hammer <[email-masked]>
wrote:

> All,
> 
> It helps to read E.164.
> It is a string of digits, max 15, no other characters, with CC, NDC, 
> and
SN.
seems to me to be silly.
the same way.

---

From: <[email-masked]>
Date: Wed, 3 Jul 2013 15:38:42 +0000

Yes, I quite agree, apologies if this wasn't clear: that's why I noted on a different thread that if that number cannot be provided in its full form, both calling and called parties will in most cases (eg they are on the same dialing plan) share an implicit context which makes the conversion to the full form feasible (for the callee if it's a CLI). The original question here as I understood it was whether there could exist somewhere a document that specifies all of the variations that will be encountered to avoid resorting to such an implicit context/"knowledge". I just don't think there is, and don't see how there could possibly be one.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 03, 2013 11:08 AM
To: Brian Rosen; Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 4:55 PM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 11:43:57 -0400

Here is an example of where I think we have a problem:

From: 2025551212

To: +44 800 505555

Any entity on the origination side, including an SS7 GW, would know that the e.164 for From is +12025551212

The problem is if the call arrives as all SIP, the UK phone or SP won't know that.

Brian

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 12:07:39 -0400

Thanks, Olle.  I guess you refer to the use of local (national significant) numbers?  That should have occurred to me.  We don't do that in our fixed-line VoIP networks (we always configure the device signal global (International format) E.164 numbers in FROM and TO.  But in mobile networks I know it is common to assign a temporary number (TLDN) to a visiting device, the format of which reflects the local numbering plan.  Historically this has occasionally caused some ambiguity, particularly if the Type of Number indication is somehow lost.  Interestingly, the resolution to such ambiguity (other than to not munge the Type of Number indication) is to "canonicalize" the TLDN on the originating side.

Is that it then?  All the use cases with which we're concerned, have to do with conversions between national significant numbers and global / International numbers?

If so, I think I understand how and where this 'canonicalization' can be performed.  It is however critically dependent on preservation of Type of Number (on the circuit switched side) and/or proper use and preservation of the 'phone-context' URI parameter (on the VoIP side).  When Hadriel says "it must be possible since it works today" he's mostly right.  There are occasional cases today where enough things go wrong that at the point of 'canonicalization' it's unclear whether the number is national or International.  But AFAIK that only happens when bad luck compounds protocol errors; and no specification we write will prevent either of those.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: Wednesday, July 03, 2013 9:45 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; Olle E. Johansson; [email-masked]; Brian Rosen
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

/O

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 12:10:52 -0400

I don't see a problem with any of those, assuming the phone-context URI parameter is properly used.  Of course if it's not, and you don't otherwise know where the call came from (e.g., by a trunk group parameter) you're in trouble.  But in that case the problem's unsolvable... which contradicts Hadriel's "trust me it works today" assertion.

Tim

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 9:55 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 16:11:06 +0000

Henning,

The Caller-ID argument seems to run along these lines:

SS7 PTSN works well, we get good caller ID.
SIP world is problematic, we get robo-calling.
Because we get good caller ID, we don't need to change how SIP operates
today.

That is a disconnect for me.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 11:38 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

We're retreading the same territory, but I don't think anybody is talking
about rewriting From. The process is

As long as the receiver can perform the same operation and get the same
result, this works. For the reasons now repeated several times, receivers do
seem to be able to make sense of inter-provider From information, as they
use it mechanically for a variety of purposes.

I just don't see the real problem - if From (and their SS7 kin) didn't work,
callerID would fail altogether. It obviously doesn't, for almost all calls.

-----Original Message-----
Michael Hammer

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 12:14:42 -0400

I thought we were talking about 'canonicalization' of the URI in the FROM header, at the terminating end.  

Sorry to have confused the issue.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 03, 2013 11:08 AM
To: Brian Rosen; Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 4:55 PM
To: Dwight, Timothy M (Tim)
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 16:25:01 +0000

I don't see the contradiction: Today, we get perfectly-formatted, but substantially-false, callerID. Just because it's fake doesn't mean it's bad-looking...

Indeed, the bad guys have every incentive to provide well-formatted numbers as otherwise the CNAM lookup will fail, defeating the purpose of rendering plausible textual caller ID information.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael Hammer [[email-masked]]
Sent: Wednesday, July 03, 2013 12:11 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Jul 2013 12:49:24 -0400

Both SIP and SS7 get caller-id's they recognize/treat/process as E.164 phone-numbers.
Both SIP and SS7 get caller-ids that do not actually belong to the source of the call request.

When investigated, it turns out that the problem is not that the sources meant to say X while the receiver believed they said Y.  Instead, the sources meant to say Y and the receiver understood it to be Y.  The problem is the source isn't actually authorized to claim Y.

-hadriel

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 12:52:38 -0400

Ah, so I wasn't as confused as I thought.  Good to know.  We are talking about being able to translate the value in the FROM header to an International E.164 number, on the terminating side of the call.  Not over-write the value in the message, but the 'convert-to-E.164' function has to return the same value on the terminating side as it did on the originating side.

So I'm back to my previous position - this is indeed possible, assuming enough contextual information is present.  Which in general it must be since as Hadriel repeatedly assures us, this all (usually) works today.  

The nature of the contextual information is different in SIP though.  If people are going to signal FROM headers with national significant numbers in the user part, they (or something in the path on the originating leg) had better be religious about appending the phone-context parameter, so that on the terminating leg it's possible to know what they meant.

tim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 17:07:04 +0000

Yes, but where are the false data being injected?

Also, these are links in a chain, that if one fails, the follow-on checks
will also fail.
If you have a large number of failures for valid users, then the recipient
cannot rely on the feature.
And, the end result is the same, meager adoption.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

I don't see the contradiction: Today, we get perfectly-formatted, but
substantially-false, callerID. Just because it's fake doesn't mean it's
bad-looking...

Indeed, the bad guys have every incentive to provide well-formatted numbers
as otherwise the CNAM lookup will fail, defeating the purpose of rendering
plausible textual caller ID information.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Michael
Hammer [[email-masked]]
Sent: Wednesday, July 03, 2013 12:11 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 13:07:40 -0400

Actually in networks with which I am familiar, the CNAM lookup is performed based on the URI in the P-A-ID header (if it's present).  Until / unless the caller finds a way to spoof that header, they can't 'finish the job' of pretending to be someone they're not.

Of course today there is a loophole provided by entities-that-resemble-carriers, who don't meaningfully populate P-A-ID (I say 'meaningfully' to intentionally rule out nonsense like all zero's).  If you were doing this type of mischief I guess you'd seek out such an entity.  

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 11:25 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; Dwight, Timothy M (Tim); [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

SS7 PTSN works well, we get good caller ID.
SIP world is problematic, we get robo-calling.
Because we get good caller ID, we don't need to change how SIP operates today.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 13:34:48 -0400

Right, unless the URI in the FROM header has something like phone-context=+1 the UK network would have to base its 'canonicalization' logic on something else.  If it's lucky it'll know more about where the call came from, e.g., an ingress trunk group, from which it can make inferences.  It can also consider whether there's a country with CC=2 (there isn't), and if so whether the remaining 9 digits could be a valid national significant number in that country;  then repeat for CC=20 and CC=202.  In my experience such checking is (in the circuit switched network) implementation specific and not always as rigorous as you would like.  We are saved by the fact that SS7 signaling is very reliable, so we don't often have to exercise such logic.  

I have seen cases where the caller ID for a call from a mobile roaming internationally, was presented as having come from a (non-existent) US area code.  It messes up not only the caller ID but a subsequent callback, should one be attempted.  This happened because the 'context' of the call was somehow lost and the terminating switch's logic for resolving that case wasn't robust.  

Fortunately in ISUP we very rarely lose the context of the call.  Unfortunately as we introduce VoIP our mechanisms for communicating such context (URI parameters) are not as rigidly adhered to as they should be.  So in SIP use cases such as you describe could be more problematic.  I conclude that in addition to the cryptographic security mechanisms we aim to define, we need to find a way to improve compliance, or at least clarify the ramifications of noncompliance, with existing specifications.

Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, July 03, 2013 10:44 AM
To: Henning Schulzrinne
Cc: [email-masked]; 'Michael Hammer'; Dwight, Timothy M (Tim); [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

From: 2025551212

To: +44 800 505555

Brian

On Jul 3, 2013, at 11:37 AM, Henning Schulzrinne <[email-masked]> wrote:

> We're retreading the same territory, but I don't think anybody is 
> talking about rewriting From. The process is
> 
>> knowledgeable and honest, but personally I have little experience 
>> with this "FROM header manipulation" that I'm told is so rampant.
>>> 
>> validator, and validations can occur anywhere in the call path.  
>> We'll dress up that text a lot I am sure, but the notion that we 
>> could write, or need a document describing all possible variations of 
>> how telephone numbers may appear and how to extract the e.164 in each 
>> of them
> seems to me to be silly.
>>> 
>>>>> Catching up (I was out for a week) On Jun 28, 2013, at 7:09 PM, 
>>>>> Dave Crocker <[email-masked]> wrote:
>>>>> 
>> able to extract a canonical e.164 from the content of "From"), I 
>> don't think the DKIM experience is particularly relevant.
>>>> 
>>>> 
>>>> Brian,
>>>> 
>>>> Thanks.  Good to hear.
>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 18:03:46 +0000

I'm probably missing something, but as far as I can tell, the situation today is:

(1) Most calls have well-formatted "From" (CgN, ANI, ...) information that is truthful.
(2) Some calls have well-formatted origin information that is spoofed.
(3) A very small fraction of calls have ill-formatted caller ID information, typically inserted by entities with something to hide or the occasionally clueless/bad-combination-of-circumstances cases.

With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate (3) calls should move into (1).

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 18:07:43 +0000

If they  don't, both numeric and textual callerID won't work at all, most likely (or will show random garbage). Large companies presumably want their calls to show usable callerID, so that people pick up the calls. (And individuals and small businesses will complain to the state PUC or the FCC.) I suspect that if United Airlines calls up their carrier and complains about mangled callerIDs, somebody at that carrier will try to get this fixed - at least at your company...

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 18:18:16 +0000

My impression from this thread was that (3) was more often the case, and (1)
was the minority.
And, that there was little incentive thus far to change that.
Thus, absence some "encouragement" from regulators, 
call completion is not impeded, since $$ come from call completion, not from
valid caller ID.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 2:04 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

I'm probably missing something, but as far as I can tell, the situation
today is:

(1) Most calls have well-formatted "From" (CgN, ANI, ...) information that
is truthful.
(2) Some calls have well-formatted origin information that is spoofed.
(3) A very small fraction of calls have ill-formatted caller ID information,
typically inserted by entities with something to hide or the occasionally
clueless/bad-combination-of-circumstances cases.

With validation, (1) would succeed, (2) would fail, as it should, and (3)
would remain as-is (and also fail validation, most likely). If anything, as
validation increases, since the originator of a call, particularly on the
commercial side, has every incentive for the call to complete, legitimate
(3) calls should move into (1).

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 18:19:57 +0000

Ummm....  who do I call to complain about calls from 800 numbers?  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Wednesday, July 03, 2013 2:08 PM
To: 'Dwight, Timothy M (Tim)'
Cc: [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

If they  don't, both numeric and textual callerID won't work at all, most
likely (or will show random garbage). Large companies presumably want their
calls to show usable callerID, so that people pick up the calls. (And
individuals and small businesses will complain to the state PUC or the FCC.)
I suspect that if United Airlines calls up their carrier and complains about
mangled callerIDs, somebody at that carrier will try to get this fixed - at
least at your company...

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Ah, so I wasn't as confused as I thought.  Good to know.  We are talking
about being able to translate the value in the FROM header to an
International E.164 number, on the terminating side of the call.  Not
over-write the value in the message, but the 'convert-to-E.164' function has
to return the same value on the terminating side as it did on the
originating side.

So I'm back to my previous position - this is indeed possible, assuming
enough contextual information is present.  Which in general it must be since
as Hadriel repeatedly assures us, this all (usually) works today.  

The nature of the contextual information is different in SIP though.  If
people are going to signal FROM headers with national significant numbers in
the user part, they (or something in the path on the originating leg) had
better be religious about appending the phone-context parameter, so that on
the terminating leg it's possible to know what they meant.

tim 

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 18:32:57 +0000

I don't think anybody has complete statistical data, but from what I can tell, for almost all domestic calls, callerID tends to work (whether it's spoofed or not). Given that a significant fraction of call origination is now VoIP (in some areas, close to 50%), courtesy of MSOs, there's usually some SIP in the call path.

Is your experience that a large fraction of your incoming calls have mangled callerID?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 2:18 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

My impression from this thread was that (3) was more often the case, and (1) was the minority.
And, that there was little incentive thus far to change that.
Thus, absence some "encouragement" from regulators, call completion is not impeded, since $$ come from call completion, not from valid caller ID.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 2:04 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

With validation, (1) would succeed, (2) would fail, as it should, and (3) would remain as-is (and also fail validation, most likely). If anything, as validation increases, since the originator of a call, particularly on the commercial side, has every incentive for the call to complete, legitimate
(3) calls should move into (1).

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Also, these are links in a chain, that if one fails, the follow-on checks will also fail.
If you have a large number of failures for valid users, then the recipient cannot rely on the feature.
And, the end result is the same, meager adoption.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 3 Jul 2013 18:33:35 +0000

Mike:
I think that (1) is actually the predominant case taking all calls in account. There is enough absolute number of calls that are (2) or (3) that it *is* a problem. When I don't get a good caller ID, I mostly get nothing, and indeed, there are some outbound services that have no caller ID or meaningful Charge Number/ANI.
I've had telemarketers spoof my office number on calls to others and it's a truly painful experience.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 2:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 18:43:28 +0000

I'll add that there are indeed rules against  "calls for which identifying information is missing or masked in ways  that frustrate intercarrier billing." See, for example, footnote 58 at

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-18A1.pdf

and references therein, in particular 47 CFR 64.1601, at

http://www.law.cornell.edu/cfr/text/47/64.1601

Henning

-----Original Message-----
From: PFAUTZ, PENN L [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 2:34 PM
To: Michael Hammer; Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 2:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 15:31:10 -0400

Henning,

I agree that there are multiple reasons for trying to improve compliance with use of URI parameters.  I'm a little concerned with statements I've seen to the contrary - I understand the frustration (related to their frequent misuse) but giving up and resorting to pure guessing, will just make things worse.  I think we're in agreement there.

You're correct that people (and companies) care that their caller ID / calling name is presented correctly.  They complain when it isn't, and we do our best to fix it.  It's a complicated system though, for example there may be calling name data for a given number in many 'CNAM databases', and it can take a while to track down and fix an error.  Something to think about with respect to the task at hand... it's easy to postulate 3rd parties contributing to the solution, but be careful what you ask for...

tim

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 15:43:29 -0400

Let's not get too carried away.

Much more than 50% of the time, calls today have valid (as in, properly formatted) calling party identification.
 
You're right about the fundamental driver being economic.  We get paid when the call completes.  But there are additional drivers that reach the same conclusion.  For example if there is no valid calling party identification, we don't know whose 'fault' that is.  We don't want to 'punish' the calling and called parties, who generally have no control over how the signaling messages that establish their call, are formatted.  

What we do is try and 'persuade' our customers (e.g., wholesale, Enterprise) and peering partners, to provide such information.  Commercial terms and conditions, that sort of thing.

Tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 1:18 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Dwight, Timothy M (Tim); [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 15:52:41 -0400

I'm not sure if you're serious, but calls "from" an 800 number aren't necessarily invalid.  Call center phones may be set up that way, for example, because they don't want their agents taking incoming calls directly.  Messes up their call distribution algorithms :-).

If you get a harassing call from such a number, call your carrier.  They can track down who owns the 800 number.  If it's spoofed, of course, you'll get the same [lack of] satisfaction you get when you complain about any call from a spoofed number.

Toll free numbers do present us with an interesting tangent in the certificate chain though... particularly since their 'ownership' can be split across multiple entities and change quite rapidly.  For example if I'm Joe's Fish Market I may get an 800 number 1-800-eat-fish and have it set up so that AT&T handles half the calls and Verizon handles the other half.  I can split the calls by day of week, time of day, or even every-other-call.  I wonder if this challenges any assumptions people are making, e.g., about the length of time that a certificate would be valid.  If Verizon only has the right to assert that number when it's Verizon's "turn", does that mean that the certificate ceases to be valid the next time anybody calls that 800 number?  If so the cert may not be valid by the time the verifier wants to use it...

Tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 1:20 PM
To: [email-masked]; Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 20:21:05 +0000

I only use mobile phone, so not sure I can extrapolate my personal
experience.

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 2:33 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

I don't think anybody has complete statistical data, but from what I can
tell, for almost all domestic calls, callerID tends to work (whether it's
spoofed or not). Given that a significant fraction of call origination is
now VoIP (in some areas, close to 50%), courtesy of MSOs, there's usually
some SIP in the call path.

Is your experience that a large fraction of your incoming calls have mangled
callerID?

-----Original Message-----

My impression from this thread was that (3) was more often the case, and (1)
was the minority.
And, that there was little incentive thus far to change that.
Thus, absence some "encouragement" from regulators, call completion is not
impeded, since $$ come from call completion, not from valid caller ID.

Mike

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:07 PM
To: Henning Schulzrinne; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:25 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Henning,

Mike

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 3 Jul 2013 20:25:14 +0000

I was half-joking.  But, most of my annoying calls are from such numbers.
But, at same time when United or Amtrak tells me something is up with my
travel plans, it is 800 as well.

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 3:53 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

I'm not sure if you're serious, but calls "from" an 800 number aren't
necessarily invalid.  Call center phones may be set up that way, for
example, because they don't want their agents taking incoming calls
directly.  Messes up their call distribution algorithms :-).

If you get a harassing call from such a number, call your carrier.  They can
track down who owns the 800 number.  If it's spoofed, of course, you'll get
the same [lack of] satisfaction you get when you complain about any call
from a spoofed number.

Toll free numbers do present us with an interesting tangent in the
certificate chain though... particularly since their 'ownership' can be
split across multiple entities and change quite rapidly.  For example if I'm
Joe's Fish Market I may get an 800 number 1-800-eat-fish and have it set up
so that AT&T handles half the calls and Verizon handles the other half.  I
can split the calls by day of week, time of day, or even every-other-call.
I wonder if this challenges any assumptions people are making, e.g., about
the length of time that a certificate would be valid.  If Verizon only has
the right to assert that number when it's Verizon's "turn", does that mean
that the certificate ceases to be valid the next time anybody calls that 800
number?  If so the cert may not be valid by the time the verifier wants to
use it...

Tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:20 PM
To: [email-masked]; Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 20:28:14 +0000

My understanding is that 800 numbers are assigned by SMS/800 via RespOrgs. They might handle the certificates. (Each 800# is, as far as I know, only at one RespOrg at a time.) This would only apply to outbound calls that show that 800 number, which probably doesn't include Joe's Fish Market. If United Airlines uses multiple outbound call centers, they can use the same RespOrg-issued certificate to sign their outbound calls. (We can discuss various delegation mechanisms, with SMS/800 as the root, but that's getting into irrelevant operational details.)

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 3:53 PM
To: Michael Hammer; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:20 PM
To: [email-masked]; Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jul 2013 20:42:38 +0000

Lets have the side that would know how to fix the number either fix it or reject it until  so it can be globally understandable by the algorithm Henning proposed below. Clearly systems are willing to make the SIP request URI globally routable, I think they need to make the From be sort of globally understandable  too. From the stats I can see, most calls already do have reasonable formatted caller id (ignoring the issue of it it is spoofed or not). If someone sets their PSTN phone number in caller ID to "quack like a duck" there is nothing we can do to help that regardless of if it is a From header or some other place.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 16:45:15 -0400

Yes, toll free numbers 'belong to' responsible organizations (RespOrg's).  It is the routing of the calls that can be allocated across multiple carriers, not the ownership of the number.  My mistake.  I agree also that in this case the carrier(s) would not be in the certificate chain.

tim

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 3:53 PM
To: Michael Hammer; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 1:20 PM
To: [email-masked]; Dwight, Timothy M (Tim)
Cc: [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 12:53 PM
To: Henning Schulzrinne; 'Michael Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

tim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Wednesday, July 03, 2013 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Mike

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 11:19 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Replacing rfc4474 (was: Revised charter text for STIR)

Brian

SN.
seems to me to be silly.
the same way.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 3 Jul 2013 17:04:05 -0400

I don't know if that is more likely to be able to be deployed any time soon than any other solution, but I agree it's the most desirable.

I've seen a lot of U.S. numbers in From that did not have a country code.  Less common elsewhere I believe.

Brian

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jul 2013 22:03:54 +0000

> I've seen a lot of U.S. numbers in From that did not have a country code.  Less common elsewhere I believe.

yah, I agree - as sad as this is to say, the pragmatic thing to do is, if it 10 digit number with no country code and does not start in 0, assume it is +1 country code. I realize there are cases this fails but it works often enough there are people doing it.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jul 2013 13:40:49 -0400

> I don't see a problem with any of those, assuming the phone-context URI parameter is properly used.  Of course if it's not, and you don't otherwise know where the call came from (e.g., by a trunk g…

Does anybody actually use phone-context?
How many implementations will do anything reasonable if they see it?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Jul 2013 14:07:44 -0400

>> the verifier would understand the handling of the case where it is

Won't the presence of a phone-number-based signature serve as an
differentiator that From is intended, by the signer, to be interpreted
as a phone number?

	Thanks,
	Paul

---

From: Dave Crocker <[email-masked]>
Date: Mon, 08 Jul 2013 10:03:39 -0700

> differentiator that From is intended, by the signer, to be interpreted

 From an information theoretic standpoint, I suppose you might be right.

However in terms of protocol simplicity and clarity, having to go 
outside a field, to understand what is meant inside it, is fragile at 
best and likely problematic.

d/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jul 2013 18:03:07 -0400

> best and likely problematic.

ISTM there are several distinct, though closely related, issues here:

1) Does From contain a phone number that the sender of the request is 
entitled to assert?

2) What should be displayed as callerid?

3) What should the receiver of a request with a particular From value 
save and use in the future for initiating requests to the caller?

ISTM that the presence of a phone-number-based signature should be 
sufficient for an authenticator to attempt to authenticate in order to 
answer (1). And I think that is mostly what STIR is about.

Dealing with (2) and (3) is tricky, and not something that has been 
standardized to date. The answer to (1) is one data point for answering 
(2) and (3), but IMO it is far from sufficient.

*If* the decision is to take the "phone number" from From and display it 
as the callerid, then there are a lot of cases where that is what will 
be captured and used for making callbacks. (E.g., I copy the number off 
the phone and manually enter it into an address book.)

If that is done, then when the phone number is used to initiate a new 
call, then the URI from From is likely to *not* be replicated. Instead, 
some arbitrary routing though telephony infrastructure may be used to 
get to that number. In many cases that will be "good enough", but not in 
all cases.

The rules for sip routing say that a request addressed to a sip URI is 
to be routed solely based on the domain name until it reaches a server 
responsible for that domain. *Then* it may be translated/routed based on 
the user part. So the sender of a sip request with a SIP URI containing 
a phone number *should* be able to count on callbacks coming to its 
domain, via SIP.

IMO the *right* answer (that nobody likes) is that if you want to have 
your phone number displayed as callerid, then you should put a TEL URI 
in From. If the From URI contains a sip URI, then that URI should be 
captured for use in callbacks. And probably the URI should be displaed 
as the callerid. It *might* be acceptable for some devices to capture 
the full URI but *display* the phone number.

Unfortunately, that answer seems to be universally unpopular. If the 
intent is that (3) and (3) should be just the phone number, then we have 
broken the existing sip routing rules. If we want to do that, then we 
are carving out a reserved portion of the address space of the user-part 
of sip URIs in *every* domain, whether they want that or not.

A middle ground is to use the ';user=phone' paramter to make the 
decision. (So that sip:number@domain;user=phone is officially equivalent 
to tel:number.) But that won't be enough for many/most people, and it 
won't work for non-e.164 number strings.

I guess a way to sidestep this is to say that if you can authenticate as 
a phone number then you MAY display the number as a trusted callerid, 
but you aren't required to do so. And then leave the rest to 
implementations.

	Thanks,
	Paul