[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enum] Re: [Geopriv] Re: [Simple] tel URIs in common policy
I fully agree that there seems to be an issue here,
because the problem is currently discussed at voipeer
also.The format sip:+1-232-555-1234 at foo.com;user=phone
gets very important especially for Carrier ENUM indicating
the destination providers (see below)
It also concerns the CLI and CLIR aspect not yet fully discussed
in voipeer. This is one issue definitely in scope of voipeer.
comments inline
Jonathan wrote:
>I'll reply to some of the technical comments inline, but I want to step
>back a second here.
>All of this discussion is making it clear that there is a MUCH bigger
>mess here that needs attention, around phone number usage,
>interpretation and equivalence across tel and SIP URI. This is a common
>source of interop problems in the wild and it makes sense to address it.
I fully agree. At voipeer the question is raised what format to use
if E.164 or phone numbers in general are to be transmitted between peers.
also in the to: field
>However, the problem at hand is to complete the common policy document,
>and it seems to me a mistake to hold up common policy until that mess is
>sorted out. Furthermore, I would argue that the common policy spec is
>not the place where that mess should be sorted out.
Could this be done in voipeer ? Or at least partially
The problem is that only a special aspect of the semantic
of the usage of these URIs is under discussion;
namely the usage for signalling
>My suggestion therefore is to keep the "id" attribute as an NAI form,
>and make sure common policy is extensible to allow other ways of
>representing identities in the future. We then declare phone numbers out
>of scope for this version of common policy, finish that spec, sort out
>the tel/sip uri mess, and when thats done, we can issue an extension to
>common policy that adds phone number support.
>more inline.
>Paul Kyzivat wrote:
>>
>> Aki Niemi wrote:
>>
>>> Hi Paul,
>>
>>> ext Paul Kyzivat wrote:
>>>
>>>> Then what do you do with sip:+1-232-555-1234 at foo.com;user=phone ?
>>>>
>>>> I don't think you can convert it to:
>>>>
>>>> 4.3.2.1.5.5.5.2.3.2.1.foo.com
>>>>
>>>> and if you could then it it wouldn't match the e164.arpa form.
>>>
>>>
No you can't
>>>
>>> Well, 'sip:+1-232-555-1234 at foo.com;user=phone' is indeed a tricky
>>> identity to put into a From header in the first place. I'm not sure it
>>> is a telephone number at all. Why wouldn't the From include a tel URL?
This is an interesting point I have not considered yet. Thinking
about it, I would prefer a tel URI in this case. This is IMHO an
issue where voipeer could make a BCP.
>>
>>
>> Personally, I generally think it should. However I have run into many
>> people who don't seem to believe in tel URIs, and always use the sip
>> form. I would like to convince them of the error in their ways, but no
>> luck so far.
If one uses the sip URI, it has to be defined what the foo.bar is:
Is it the domain of the originating service provider or the domain of
the provious hop, being modified each time?
>I think the problem is that we've not made it clear what the semantic
>differences really are.
>>
>> The other case is when I really, definitely, only want to be contacted
>> via SIP.
In this case you should use a SIP alias and not a phone number,
because sip:+1-232-555-1234 at foo.com;user=phone is the equivalent
to a phone number
>>
>>> I suppose that matching a SIP URI converted from a tel URL will be a
>>> problem regardless of the way in which we choose to represent them in
>>> common policy.
I do not think so. Especially if you use global numbers (E.164 numbers)
only you can map back and forth as much as you like, done properly, it
should always be the same number.
>>
>
>> I am relaxing my theoretical objections in favor of pragmatism, and
>> suggesting that for purposes of determining what authorization policy to
>> apply it will be ok to treat this as a phone number.
>Stepping back for a sec, I think there are real differences between the
>tel URI and the sip version. The way to think about it is that the tel
>URI is a NAME, and you need to think of it as if it were a URN. A SIP
>URI is an address. Procedures like enum allow the resolution of a name
>to an address.
Hmm. We should not go down this path ;-? This is not so simple:
This is also a terminology problem between differnent standard bodies
A phone number could also be a name and an address, In ITU and
ETSI terms a sip AoR or email address is also a name. Only an IP-address
is an address.
Also with SIP URIs you may have:
A. A SIP AoR, which is a name
B. A SIP Contact Address, which is either a name or an (IP) address
C: A SIP URI with parm user=phone, which is a phone number (a name?)
D. A GRUU, which is ?
>As such, it really makes no sense to compare a name and an address. Just
>because I work at 600 Lanidex Plaza in Parsippany, does that make
>"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza,
>Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel
>URI and SIP URL are NEVER equivalent; you need to convert the name to an
>address for comparison.
I cannot fully follow this argument:
Lets try it in another way. There is other usages for URIs
A. You put it on a webpage to be clicked on:
In this case you would either use a plain tel URI to indicate a phone number
or a sip URI in the format sip:userID at foo.bar to indicate rachability via sip
In the first case the client linked to the tel URI may even chose to use a dialler
in the second case it wold indicate to use a sip-client. If you use
sip:+1-232-555-1234 at foo.com;user=phone , this would indicate also to use
the sip client?
B: in ENUM. (now we are finallyat the point ;-)
If one queries ENUM for the phone number +1-232-555-1234
it would be completely useless to get back the same
number in tel:+1-232-555-1234
we need here sip:+1-232-555-1234 at foo.com;user=phone with
the same number to indicate the foo.com domain of the carrier
This is basically the essential information
Of course one could also put in sip:userID at foo.com, but only
in User ENUM, in Carrier ENUM this will not be possible for privacy reasons.
C: the nect, yet undicided question is what you use in case B within signalling
now in the to field: the tel URI or the sip URI returned by ENUM.
Current practice here is to use the SIP URI.
>Givne this, the meaning of sip:<phone-number>@domain;user=phone means
>that the domain is asserting ownership of the identity in the user part,
>in this case a global phone number. As such, its appropriate to use this
>form only when it is authoritatively known that the domain in question
>"owns" that phone number.
This is a very interesting aspect, leading to the CLI and CLIR problem
not yet discussed fully in voipeer.
The CLI problem is IMHO definitely in scope of voipeer. CLI is required
for call-back (especially if gatewaying to the PSTN), for MCI to emergency services
and also requires CLIR support for anonymous calls.
>-Jonathan R.
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum