Francois,
I agree much of what I wrote below does sound like a candidate for a
BCP. But I think it is still a bit premature to write one. At the moment
I think it is just use cases we are playing with to explore the solution
space.
Paul
Francois Audet wrote:
> This is starting to smell like BCP material actually.
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, April 16, 2008 16:04
>> To: Audet, Francois (SC100:3055)
>> Cc: SIP IETF; Dan WING; Dean Willis
>> Subject: Re: [Sip] E.164 - who owns it
>>
>> replying to myself - another thought:
>>
>> Paul Kyzivat wrote:
>>> 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.
>>
>> This would make *some* sense to me if the semantics were:
>>
>> 1) you MAY route to this domain following 3263 procedures
>> with expectation that it will work.
>>
>> 2) if you are unable to do that (say because you don't have a
>> sip path at all, or don't have a path to the domain in the
>> URI) then you may treat it as a tel URI and route it any way
>> that works for you.
>>
>> But it seems that in many of the use cases that have been
>> presented in this thread it is actually the case that if the
>> recipient routes to the domain in the URI the request *won't*
>> work. That makes absolutely no sense to me. In that case TEL
>> seems clearly the right way.
>>
>> Now Hadriel has made a case that it is the SBC's job to fix
>> this up. So when the URL exits the domain in which it will
>> work, then the SBC should fix it up with the domain it is
>> going into. I guess that could make sense if that SBC was
>> acting as an agent of *both* domains. But typically it is
>> only acting as an agent of one domain. An SBC acting for
>> b.com has no business changing the domain of the URL to
>> a.com, since doing so is (or isn't) a policy of a.com.
>>
>> A way around that is to say that if the URI contains b.com,
>> then an SBC acting for b.com, when it knows it won't honor
>> that, can change it to a TEL URI when it exits the domain. It
>> then may well go through another SBC acting for a.com as it
>> enters the a.com domain. That SBC could change the TEL URI to
>> an a.com URI if that will be handled correctly within the
>> a.com domain.
>>
>> Paul
>>
>>> 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
>>>
>
_______________________________________________
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
