Francois Audet wrote:
> That's kind of what I was also saying.
>
> PS: what's the difference between 2 and 4?
I think 4 is a typo and was presumably intended to be
4) sip:+445588675309:a.com;user=phone
It is already the case that a.com may treat 3,4 & 5 alike if it wishes.
And b.com may treate 1,2 & 5 alike if it wishes.
The question is whether a.com may treat 1&2 like 5, or if b.com may
treat 3&4 like 5.
Apparently some are saying that user=phone is license to ignore the
domain. But that just raises the question of why one would insert a
domain along with a parameter that says to ignore it. Makes no sense to me.
Paul
>> -----Original Message-----
>> From: Anders Kristensen [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, April 16, 2008 15:21
>> To: Dean Willis
>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055);
>> Paul Kyzivat; Dan WING
>> Subject: Re: [Sip] E.164 - who owns it
>>
>>
>>
>> Dean Willis wrote:
>>> What does Bob put into the Contact of a 302 he might send to Alice?
>>>
>>> I've heard several alternatives:
>>>
>>> 1) sip:+445588675309:b.com
>>>
>>> 2) sip:+445588675309:b.com; user=phone
>>>
>>> 3) sip:+445588675309:a.com
>>>
>>> 4) sip:+445588675309:b.com;user=phone
>>>
>>> 5) tel:+445588675309
>> The presence of user=phone and a valid E.164 number in the
>> user part seems like a pretty strong hint so I wonder if the
>> following might work as a pragmatic, if not exactly elegant,
>> way forward: allow proxies and the UAC to treat cases 2 and 4
>> as if the URI is equivalent to 5 in the sense that they can
>> do ENUM query on the E.164 number and they can even rewrite
>> the domain part and expect the URI to identify the same entity.
>>
>> This doesn't prevent a.com from recursing when really Alice's
>> UA would have liked to use another provider for gateway
>> services but then neither does using a tel: URI.
>>
>> We'd also want to start pushing support for tel:, of course.
>>
>> Thanks,
>> Anders
>>
>>>
>>> So let's step through what these mean and why they each might not
>>> work. Keep in mind also that there's a very real possibility that
>>> Alice might nod NEED a gateway to reach Jenny; it's possible that
>>> Jenny's phone number is already in ENUM and is directly
>> reachable via
>>> SIP. But this only works if Alice knows to look it up that way.
>>>
>>> 1) causes Alice to make a call to a user ID in the domain
>> of b.com.
>>> Assuming that b figures out that this means a telephone
>> destination,
>>> Alice probably doesn't have an account at b.com to use for
>> placing the
>>> call. So unless B provides free SIP-to-PSTN calling, or at least
>>> provides free translation service to ENUM, she's out of luck.
>>>
>>> Of course, maybe a.com knows that when it gets a 302 back with a
>>> contact that looks like it might be a phone number, it
>> should discard
>>> the host part and do phone number routing on the user part.
>> That works
>>> until a.com also has user IDs that look like phone numbers.
>> Of course,
>>> this is a direct violation of RFC 3261, which bans a.com from
>>> retargeting a request with a b.com host part.
>>>
>>> 2) is much the same as 1, except that "user=phone" provides another
>>> hint. B is no more likely to provide gateway services, but at least
>>> least if A is going to do an illegal foreign retargeting, it has a
>>> broader hint that phone number routing instead of user routing is
>>> required.
>>>
>>> 3) instructs alice to make a call in the domain of a.com.
>> That's fine
>>> as long as sip:+445588675309:a.com routes to Jenny. Does
>> it? It might
>>> route to somebody with user ID +445588675309, which is a perfectly
>>> valid user ID.
>>>
>>> It might also be true that Alice doesn't use a.com for her
>> PSTN calls.
>>> Perhaps instead, she uses c.com. So to use c.com services, or do an
>>> enum lookup, she has to do an illegal retargeting.
>>>
>>> 4) is much like 3, with the added hint that a telephone-number
>>> destination is indicated. This might eliminate the
>> accidental calling
>>> of user +445588675309, but it does nothing to resolve the
>> question of
>>> Alice not using a.com services for PSTN gateways. There's
>> also an open
>>> issue as to whether PSTN routing (such as an ENUM lookup) can be
>>> applied, vs requiring the call to traverse a gateway.
>>>
>>> At the very best, a.com (or Alice's UA) knows to discard
>> the host part
>>> and do telephone routing on the user part. If Alice's UA does this,
>>> it's probably a violation of RFC 3261, as the UA itself is not
>>> responsible for the host-part of the contact. A proxy in
>> a.com could
>>> do this translation. But what happens if Alice doesn't use
>> a.com for
>>> routing PSTN calls? For example, I might place SIP calls using
>>> "softarmor.com", but I make my PSTN calls using "sipphone.com", so a
>>> 302 sent to me for "sip:
>> [EMAIL PROTECTED];user=phone" will
>>> most assuredly fail. Now, if the a.com proxy knew to translate the
>>> call, that would be OK, but depending on the relationship between
>>> Alice and a.com, it might not.
>>>
>>> 5) doesn't work at all, because Alice's phone doesn't
>> understand tel:
>>> URLs, since understanding of such was listed as a MAY in
>> RFC 3261. But
>>> it's the only suggestion from the set that doesn't require
>> violating a
>>> bunch of existing protocol rules.
>>>
>>>
>>>
>>>
>>>> Really, in the long list of interop issues, this one's
>> pretty low on
>>>> the totem pole, imho. People are having trouble getting
>> basic calls
>>>> to work without the aid of a middle-box. That's a bit
>> higher on the
>>>> list to me. :)
>>> This is a very basic interdomain calling scenario. I'm
>> really hoping
>>> we get more and more interdomain calls.
>>>
>>>
>>>>
>>>>>> Again, don't shoot the messenger: it makes sense to me
>> to use Tel
>>>>>> URI for this. I am just saying it may cause interop
>> problems. Maybe
>>>>>> that's ok, and maybe implementations will start implementing tel
>>>>>> URI.
>>>>> I've no doubt that there will be interop problems. That's what
>>>>> happens when you specify something that has previously been
>>>>> unspecified and left to whim or caprice.
>>>> OK, but failing calls will not give it a high chance of being
>>>> adopted. Maybe we can figure out how to get a sip: uri to work as
>>>> well - there's more than one way to skin a cat, even with a potato
>>>> peeler. ;)
>>> Failing calls that don't work now isn't much of a handicap.
>> Changing
>>> the rules of RFC 3261 to make case 3 or 4 generally valid
>> might also
>>> work.
>>>
>>> Fundamentally, we need a documented solution that works in
>> the general
>>> case and doesn't conflict with MUST level rules of other
>> RFCs we cite,
>>> unless it supercedes those RFCs.
>>>
>>>
>>> --
>>> Dean
>>> _______________________________________________
>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use
>>> [EMAIL PROTECTED] for questions on current sip Use
>>> [EMAIL PROTECTED] for new developments on the application of sip
>>>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
