Dean Willis wrote:
>
> On Apr 14, 2008, at 6:24 PM, Hadriel Kaplan wrote:
>>
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>>> Dean
>>> Willis
>>>
>>> The problem is we're talking about TWO service providers, and reaching
>>> the wrong one's gateway.
>>
>> I'm not sure I understand the problem. Service providers decide
>> whether they want to send a call to the PSTN or not for another
>> domain, and that decision is based on their peering relationship and
>> regulatory restrictions. If the peering relationship is such that
>> b.com will try the PSTN (e.g., because a.com pays b.com to be its
>> provider), then it will, else not. So it's not reaching the wrong
>> one's gateway. A.com calls b.com, b.com can forward the call to the
>> pstn if it has that type of relationship with a.com, else it sends the
>> 302 redirect back upstream. What's the "wrong one's" gateway?
>>
>>
>>>> I guess you are worried about [EMAIL PROTECTED] phoning [EMAIL PROTECTED]
>>>> and b.com
>>>> doesn't have
>>>> a gateway but wants to forward to PSTN (and wants the originating to
>>>> fork
>>>> the bill). So it sends tel URI instead. Sure, but again, I doubt it
>>>> will
>>>> work very well.
>>>
>>> It has the potential to work well, whereas what we have now doesn't.
>>
>> Well, it seems to be working. There's plenty of bilateral peering
>> already happening, and the 302's seem to work across the providers.
>> It's just that the contact URI in them is not what I would call the
>> "right" one, but it's working.
>
> I really can't see how; I can't make it work with my providers
>
> Let's revisit the problem again:
>
> Alice is a customer of provider A. Bob is a customer of provider B.
>
> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone
> number, +445558675309.
>
> At this point, Bob and provider B don't know what gateway Alice might
> use to reach the PSTN, They also don't know whether reaching Jenny's
> phone number even requires Alice to use a gateway.
>
> 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
>
>
> 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.
As another alternative, Hadriel has mentioned b.com returning a 302 when
it gets the request with the phone number and its domain in the R-URI.
But I don't know what uri it will put in the 302.
> 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.
It won't prevent calling the user with the name that looks like a
number, at least not if a.com uses a location service. That is because
the basic 3261 rules say to ignore the uri params when looking up in the
location service.
That's all the comments I have for now.
Paul
> 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
