Jolan Evans wrote:
> Paul & Dale:
>
> While section 5.2 of RFC 3261 says that the To URI must contain a SIP or
> SIPS URI, RFC 3261 was published before the newer tel URI RFC 3966
> (which obsoletes RFC 2806 which is referred to by RFC 3261).
>
> In section 9 of the newer RFC 3966 (titled "Use ot 'tel' URIs with SIP
> (Informative)") it says that:
> "SIP can use the 'tel' URI anywhere a URI is allowed, for example as
> a Request-URI, along with 'sip' and 'sips' URIs."
>
> While this section of RFC 3966 is only informative it does bring into
> doubt whether the Request-URI and To URI in a REGISTER request can only
> contain sip or sips URI as Paul stated below.
>
> Personally, I think that this informative remark is not meant to apply
> to REGISTER requests but this section certainly does not make this
> clear.
The subject of how to deal with TEL URIs in sip is complicated already,
and allowing it in the register makes it moreso. Its a can of worms we
could do without right now.
> Whether the To and Request URIs in a REGISTER request can contain a tel
> URI brings into question the purpose of the tel URI. A colleague of mine
> would like that a single tel URI:
>
> 1. is an AOR URI to which locations can be registered using
> REGISTER request. The domain of the location service for the
> Request URI presumably comes from the tel URI's domain
> phone-context, which must be present, and hence the tel URI must
> be a local number.
Using the phone-context that way is a real stretch. I'm not aware of
anything that suggests you should do that, though it is tempting. (But
it isn't a good strategy when the phone-context is "+1".)
Note that 3966 says the phone-context is not to be used to construct an
E.164 number from the local number. (This is in relation to numeric
phone-contexts. So you can't transform tel:5551212;phone-context=+1212
into tel:+12125551212.) I don't recall what it says about phone contexts
in FQDN format, but IMO the intent in both cases is that this provides
*context* for understanding the meaning of the local part, but provides
no mechanism for routing to it. (The TEL URI is not a URL.)
In principle you could establish a convention for using the phone
context as a domain for routing requests, but you would have to also
come up with a way for deciding which domains in a phone-context it it
applied to. For instance, tel:34;phone-context=fqdn might be resolved
via an ENUM query to 4.3.fqdn.e164.arpa. But there is currently no such
convention defined.
> 2. is an AOR URI to which other SIP UAs can send INVITE's. This
> assumes that the tel URI has a domain phone-context as well so
> that the UA can route the tel URI to the AOR's location service.
Same as above.
I don't see the attraction of local phone numbers. I think they are just
a necessary evil for phones that don't have E.164 DID numbers.
> 3. contains a telephone number (the telephone-subscriber in RFC
> 3966) so that a PSTN caller can also call the AOR.
This isn't going to work for local numbers.
> This assumes
> that the PSTN number is routed to a PSTN to SIP gateway which is
> configured with the domain of the location service associated
> with the tel URI. However, because the tel URI is a local and
> not a global number, the number does not contain a leading "+".
> This may present a problem for the PSTN caller. However, since
> PSTN callers don't use the tel directly, they could be given the
> same number but with a leading "+".
>
>
> The objective is that a subscriber can have a single identity: a tel URI
> for the SIP domain which contains the same telephone number which is
> their identity in the PSTN telephone network.
In that case it needs to be an E.164 number. And then presumably the
domain is learned via ENUM. This requires there to be a sip-uri as well.
Of course it can just be the user=phone equivalent of the tel, with the
domain included.
> I'm not sure that this is the intent of the tel URI especially given
> that the telephone number must be a local number and not a global one.
> My understanding is it is just a way of representing a telephone number
> so that e.g. a SIP UA can call the number by using an appropriate
> gateway: a SIP to PSTN gateway if the number is global or an
> proxy/gateway identified by the tel URI's phone-context if the number is
> local.
Certainly there is no intent that local numbers be used and not global
ones. But it can be used in a variety of ways. I don't think there is
any intent to restrict the use to gateways. All the work on ENUM is
intended to allow E.164 numbers to be used without ever having to go to
the PSTN.
Paul
> Comments on this which include references to relevant RFCs would be
> appreciated.
>
>
> Jolan
>
> On Mon Nov 28 19:51:19 EST 2005 Paul Kyzivat wrote:
>> I pretty much agree with Dale.
>>
>> It would be good if people would RTFM before posting questions like this
>> one. Section 5.2 of 3261 says:
>>
>> Request-URI: The Request-URI names the domain of the location
>> service for which the registration is meant (for example,
>> "sip:chicago.com"). The "userinfo" and "@" components of the
>> SIP URI MUST NOT be present.
>>
>> To: The To header field contains the address of record whose
>> registration is to be created, queried, or modified. The To
>> header field and the Request-URI field typically differ, as
>> the former contains a user name. This address-of-record MUST
>> be a SIP URI or SIPS URI.
>>
>> This makes it pretty clear that the R-URI and To-URI of register MUST be
>> sip or sips.
>>
>> I do have some sympathy though. I think it *ought* to be ok to use a tel
>> uri in the To: header. Of course that won't by itself be enough to get
>> the domain to assume responsibility for the phone number - that would
>> have to already have been established somehow. But it would provide a
>> way for a UA to say it wants to accept calls to that number that happen
>> to reach the domain.
>>
>> Paul
>>
>> Dale R. Worley wrote:
>>> On Mon, 2005-11-28 at 02:54 -0800, Litty Preeth wrote:
>>>
>>>> Suppose there is a sip soft-phone with a tel URI say "tel:
>>>> +358-555-1234567". If i want to register that phone to a SIP
>>>> registrar handling the domain say "xyz.com" then what would be the
>>>> sheme of the request uri of that REGISTER request - sip or tel ? I
>>>> mean would it be tel:xyz.com or sip:xyz.com
>>>
>>> Maybe I'm not seeing how you want to use SIP, but I think such a request
>>> would be meaningless. A REGISTER is for informing the proxy that
>>> handles a SIP domain, e.g., "sip:... at example.com" that requests for
>>> <sip:foo at example.com>" should be routed to <sip:foo at 10.1.2.3>. A
>>> REGISTER can never provide information about how to handle requests for
>>> a tel: URI.
>>>
>>> Perhaps people have started building registrars/proxies that route tel:
>>> URIs and use REGISTER messages, but that is an extension of RFC 3261
>>> that I've never heard of.
>>>
>>> Dale
>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors at cs.columbia.edu
>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
