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

From: [email-masked]
Date: Thu, 22 Mar 2001 13:57:41 -0700

My original mail on this subject was intended to refer only to UA call
set-up behavior (the subject that kicked off this thread); bis 2.2
explicitly forbids non-SIP URIs in the Contact headers of INVITE, OPTIONS,
BYE, and 2xx messages, -not- 3xx messages nor REGISTER. Sorry for my lapse
of precision; didn't mean to start a panic here.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 1:49 PM
To: Yu, James; [email-masked]
Subject: Re: [SIP] Using sip or tel scheme in URIs with SIP-T

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]

----- Original Message -----
From: "Yu, James" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 22, 2001 3:08 PM
Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T

> 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.
>

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Thu, 22 Mar 2001 23:43:52 +0200

Hi Jon,

First a comment on the thread in general. 

It's true that a tel-url can be mapped into a sip-url, but do we really
solve a problem by allowing only sip-url and tel-url in the Contact
header? Sure, this would solve the problem when we talk about telephone
numbers, but isn't the whole idea of what we are doing to finally go
"beyond" that? 

>of precision; didn't mean to start a panic here.

I think the proposal I wrote in my other mail (by specifying the
supported URI in an Accept-XXX header) would solve also this. In my
initial INVITE I add a Contact with ANY URI, and if the receiver doesn't
support it he will send some 4xx response, and a header indicating which
URIs he supports. An idea could be to even allow multiple Contacts, all
with different URIs, in the INVITE, and the UAS can choose the one he
wants and/or supports...

Regards,

Christer Holmberg
Ericsson Finland