Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T

From: "Yu, James" <[email-masked]>
Date: Thu, 22 Mar 2001 14:08:27 -0600

If a redirect/proxy server invokes the ENUM process and retrieves the URLs
in the NAPTR RRs associated with a telephone number (assume the telephone
number is in the user part of the sip URL or in the tel URL in the INVITE
received by the server).  There is a need to return the list of URLs in the
Contact header of the 3xx response from the redirect server to the proxy/UAC
or from the proxy server to the UAC (reason is explained later).  If the
rule is that only sip URL can be returned in the Contact header, it may be
fine with the tel URLs that can be converted to the sip URLs; however, other
URLs (e.g., mail to) cannot be returned.  If we use an extreme case where
the ENUM end user only wants to be reached by e-mail (may be for a
particular time period), there would be only the mailto URL(s) in the
retrieved NAPTR RR(s).  It won't be possible to return the mailto URL(s) to
the UAC so that it can cancel the sip INVITE request, indicate the called
end user's preference of using the e-mail and ask the calling end user
whether to abort or to invoke the e-mail application.

So from the service point of view, it seems that we should allow non-sip
URLs in the Contact header of the 3xx response.  When a proxy receives a 3xx
response that contains URLs or retrieves the URLs through the ENUM or other
process that it does not know how to route further (e.g., no sip or tel
URL), it should relay the 3xx response back to the UAC so that proper action
may be taken there.  We'll need to define how a proxy handles the mixed URL
cases.  For example, the list of URLs returned may contain sip URLs, tel
URLs and other URLs with a preference specified for each URL.  What if there
are non-sip routable URLs that have higher preference values than the sip
routable URLs?  Should the proxy try to use the sip routable URLs to route
first or need to enforce the preference rules (e.g., return the 3xx back to
the UAC in the example). 

James
> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Thursday, March 22, 2001 12:15 PM
> To: 'Yu, James'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T
> 
> 
> This is an interesting question. Since Contact:
> effectively forms part of a Route: list. Since
> it was decided that only sip: URIs are allowed
> in a Record-Route:, do we use the same logic for
> Contact:? I don't believe so. The rule of thumb
> would seem to be that you should only use non-sip
> URLs in Contact: in REGISTER requests and 3xx 
> responses.
> 
> /sean
> 
> >-----Original Message-----
> >Jon brought up a good point.  Is there a reason why tel URL is 
> >not allowed
> >in the Contact header?  The tel URL can be converted to a sip 
> >URL if sip URL
> >is the only allowed URL.  But the question is why the tel URL 
> >is not allowed
> >in the Contact header?
> >
> >If the Request-URI allows many types of URLs, it seems 
> logical that the
> >Contact header should allow those URLs.
> >
> >James
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >> Sent: Wednesday, March 21, 2001 9:21 PM
> >> To: [email-masked]; [email-masked]
> >> Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T
> >> 
> >> 
> >> RFC2543bis (section 2.2) lists some headers (notably 
> >> Contacts) in which only
> >> the SIP URI can be used. The protocol permits other schemes 
> >> (like the tel
> >> URL) to be used elsewhere. So presumably it is legal for a UA 
> >> to use schemes
> >> in the URIs within responses other than those schemes 
> which have been
> >> received in a request (with the Contact caveat, etc). I 
> >> cannot speak to the
> >> existence of UAs which do not 'support' the tel URL (frankly, 
> >> I'm not sure
> >> what failures a UA might experience as a result of receiving 
> >> an unfamiliar
> >> URI scheme), but I think generally you can assume that the 
> >> sorts of entities
> >> to which you would be likely to send a tel URL in a SIP 
> >> message probably
> >> support the tel scheme. Also note that it is unlikely that 
> >> any entity that
> >> understands SIP URIs will have substantial trouble parsing tel URLs
> >> considering that (to plagarize a recent mail on this subject)
> >> 
> >> "... the user portion of a sip URI can be a
> >> telephone-subscriber. The BNF for telephone-subscriber is 
> >> defined by the tel
> >> URL, and is anything that can be after the tel: in the tel URL."
> >> 
> >> And yes, the ';user=phone' for the tel URL example in the 
> >> "Mapping" draft is
> >> a typo. That was meant to be a SIP URI example in which the 
> >> presence of the
> >> 'user=phone' would differentiate the user portion of the URI from a
> >> non-telephony username (like old Compuserve email addresses 
> >> or something).
> >> 
> >> Jon Peterson
> >> Level(3) Communications
> >> 
> >> -----Original Message-----
> >> From: Doug Hurtig [mailto:[email-masked]]
> >> Sent: Wednesday, March 21, 2001 6:15 PM
> >> To: [email-masked]
> >> Subject: [SIP] Using sip or tel scheme in URIs with SIP-T
> >> 
> >> 
> >> Hi,
> >> 
> >>  The  "SIP  Call Flows Examples" document uses the "sip" 
> >> scheme for URIs.
> >>   The "Mapping of ISUP Parameters to SIP headers in SIP-T" draft
> >>   shows that either the sip or tel scheme is valid.
> >> 
> >>   This is no problem to handling on the incoming side. 
> >> However, can I assume
> >> that
> >>    if I send either tel or sip in the URI that the 
> receiving end will
> >> understand
> >> this?
> >> 
> >>   What if  I receive a message which uses one scheme to 
> >> identify the URI, is
> >> it
> >> allowed
> >>    that my response contain URIs with the other scheme?
> >> 
> >>    It seems that if the "tel" scheme is used it is implied 
> >> that the value is
> >>    a telephone number and there is no need to ever include 
> >> the "user=phone"
> >> parameter.  Have
> >>    I missed something here?
> >> 
> >> --
> >> Regards,
> >> Doug Hurtig
> >> 
> >> Tekelec
> >> 2425 N. Central Expressway
> >> Richardson, Texas 75080
> >> 
> >> [email-masked]
> >> 972.301.1203
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> This list is for continuing development of the SIP protocol.
> >> The sip-implementor's list is the place to discuss implementation,
> >> and to receive advice on understanding existing sip.
> >> To subscribe to it, send mail to 
> >> [email-masked] with "subscribe" in 
> >the body.
> >> 
> >> _______________________________________________
> >> This list is for continuing development of the SIP protocol.
> >> The sip-implementor's list is the place to discuss implementation,
> >> and to receive advice on understanding existing sip.
> >> To subscribe to it, send mail to 
> >> [email-masked] with "subscribe" in 
> >the body.
> >> 
> >
> >_______________________________________________
> >This list is for continuing development of the SIP protocol.
> >The sip-implementor's list is the place to discuss implementation,
> >and to receive advice on understanding existing sip.
> >To subscribe to it, send mail to 
> >[email-masked] with "subscribe" in 
> the body.
> >
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 22 Mar 2001 15:48:35 -0500

According to the bis draft (sec 6.15), a Contact header may contain a SIP
URL or a URI (which would include tel or mailto). These seem appropriate in
REGISTER and redirect responses and the like. But for things like INVITE or
a 200 response to an INVITE, where it means "send subsequent
responses/requests to this", I think it needs to be a SIP URL.

Bob
d:-)

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2001 23:14:05 +0200

Hi,

Wouldn't it be possible to indicate which URIs are supported by the UAC
by using the Accept-Contact (or a new header, Accept-URI, or
something...) in the "SIP Caller Preferences and Callee Capabilities"
draft? Then, a UAC can indicate what kind of URIs it can handle, and the
redirect server would only include such URIs in the 3xx response. This
way, any kind of URI could be allowed in the Contact header - at least
if the Accept-Contact/URI/whatever header is present in the INVITE.

And, if a proxy does not want to forward the 3xx back to the UAC
(instead it will send the new INVITE itself when the 3xx is received),
but it does not support all URIs that the UAC does, it may remove the
URIs it doesn't support from the Accept-URI (I will use that name until
we know if Accept-Contact can be used or not) header before forwarding
the initial INVITE. However, let's take the easy case first :)

Comments?

Christer Holmberg
Ericsson Finland

---

From: "Sean Olson" <[email-masked]>
Date: Thu, 22 Mar 2001 14:35:54 -0600

>received by the server).

I assume that an ENUM query would be unnecessary for a sip:
URL, even if the user portion contained a telephone number.
But this should probably be handled in a separate thread.

>There is a need to return the list 
>of URLs in the
>or from the proxy server to the UAC (reason is explained 
>later).  

This is fine by me. I think a 3xx response should be able
to carry any URL scheme in the Contact: header for the very
reason that the Contact: header in a 3xx response has 
slightly different usage than in say a INVITE request.

For the record, I am also happy to carry a non-SIP URL in
the Contact: header of an INVITE request, but I understand
why that bothers most people so I am happy to disallow it
as well.

>cases.  

This is one possible behaviour (and a sensible one), but 
I would be hesitant to add any verbage to the SIP spec
stating this. I think this is very service specific and
you may very well have some intelligent proxies that are
able to "do the right thing" with non-sip URLs. I think
the same comment applies to a list of Contact:s of 
varying priority with a non-SIP URL possibly having
higher precedence than a SIP URL.

/sean