Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean
>> Willis
>>
>> RFC 3261 Section 19.1.1 says:
>>
>> The set of valid telephone-subscriber strings is a subset of
>> valid user strings. The user URI parameter exists to
>> distinguish telephone numbers from user names that happen to
>> look like telephone numbers. If the user string contains a
>> telephone number formatted as a telephone-subscriber, the user
>> parameter value "phone" SHOULD be present. Even without this
>> parameter, recipients of SIP and SIPS URIs MAY interpret the
>> pre-@ part as a telephone number if local restrictions on the
>> name space for user name allow it
>
> That last sentence is fascinating. If I read it right, it basically allows
> me to treat a sip URI for my domain without the user=phone as a global E.164,
> if I so wish. (which so happens to be fairly common in my world) Good, I
> feel better now. ;)
If this is news to you, then you guys really lucked out. :-)
>> If we made it mandatory for a PSTN gateway to assert identities using
>> user=phone and documented that Identity headers over an identity with
>> a user=phone parameter do not assert the "user part" of that identity,
>> then I think we'd have a complete solution.
>> Corollary , we need to document that a "phone" UAS that is attached to
>> the Internet does NOT use "user=phone" even if its user ID is a phone
>> number and the ENUM entry for that phone number happens to point at
>> this user ID at this UAS (or supporting domain).
>
> There's a problem with that. There are many "phone" UAS's which are
> ultimately reachable over the PSTN. In fact, I would bet most of them are.
> If the From of a request is used to store in one's address book, for later
> requests, then per Paul's desired behavior that later request could only be
> delivered over sip, or it should fail.
I'm not so rigid as to think gailure is the best option.
I can see the conversion from sip to tel as a heuristic to recover from
failure to reach the destination via the sip URI in normal ways. It
woujld require some thought to decide which particular errors would make
sense to retry in this way.
But I do think one ought to attempt to honor the intent of the provider
of the URI. IMO 3263 is pretty clear about how a sip uri is to be routed.
> One would think if the original request were to be delivered by sip, then a
> request anytime later the other direction could as well. But that's not the
> case. For one, transit peering arrangements are not symmetrical, and it's
> totally possible that calls across providers in one direction go sip the
> whole way, but calls the other direction cross the PSTN or H.323 or whatever.
> For another, many enterprises have "PSTN fallback" abilities, so that if
> their SIP trunks fail for some reason, there is a PRI-type backup.
I'm not getting your point. Return routing will be based on a different
URI provided by the other party. All this discussion applies to that as
well. Whether reverse routing is possible is irrelevant here.
> But this issue is somewhat orthogonal to your proposal. And it's leading me
> to think that we cannot reasonably have a "if sip: then only SIP" behavior
> solely based on scheme, as Paul seems to feel is currently implied (I think).
Yes, I think that is implied. And subject to some possible fallback
behavior I think it is a good thing, as long as we have a uri (tel) that
covers the cases when that isn't the the appropriate.
Paul
_______________________________________________
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
