Chaney, Charles (NSN - US/Boca Raton) wrote:
> Hi Paul,
>
> Sorry to resurrect this old email chain but I thought it would be
> pertinent to my statements/assumptions.
>
> My interpretation of RFC3261 section 10.2 implies that the To: header
> field as a SIP/SIPS URI (userinfo) may be in the form of a
> telephone-subscriber.
Since that is a valid sip URI it certainly may be used.
> This would allow the SIP UA support the user=phone
> requirement using a global-number or local-number, essentially the same
> as a tel: URI with the advantage that the domain for the tel: URI is now
> available making it a URL.
Sure. But of course this also depends on the callers knowing the domain
used by this UA to register the number.
> Including a phone-context parameter when in
> the local-number format is possible.
Of course.
> If this is correct, the usage of a local-number (with phone-context) for
> a registration would allow SIP UA's without any global identity
Do you mean without a DID number in the PSTN?
> register within the service domain for the phone-context.
Well, they can register *using* the phone context, if the registrar
allows that. I'm not certain what "service domain for the phone-context"
means.
> Other SIP UAC's having
> knowledge of the SIP UA (domain and phone-context) would be able to make
> calls to them.
Using the sip uri.
> Likewise, SIP proxies having routing knowledge for the
> SIP UA domain and phone-context would be able to route requests to the
> SIP UA.
Given sufficient knowledge.
> This should also allow these SIP UA's that do not have Direct Inward
> Dialing (DID) capability to still be capable of receiving requests from
> outside their service domain through some intermediary server, e.g., a
> SIP PBX or Attendant that is able to process the incoming call and then
> perform a call transfer to REFER the caller to the SIP UA with the
> proper phone-context (Refer-To).
A lot of "if"s, but yes.
> Comments regarding any misinterpretation or concerns are appreciated.
The local number format of the tel uri allows both:
tel:1234;phone-context=+1212555
and tel:1234;phone-context=example.com
And then these both can be transformed into sip URIs.
If you have a sip URI, then you can route based on its domain, and
hopefully get to something that will know what to do with the rest to
get to the phone. That is what you are talking about above.
But what if you only have the tel uri? AFAIK there are no rules for
routing such things. Certainly ENUM doesn't touch them.
But conventions could be established. Certainly it is tempting to
consider transforming
tel:1234;phone-context=example.com
into sip:[EMAIL PROTECTED]
or sip:1234;[EMAIL PROTECTED]
And I can certainly imagine using ENUM with the other form. For
instance, use ENUM on +1212555 and then use the result as a Route header
with the tel uri in the R-URI.
But that is just me imagining. I have heard nobody prpose such.
I see you are Navy. I guess you have phone systems with a lot of private
numbers. Hence the questions?
Thanks,
Paul
> Thanks,
> Charles Chaney
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf
>> Of Paul Kyzivat
>> Sent: Wednesday, June 28, 2006 6:16 PM
>> To: Jolan Evans
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: [Sip-implementors] request uri scheme for
>> REGISTER request
>>
>>
>>
>> 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
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
