Subject: I-D Action: SIP Call Flows and Service Examples

From: Alan Johnston <[email-masked]>
Date: Mon, 25 Oct 1999 13:53:33 -0500

Two new Informational Internet-Drafts are available from the on-line
Internet-Drafts directories.  They will be briefly introduced at the 46th IETF
meeting
in Washington, D.C.

        Title           : SIP Telephony Call Flow Examples
        Author(s)       : A. Johnston, S. Donovan, R. Sparks, C. Cunningham,
                          K. Summers
        Filename        : draft-johnston-sip-call-flows-00.txt
        Pages           : 174
        Date            : 21-Oct-99
        
This document gives examples of SIP IP Telephony call flows.
Elements in these call flows include SIP User Agents and Clients, SIP
Proxy and Redirect Servers, and Gateways to the PSTN (Public Switch
Telephone Network).  Scenarios include SIP Registration, SIP to SIP
calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway via
SIP.  Call flow diagrams and message details are shown.  PSTN
telephony protocols are illustrated using SS7 (Signaling System 7),
ISDN (Integrated Services Digital Network) and FGB (Feature Group B)
circuit associated signaling.  PSTN calls are illustrated using
global telephone numbers from the PSTN and from private extensions
served on a PBX (Private Branch Exchange).

A URL for this Internet-Draft without diagrams (future versions will have ASCII
diagrams included) is:
http://www.ietf.org/internet-drafts/draft-johnston-sip-call-flows-00.txt

Acrobat and PostScript versions containing call flow diagrams are
available at:
http://www.greycouncil.com/sip/drafts/draft-johnston-sip-call-flows-00.pdf
http://www.greycouncil.com/sip/drafts/draft-johnston-sip-call-flows-00.ps

AND

        Title           : SIP Telephony Service Examples With Call Flows
        Author(s)       : R. Sparks, C. Cunningham, A. Johnston, S. Donovan,
                          K. Summers
        Filename        : draft-sparks-sip-service-examples-00.txt
        Pages           : 84
        Date            : 21-Oct-99
        
This is an informational draft showing one implementation of a set
of traditional telephony services using the Session Initiation
Protocol. Diagrams of the SIP conversations and the complete SIP
messages are provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-sip-service-examples-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-johnston-sip-call-flows-00.txt" or
        "get draft-sparks-sip-service-examples-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-johnston-sip-call-flows-00.txt".
        
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail
readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

---

From: "Rick Workman" <[email-masked]>
Date: Wed, 27 Oct 1999 12:22:48 -0400

Alan et. al.,

I just started reading through your draft on SIP Telephony call flows and had a few
comments/questions on the use of "tel:" (and similar schemes) URL's in SIP
messages.

For calls originating in the PSTN, it seems to me that tel: URLs would be the
preferred scheme in the To: header and the RequestURI for the initial INVITE. The
main reason for this is that destination host isn't (and shouldn't be) known to the
gateway; all it knows about are the dialled digits and and perhaps some originating
context based on the incoming trunk. The destination user agent may be another
gateway, a SIP phone/soft client, or some IVR service, any of which may not even be
in the same domain as the incoming gateway. Using the gateway host designation
seems artificial at best and may even cause the invitation to be routed back to it
if some naive proxy got involved. Using the tel: URL addresses seems to solve this
problem while permitting  proxies to map the RequestURI to a more SIP friendly form
if necessary. A similar issue arises for calls originating in SIP terminals; again
the client may have no real knowledge where the server agent will be located,
perhaps relying on a gateway selection (or other) service.

There would seem to be a couple of  minor issues in using  tel: URL's. They don't
seem to have quite made it to RFC status yet, but there's lots of things in that
category. They also seem to represent outgoing calls to the PSTN.
(<draft-antii-telephony-url-11.txt> : "They are intended for describing a terminal
that can be contacted using the telephone network." ) This fits well for calls made
from SIP to the PSTN, but doesn't seem to describe the case where a SIP terminal
was called from the PSTN using a telephone number (or does it?). To distinguish
between the two cases, the proxy may use additional contextual information, e.g.,
the invitiation originated in a known gateway. Alternatively, it may make sense to
permit the tel: URL syntax as an extension to the sip: URL syntax, or to define a
new scheme name which can be used with the existing tel: syntax.

I also don't understand the comment that tel: URL's are not routable in a SIP
network. In theory, any URL is routable if the SIP node is prepared to deal with
it, e.g., map dialled digits to a host. However, it doesn't make a lot of sense to
use non-SIP URLs in Contact headers for sessions (although it might for Contacts in
registrations as shown in the detailed call flows).

Finally, a minor aesthetic point on the private number format. While building on
the proposed tel: URL syntax, it seems to be a bit of a force fit into the SIP URL,
e.g., must use ',' instead of ';' before the phone-context since semi-colons aren't
allowed in user names. Use of tel: URLs would seem to resolve this as well.

Rick Workman
Carrier Networks
NortelNetworks, Ottawa

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Oct 1999 17:13:18 -0400

Rick Workman wrote:
> context based on the incoming trunk. 

I agree completely.

The destination user agent may be another
> if some naive proxy got involved.

Right. Using the IP address of the originating gateway is not the best
thing to do; slightly better is the address of the proxy (i.e.,
sip:[email-masked]), and tel URL is even better.

 Using the tel: URL addresses seems to solve this
> perhaps relying on a gateway selection (or other) service.

Exactly.

> category.

Its under IESG consideration now. Should be an RFC quite soon.

 They also seem to represent outgoing calls to the PSTN.
> was called from the PSTN using a telephone number (or does it?).

It could. I agree that a literal reading of the tel URL would imply that
this doesn't count. But, IMHO, the tel URL points to a resource; that
resource is some device *named* by a phone number only. So, I do believe
it makes sense to use it in this way to. You would need some kind of
database (ala enum) to translate this into a more fully qualified SIP
URL.

 To distinguish
> new scheme name which can be used with the existing tel: syntax.

The distinction is only on whether or not a translation step is
required. In general, we need to know what is represented by the tel
URL? If a PC host has a telephone number, it should be possible for
another PC host to call that number, and get the first host. So, in
general, we need to determine whether or not a tel URL has been
translated - that is, whether it represents a terminal on the PSTN, or
whether it represents a "name" which must be converted. The DCS guys ran
into exactly this problem. I believe what we need is basically a tel URL
extension, which specifies whether the number has been translated or no.
This was pretty much what they did.

> registrations as shown in the detailed call flows).

As a separate issue, I think its a bad idea to put anything but full
hostnames in Contact headers.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 210 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Oct 1999 10:35:53 -0400

Henning Schulzrinne wrote:
> Since "To" and "From" contain logical addresses, they should definitely
> contain tel: URLs. However, for the Request-URI, which reflects the next
> stage of translation, somewhere a host enters the picture. Either the
> gateway has a default outbound proxy (in which case it would presumably
> translated a tel: destination to a sip: destination) or the gateway does
> the translation to sip:[email-masked] itself.

Need it translate the tel URL before sending it to a local proxy? I
guess you can argue this either way. In one sense, changing it to
sip:[email-masked] is right since I am talking to the proxy at
mydomain.com; effectively I'm trying to reach this number through this
domain. On the other hand, the resource I am still trying to reach is a
phone number, and the outbound domain is not really the namespace in
which this number is defined.

> If it's tel:#, it needs to be translated to sip:#@domain, at which point
> the # is just an identifier. Why would you need a further
> identification? In particular, this is not fixed: in the future, the
> same # can well refer to a legacy "black" phone at night (at home) and
> an IP phone during the day (at work).

I was thinking along the lines of how enum gets integrated into the SIP
architecture. We start with a phone number, and this number really is a
"name"; using enum, we can translate it to a sip URL, mailto URL, and so
on. In many cases, this number is a name for a terminal on the PSTN with
the same number. In other words, the tel URL is just a normal POTS line,
and this number has no entry in the enum database. Say some IP phone
makes a call to tel:1234567. The first outbound proxy uses enum, and
finds that this number is not in the database. So, it forwards it to the
next hop proxy, using a tel URL in the request URI. This proxy doesn't
need to look it up in enum once more, as its been done. A similar issue
arises if the first number did exist in enum, but was mapped to another
number (tel:1234567 -> tel:2125551213). This is basically LNP. The next
hop proxy doesn't need to look up tel:2125551213 in enum.

I think what you are proposing is that translation to the SIP URL
basically implies that the lookup has been done. That works, but I think
it might be combining two things together that are really different. Not
sure...

> Actually, short-form hosts should probably be explicitly be discouraged
> in all URLs since it invites nothing but trouble. I've added a "SHOULD
> be a FQDN" in the URL section (which would apply to Contact).

Not just short form hosts, but things like [email-masked] can
also be problematic if not handled correctly. You need to make sure that
this address is always routed to the terminal from which I sent/received
the original INVITE for the call. In the absence of nats and firewalls,
the Contact: header in the INVITE is ideally the full hostname from
which the INVITE is sent (sip:[email-masked]). It can
be something thats actually a proxy, like sip:[email-masked],
but as I mentioned, the routing has to get the request to machine1 from
that proxy.

-Jonathan R.

---

From: "Rick Workman" <[email-masked]>
Date: Thu, 28 Oct 1999 10:31:49 -0400

My summary:
This would seem to indicate general support for using tel: URL's when dialled digits are
the only information available. The RequestURI may be translated to a more helpful SIP URL
as necessary. Minor comments/questions added in text.

Rick

Henning Schulzrinne wrote:

> Jonathan Rosenberg wrote:
> >
> > Rick Workman wrote:
> > >

Actually, I wasn't concerned about the "From" address since the host is known at least for
the session in question. I do agree that somewhere before reaching the server UA the tel:
URL will probably be translated to a SIP url. (I don't think this is mandatory, is it?)

> The SIP URL already has the tel numbering as a subset in the user part
> (with some restrictions where this doesn't make sense). In the next
> round, we'll make that more explicit. We couldn't, since the tel: draft
> wasn't a citable RFC at the time. You'll notice that the BNF is a pretty
> close copy of the that draft.
>

The main issue is that the SIP URL requires a host designation which isn't available. A
minor point, if I've understand the BNF, is that the 'telephone-subscriber' can conatin a
';' as part of the 'isdn-subaddress' or 'post-dial' (or in 'phone-context'  in the most
recent draft) which isn't permitted in 'user'. This is why the MCI folks had to replace the
';' with a ','.

> As a side note, [email-masked] can have two slightly different
> meanings:
>
> (1) columbia.edu is a VoIP gateway and dials the number;
>
> (2) the user has registered at the columbia.edu with that number.
>
> I don't think anybody but columbia.edu needs to know the difference. (We
> have the phone qualifier if it really does.)
>

So I guess I'm trying to figure out what happens when:a) Somebody on the PSTN dials
2129397042.
b) Some SIP client  INVITEs tel:2129397042 to a session, not really knowing (or caring)
whether the called party is a black telephone or a SIP phone.

If 2129397042 is a unique telephone number (across SIP and PSTN networks) and can only
refer to the SIP agent (or service), perhaps there isn't any problem (in theory). So the
question is whether this underlying assumption is valid?

> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Oct 1999 22:36:17 -0400

---

From: Alan Johnston <[email-masked]>
Date: Thu, 28 Oct 1999 13:27:05 -0500

We were reluctant to include the tel URL in this draft since it was still in I-D
status, and using sip URLs worked, if not as elegantly.  By the time we make the
next revision, it should be an RFC and we will probably change the sip URLs to
tels.  We attempted to use sip URLs as #@proxy rather than #@gateway, but we ran
into problems populating From headers on incoming calls from the PSTN.  The tel
URL will probably solve these issues.

I hope that once the tel URL reaches RFC status, the telephone number handling
in sip URLs is again matched to the tel URL.

Glad everyone is reading the document - the more feedback we get the better!

Alan Johnston
MCI WorldCom
+1-314-342-7360
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Oct 1999 19:59:16 -0400

Jonathan Rosenberg wrote:

> which this number is defined.

I suppose it is up to the proxy to either accept or reject non-SIP URIs.
I would guess that most current servers would not take too kindly to a
tel: URI. (I just fixed our sipd server to allow this, to see how
difficult this change might be. Two lines of code, as it turns out.)

In general, a server should probably allow non-SIP request URIs (as well
as in the To header of the REGISTER).

This should probably be made explicit. The HTTP spec only seems to imply
that something like

GET sip:user@host HTTP/1.1

would be illegal. (Having a real URI in the request line, like 'GET
http://www.ieee.org HTTP/1.1' is fine, albeit not common except when
addressing proxies.)

> need to look it up in enum once more, as its been done. A similar issue

However, somewhere along the way, this has to be translated to a
gateway. Why would this not be done at the same time?

The first proxy has to forward this request *somewhere* on the Internet,
so why not translate this into 

sip:#@somewhere;user=phone

No information is lost. The next hop will then decide whether this is
indeed a real phone, with a gateway to be contacted, or this actually
isn't, due to some other remapping.

> hop proxy doesn't need to look up tel:2125551213 in enum.

This depends on whether enum is a global database or whether certain
translations are done locally. For example, you could have a global
translation to a current carrier number ("LNP"), but only the current
carrier keeps track of whether this number is currently on 24 ga twisted
pair and 48 Volts or gets IPtone. Thus, it may have to do a second
look-up anyway.

> it might be combining two things together that are really different. Not

I'm just not sure that a single-lookup-model even works within the tel:
context. Why have a proxy if it doesn't do a lookup - that's it's
primary justification, after all...
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Oct 1999 20:05:20 -0400

Rick Workman wrote:

> recent draft) which isn't permitted in 'user'. This is why the MCI folks had to replace the

Actually, the correct thing to do here is URL-escaping. The phone number
is treated by the SIP URL like an opaque object. Thus, I don't think
that replacing ; with , is the right solution. The BNF for 'user'
explicitly says "escaped" as one of the options.

> So I guess I'm trying to figure out what happens when:a) Somebody on the PSTN dials

I think having two numbering spaces that look alike but are different is
generally a bad idea. In that case, you'd at least would need to add a
context identifier to the phone number part to disambiguate the context.
I see no reason why the SIP world should have its own E.164-like space -
after all, we are trying to get rid of random digit strings as user
identifiers. Even Compuserve has conceded that point, I believe :-)

---

From: "Francois Morel" <[email-masked]>
Date: Fri, 29 Oct 1999 08:46:27 -0400

There is a proposal from the DCS group to relax the URL syntax and to allow
SIP URL without the host part. Here is the extract from
"draft-dcsgroup-mmusic-state-00.txt" dated from July '99:

BEGIN[
4.1 SIP URL Extensions

   The SIP URL host syntax is extended to allow hosts to be identified
   by a simple phone-number (E.164 number). The SIP client initiating
   the call may not know of the gateway associated with the number. The
   Telephony subscriber URL definition in RFC 2543 for a telephone
   number requires the phone number and its gateway association in the
   host parameter. We propose that this constraint be relaxed to allow
   hosts to be identified by their E.164 numbers only. If this
   interpretation of the hostname is used, the associated user-param
   user=phone MUST be present.
]END

Has this been accepted by the SIP group? If so it could be an alternative to
the use of tel URL?

Francois Morel
InnoMediaLogic Inc.
Tel: (450) 676-2977 x128 Fax: (450) 676-0360
mailto:[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Oct 1999 10:11:41 -0400

> Has this been accepted by the SIP group? If so it could be an alternative to

This is one of the issues I'm sure we'll discuss at the Sunday interim
meeting. I think the DCS group correctly saw the need for a URL only
with a phone number and not a host part, but they weren't aware of the
tel URL (please correct me if I'm wrong, BTW). As the difference is just
syntactic and not fundamental (sip:5551212 vs. tel:5551212), I think we
can come to a consensus on one way to do this.

-Jonathan R.

---

From: "Rick Workman" <[email-masked]>
Date: Fri, 29 Oct 1999 11:14:39 -0400

> URL will probably solve these issues.

Just to clarify my position,  I think it makes sense to use SIP URL's in the From headers in
INVITEs originating from gateways (or any SIP UA for that matter). In the context of that SIP
session, the From host is the gateway so there's no problem in using #@gateway there, and
allows the inclusion of tag fields and calling name if necessary. However, the only
information the gateway has about the destination endpoint is just the dialled digits, so
"manufacturing" a To host in the gateway is problematical. It's less of a problem for the
RequestURIs since proxies can change those in course of routing the request, but I see no
reason why the tel: URL shouldn't optionally be used there as well. This does require that
proxies support this but this seems fairly fundamental to PSTN interworking (but not really
an issue if you're not worried about the PSTN).

> in sip URLs is again matched to the tel URL.

I'm not sure why the use of the tel: URL in it's I-D form isn't the same as using the
proposed 183 response, which arguably is in a less mature state. I guess this depends
somewhat on  the intent of publishing your call flow draft. As a discussion paper, I think
it's a valuable and appreciated contibution to the SIP community. If it's intended that it
evolve to RFC status as a standard for SIP network operation then I think we have to be more
careful. For example, are the assumptions stated in the first section intended to be
requirements. If so, what should happen if the assumptions are violated even though the SIP
protocol usage is valid.

Rick Workman
Carrier Networks
NortelNetworks, Ottawa

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Oct 1999 11:49:31 -0400

> http://www.ieee.org HTTP/1.1' is fine, albeit not common except when

I agree we should say something about this. Also some wording on what to
do when the URI type is one you don't understand or one that doesn't
make sense in the given context. I believe the BNF already allows any
field to take any URI.

> pair and 48 Volts or gets IPtone. Thus, it may have to do a second

Right; the idea here is that enum is a global database. Local
translations, of course, can and should occur at each proxy. I guess
since each proxy performs local translation, its that proxies
responsibility to perform any accesses to global databases like enum
that might be needed.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Oct 1999 11:58:24 -0400

> make sense in the given context. I believe the BNF already allows any

Currently, the spec already says:

"If a SIP server receives a request with a URI indicating a scheme other
than SIP which that server does not understand, the server {\MUST}
return a 400 (Bad Request) response.  It {\MUST} do this even if the
\header{To} header field contains a scheme it does understand.
This is because proxies are responsible for processing the
\header{Request-URI}; the \header{To} field is of end-to-end
significance."

Anything beyond that needed?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Oct 1999 16:05:01 -0400

> \header{Request-URI}; the \header{To} field is of end-to-end

I don't think this rule would apply for Contact headers in
registrations. If the server is acting as a redirect server, it doesn't
need to understand anything about the request. We should also explain
that other URIs are allowed, and perhaps mention the telephony URL as an
example, and that the function of the proxy is to translate the request
URI, whatever it may be, based on any logic at its disposal.

-Jonathan R.