Subject: comment on intel i-d on h323 and internet

From: Jon Crowcroft <[email-masked]>
Date: Wed, 05 Mar 1997 17:54:32 +0000

very useful document.....it helped me see what the problems are very
nicely...

one thing that would sureley need resolving is that the RTTs for the
two TCP channels used to convey the h245 and q931 messages will be
variable, which means that the behaviour of a multiway conference will
be non-deterministic compared with one over ISDN?

jon

---

From: [email-masked] (Christian Huitema)
Date: Wed, 5 Mar 1997 17:59:44 -0500

Last time I counted, doing RAS + q931 + H245 implied :

1 RTT for RAS,
3 RTT for q931:
        1 for the TCP SYN,
        1 for the TP0 SYN in RFC1006
        1 for the q931 call set up
4 RTT for h245:
        1 for the TCP SYN
        1 for TP0
        1 for the capacity exchange
        1 for the channel open
which implies 8 RTT before you set up, say, a telephone call.  The
current Internet RTT for a long distance transmission is at best 100 ms,
more likely 200.  So, we are speaking of 0.8 to 1.6 seconds to set up
the call.  If you have any transmission error, you have to add 4 seconds,
i.e. the initial timer estimate of TCP.  and we can certainly expect
quite a few errors on long distance transmissions...

-- 
Christian Huitema

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 06 Mar 1997 08:46:53 +0000

this is a seperate but useful point......

but yes,. why h323 can't just use either TCP conenctio ncompletion as
implict q931 setup completion, or even use a multicast control
protocol (actually they are working on that now) was always beyond
me.......ditto for the H245, at least that could remove 2 RTTs or even
3 or 4 if you remove TP0 mapping....

[we've been here before a few times, havnt we!!!]

but my main concern was about the multipoint controller - the order of
arrival of conference control application messages is non determined,
where as with a fixed RTT yo uhave in an ISDN network (viz it must be
or BONDing wouldn;t work:-), yo ucan do one time RTT estiamtion ,and
then create a perfect ordering with a trivial application protocol,
which simply wont work over a star of TCP conenctions....so the
service, e.g. for distributed whiteboards, will NOT have the same
semantics...

oh well...

 >quite a few errors on long distance transmissions...

yep,
cheers

 jon

---

From: "Michael Benson" <[email-masked]>
Date: Fri, 12 Dec 1997 18:13:20 -0500

Hello,

I have deep concerns about the ITU's H.323 standards for Internet Telephony
versus open standards.  With how it currently stands, users are able to
purchase the standards, but the standards are so incomplete and ambiguous
(very much unlike the IETF protocols) that unless a company works with an
established company in the field, then it has no chance of implementing the
protocol (this came straight from one developer, and I concur after looking
at the protocols in question).  Furthermore, some of the protocols depend on
standards that are proprietary (for example, the recommended voice codec
standard is G.723.1) which required a major investment and licenses to
multiple parties.

This goes directly against the openess that the IETF and the W3C standards
inherit, and the ability of small developers being able to get into this
market.  The later is important because that is where the innovation
in the Internet happens.  When the bigger companies control
the standard without making it completely open and fully specified then it
will hurt all players that are not corporate based (including universities).

Furthermore, these standards are fairly bloated and not useful for the
lower-bandwidth models of the Internet, and are far from optimized.  Yet,
the IETF conceded control over this realm to the ITU.  I am very surprised
that was allowed to happen.  It was a mistake.

I know it is very late in the game for this, but does anyone share this
concern and can anything be done about it from the political/IETF arena?
Is perhaps an IETF based set of protocols appropriate?

Michael

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 22 Jan 1998 12:08:18 +0000

In message <004401bd0753$8cfb4780$010101c8@pent150>, Michael Benson typed:

 >>versus open standards.  

ok - having read over the H.323 family of standards documents (thanks
to picturetel for online copies) at some length again, I have to
agree.

1/
It seems that H.323 is aimed (along with all the other H series) at 
extending the ISDN _videoconferencing_ standards on to unreliable packet 
LANs, but it is 
i) NOT aimed at solving the scaling problems of WAN Internet 
ii) has a large amount of baggage associated with interworking with
many other standards - particularl selection and control of
multiplexing
iii) is for conferencing not telephony
iv) doesn;t appear to have a clean call control model
2/
It seems that session advertisement, invitation, address allocation,
multiplexing (such as it is in rtp), rtt estimation, and many other
functions are already addressed, both for telephony and for
conferdcning in the "pure" Internet 'standards' work.....

A core piece we might learn from is the conference control
fucntionality in H.245 part of the standards IFF it were expressed in
a way that would tell us how to actually implement it in a scalable
way, but it isn't.

[main value we gain from ITU work at the moment I see as coding -
basically link level framing and application level media coding and
 compression standards...]

So I am left with the feeling that we should proceed with "our own"
and then specify interworking - why start with something that is
primarily targetted at talking to gateways to ISDN? why not start iwth
a core WAN Internet conf/call control protocol, and then see what a
parsimonious design for a gateway would really look like?

see 
http://www.cs.columbia.edu/~hgs/sip/
where
there's a link to h.323 v. sip discussion
for some excellent dissection of the packet exchanges - it seems clear
to me that the Q931/Q932 stubs, the RAS and other phases are
completely unnecessary in most conferences, and that we can specify
some equivalent functions (actually, the Q931/2 are partly implicit in
any reliable conf control transport protocol, and for media streams i
RSVP or other signaling), many of trhe RAS functions could be done by
simple use of SAP/SIP, and the rest is dealt with mostly by RTP/RTCP -
if this works, then the gateway can map these (largely implicit)
functions to H.323 (or 320/321/322) as needed.....

 cheers

   jon

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Jan 1998 09:35:02 -0500 (EST)

Jon is basically on target there.  The main problems with H.323 are:

1) That it is designed for interworking with H.320, i.e. videoconference
with ISDN, which mandates a two phase conection set-up: first build the
equivalent of an ISDN circuit, then negotiate how to mux channels on that
circuit.

2) That it is top heavy, in fact a monument of complexity.

The two phase set-up has very weird consequences when you try to
interconnect an H.323 terminal with a plain telephone through an Internet
telephony gateway.  Basically, at the end of the first phase (the
H.225/Q.931 layer of H.323), the phone call is set and the phone user
starts speaking and listening.  Yet, the H.323 user will not listen and
cannot speak until the H.245 negotiation has been completed -- on the
Internet, this may take a second or two.

Implementors of H.323 are trying to solve that problem by proposing
kludges.  One can for example start the negotiation of H.245 as soon as
the phone "starts ringing", without actually waiting for completion of the
Q.931 procedure.  This works if one solves the resulting synchronisation
problem, and cuts delays significantly.  But there is no guarantee that
all terminals support this non standard behavior.

Another kludge is proposed in the revision of H.225, basically allowing
Q.931 to carry a session description.  But then one will have to solve te
interaction between version 2 and version 1, which is made hard by the
next problem, the sheer complexity of the spec.

Connection set-up in H.323 requires three successive exchanges, for
H.225/RAS, H.225/Q.931 and H.245.  None of these protocols is simple.
 H.225 includes 15 pages of ASN.1, plus inclusion by reference of the
Q.931 specifications.  H.245 includes no less than 60 pages of ASN.1.
 Even if you use an ASN.1 compiler (and you really have to), you are left
with hundreds of parameters to set right if you want to interoperate.  The
chances that a programmer goofs up here or there are enormous; the problem
space is so large as to make it out of the reach of most testing
techniques.

Version 2 may include the faster call set-up procedure described above,
but it also includes tons of extensions, in fact a whole new additional
recommendation (H.450).  As with many ITU standards, the behemoth merely
gets fatter as it ages.

So, to conclude, I heartily support Jon's recommendation. We should
proceed with "our own" and then specify interworking.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Jan 1998 09:52:50 -0500

> Internet, this may take a second or two.

You've got similar problems with SIP, where the remote terminal
can be "alerting" but the connection might not be
established because of lack of resources - again, this is
particularly a vulnerability in PSTN gateways, or any other
scenario in which you're making use of expensive, scarce, or
tightly controlled resources.  Note that this isn't an
argument against SIP, but rather that it's going to need
some tweaking to make it more general.

Melinda Shore
Lead Network Systems Programmer
Cornell Information Technologies
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 22 Jan 1998 12:14:30 -0500 (EST)

On Jan 22,  9:52am, Melinda Shore wrote:
> Subject: Re: H.323
> tightly controlled resources.

This is similar, but however somewhat different in nature, because the
invitation carries the SDP description of the session.  The station that
receives the invitation can check and even reserve the resources before
even ringing -- this is indeed what is done on the PSTN today.

Also there is no question that all resources have been allocated by the
time an acceptation is received (200 OK), which means that one can safely
map the 200 OK message to, for example, an ISUP circuit completion message
(ANM).

---

From: Tim Dorcey <[email-masked]>
Date: Wed, 21 Jan 1998 10:41:21 -0700

I agree with the criticism of H.323.  There is little reason to expect a
direct derivative of a standard that was introduced in 1990 to standardize
the design of special purpose hardware for videoconferencing over
circuit-switched telephone networks to be a good guide to the 1998 design
of software that runs on general purpose desktop computers connected by a
best-effort packet-switched data network.  The contexts are fundamentally
different.  With H.323 you get all of the disadvantages of a lossy packet
switched network, with none of the advantages (except low cost).

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 23 Jan 98 12:31:08 JST

Jon;

I'm a little bit confused.

> parsimonious design for a gateway would really look like?

ISDN?

Why don't we start with something that is primarily targetted
at talking to gateways to analog POTS?

A core WAN Internet conf control protocol seems to be too comlex
to start with.

							Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 23 Jan 1998 13:20:04 +0000

>>Jon is basically on target there.  The main problems with H.323 are:

to be fair to H.323, the problems with Internet Telephony are
1/ we don't have a call routing protocol which includes provider
selection
2/ if you include phases
i) server location including
ii) lookup user in directory - LDAP - get sip id (needed to get real
"number portability", for sip ids ...can't just have
[email-masked] 
since there's quite a few j.smiths...
iii) lookup sip id in DNS and get IP address
iv) make sip invite
v) do RSVP (or similar)

3/ we need to use premium services somehow, whichneeds them to be
deployed - where not, we need someone to figure out a charge/refund
model that maps RTCP RR loss data onto a refund (especially if the
call routes to a GSTN/POTS gateway)

4/ if we are interworking POTS and IP telephony, while we can be smart
about echo in the packet net and tolerate 400msec delays (or 200 +/-
100ms with adaptive playout set to 400ms)  then we need to route via a
the poor legacy POTS perdson's half of the call via
an echo cancllor port on an exchange...
echo cancellor ports might be (are) a scarce resource  c.f. satellite
calls...

5/ how to transcode from some of the smarter
IP loss tolerant codings to PCM
and then straight into the D2A port on an exchange (or onto an ISDN
call) is easyish...but there's quality degradation sometimes - might
be refunds needed.. again....

to set a level playing field betweein voice on IP access ISP
providers, voice on IP backbone providers, telcos who are also IP
providers, and the pure pots providers is slightly difficult

etc etc....

j.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Jan 1998 09:22:51 -0500 (EST)

Jon,

You are correct to note that we have problems that are independant of
the particular signalling protocol that one wishes to use.  User location
problem and transport quality problem, which you quote, and also 
the relation between phone numbers and Internet names and addresses,
which is currently on the SIPTEL charter.

At first sight, user location problems are no different from what we are
already doing with e-mail, and I don't see why we could not follow the
very same model -- albeit not necessarily with the very same identifiers.
Doing a full fledge directory search before each call looks like overkill.
You don't do it for e-mail, and you also don't do it for mobile telephony.
You do perform a database access, very similar to a DNS look-up, but that
is another matter.  SIP is designed to embed that functionality; H.323/RAS
features a "location request" primitive that can also achieve this result.
The difference is that in the SIP case the resolution is "embedded", i.e.
can be performed during call set-up, while in the RAS case it is yet
another transaction.

Whether we need RSVP or something else is another matter entirely.
Frankly, I don't predict much success for Internet telephony if the 
transmission delay cannot be brought down to something like 100 or maybe
150 milliseconds.  This implies major infrastructure development, and
also some revision of unnecessary sources of delays in the current
architecture, for example queues that are allowed to become very large
for no good reason (OK, there maybe a good reason), or route management
algorithm that flush the cache every 30 seconds, or whatever has cropped
in releases and releases of software in hosts, routers and switches. In
any case, this will not be done in the Conctrl, or Siptel, groups.

On the other hand, good quality transmission may require access to some
premium backbones.  That access will very likely be gated.  The session
control protocols will have to take this gating into account.

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 23 Jan 1998 14:29:59 +0000

>>Whether we need RSVP or something else is another matter entirely.

sure - i didn't want to get into the int-serv/diff-serv debate again
(here or elsewhere) but i think its clear (c.f. some of henning's
other excellent online notes) that preimum service or very simple
approaches based on subscription and seperate overlays/backbones and
many other appriaches can, and will be used by ISPs to do toll quality
voice transport provisioning

 >>any case, this will not be done in the Conctrl, or Siptel, groups.

sure...agree

 >>control protocols will have to take this gating into account.

right.....

 cheers

   jon

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jan 1998 11:33:28 -0500

In message <[email-masked]>, Christian Huitema
> control protocols will have to take this gating into account.

Indeed, that's one reason SIP has the notion of proxies and proxy
authentication. There may well be a mechanism where SIP picks up a magic
cookie from the gateway, which it then presents to RSVP (or enables some
kind of filter in a router) to gain access to the premium service.

---

From: Mark Handley <[email-masked]>
Date: Fri, 23 Jan 1998 11:35:08 -0500

>since there's quite a few j.smiths...

Sure you can - but it's up to anyphone.org how they allocate SIP ids.
You still need LDAP or whatever to serve as a white pages, but it's
not needed for normal calls where you already have the SIP id from
their business card/web page/whatever.

I expect that there will be companies offering location independent
SIP ids in exactly the same way as the acm and a few other companies
offer email addresses that don't change when you change employer or
ISP.  They would issue a "moved temporarily" response to incoming
calls directing callers to your current provider, perhaps with a cache
lifetime of a few months.  Anyone who calls you regularly would cache
the response and not need to go via anyphone.org to call you.  If you
then moved unexpectedly, your old employer/ISP simply returns "non
known" and your SIP agent knows to refresh it's cache from
anyphone.org.

Of course all of this needs appropriate authentication, but the
problem seems tractable.

Cheers,
	Mark

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 23 Jan 1998 10:40:14 -0600

>Yet, the H.323 user will not listen and

One can experience up to 10 seconds between two dial access point, using
well known H.323  conferencing PC clients. The call setup delay in some
instances is so big, that something in the application times out and crashes
the PC. Probably TCP retransmits. Makes one wonder why the trade media has
not published "test reports" given this juicy topic.

LAN access to the Internet gives better results.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christian Huitema
> Sent: Thursday, January 22, 1998 8:35 AM
> To: Jon Crowcroft; Michael Benson
> Cc: confctrl
> Subject: Re: H.323
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 23 Jan 1998 11:59:12 -0500

Jon Crowcroft wrote among other interesting things:

> since there's quite a few j.smiths...

The naming issue for portable names presents an interesting issue. There
seem to be a number of alternatives:

0) Unlike the telephone, we can ignore organizations here, as they will
have a domain name of their own. Yahoo and kin provide reasonable
directory lookup capabilities.

1) Lookup via directory services. Not too useful in general, as you can
never be sure to actually find the right J.Smith unless the directory
contains a lot of personal information (workplace, age, gender, etc.).
It also takes far too long to scroll through the list of common names.
It also seems rare that you call an individual that you have not "met"
in some other form before: web page, business card, email, personal
address book, etc. Most of the directory assistance calls seem to be for
people you know that have moved to a new place (and businesses, but see
(0)).

2) Since SIP and maybe RAS allow the separation of the call routing from
name lookup, I can see lots of services similar to the free email
services. All the colleges will have names like
[email-masked] (for a small fee, naturally); IEEE, AAA (the
American Automobile Club), fan clubs and who knows who else can do the
same. Actually, far cheaper than email forwarding services, since
there's no need to store much of anything. If this takes off, I'm sure
somebody will ask for a Sponsored-By SIP header, just like the email
footnotes found today at hotmail and such :-).

3) Some servers that I've worked on allow a more flexible naming, e.g.,
[email-masked] and then use local tactics to check if this
name is unambiguous and possibly return a list of choices. This has been
done for email by organizations like Bell Labs for a while. It has the
advantage of avoiding an additional lookup if there is no ambiguity.

4) There's always the possibility of using a personally, globally unique
identifier, but I don't think using a person's social security number
would fly with the general public.

5) There seems to be an unavoidable trade-off: You either have a central
registry (as for second-level domain names or 700/800/900 numbers) or
one level of indirection (somebody@registry). The first seems to be
difficult in a competitive environment and has scaling problems in terms
of directory lookup and distribution, the second means that you loose
your address if you don't like the current registry provider. Maybe all
of us will get somebody.nom DNS names, but it would make the DNS scaling
problems at least two orders of magnitude worse, as there will be very
little caching.

Given this, maybe parents will have an incentive to shy away from common
names. None of my kids need to worry about this :-)

Any other suggestions?

Henning

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 23 Jan 1998 17:15:44 +0000

>>directory lookup capabilities.

right

true...

 >>footnotes found today at hotmail and such :-).

acm and other similar orgs do these mailbox name for life...seems like
rich pickings...

 >>advantage of avoiding an additional lookup if there is no ambiguity.

yes, a lot of UK simple directory/web based lookup systems, and
mailservers do something like this in an ad hoc way...

 >>would fly with the general public.
 
yes......but if we all had registered iris/retinal/dna/fingerprint
scans, then that would give a big clue...

 >>problems at least two orders of magnitude worse, as there will be very

indeed....

 >>Any other suggestions?

let the market deliver all of the above and the customers buy the
best/cheapest/most appropriate....

 cheers

   jon

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 12:46:21 -0500

Problem: What happens if a forked request produces multiple
2xx responses if several people ``pick up the phone''?

Suggested resolution:  Proxy should send a BYE to the late comers.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Mar 1998 13:42:40 -0500 (EST)

On Mar 27, 12:46pm, Henning Schulzrinne wrote:
> Subject: SIP: Forked request

That is dirty.  There should be a way to solve it through by forking
multiple "probes", then following on with a real invite.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 13:50:41 -0500

> multiple "probes", then following on with a real invite.

That option exists today (OPTIONS). However, the behavior described
(phone rings on several desks or in different rooms) is fairly common
and useful both at home and in the office.

Also, not clear how this probe would work. Would you actually ring the
phone? If you don't, how do you know that somebody is sitting there? I
don't think I want a "Excuse me, just a hypothetical question, if this
phone were to ring right now, would you consider picking it up - just
asking..." user interface.

---

From: Mark Handley <[email-masked]>
Date: Fri, 27 Mar 1998 14:02:14 -0500

>multiple "probes", then following on with a real invite.

It seems we might need an ACK to indicate to the later callee what
happened (I assume the proxy already relayed the first response back
to the caller).  Under these circumstances, it should probably be up
to the callees to decide the correct course of action, and handle this
using call-transfer functionality if necessary.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Apr 1998 09:56:32 -0400

Issue: Currently, SIP allows both relative and absolute times (delta
seconds and HTTP-Date as in "Mon, 20 Apr 1998 09:25:49 -0400") for the
Expires and Retry-After headers. This corresponds to the HTTP/1.x
conventions for fields of the same name. It has been argued that the
absolute form is harder to parse, particularly in Internet appliances
and that we should restrict SIP to only use the delta-seconds form.

The two are functionally equivalent (as far as I can tell).

In some circumstances, HTTP-date may be easier to present for small
devices [probably only relevant for Retry-After, where a value of 834848
is not particularly meaningful for user display and 9.66 days only
marginally so.]

---

From: Christian Huitema <[email-masked]>
Date: Mon, 20 Apr 1998 18:40:02 -0400 (EDT)

Henning,

At this stage, it is more important to get a first version of SIP 
published than to try minor adjustments.  Let's concentrate on the
real problem, i.e. fining a proper security architecture, and 
go to WG last call.  The more you delay, the more this work is
becoming irrelevant.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 20 Apr 1998 21:47:53 +0200

Agree. SIP "as is" is too important to delay. 

Thanks, Henry

> Sent: Tuesday, April 21, 1998 12:40 AM
> To: Henning Schulzrinne; [email-masked]
> Subject: Re: SIP: Expires, Retry-After
> 
> 
> Henning,
>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 21 Apr 98 12:57:46 JST

> Agree. SIP "as is" is too important to delay. 

Why? It may be of some importance for a toy environment of Mbone.

But, what is the importance of it in the real world?

It is just overkill for IP telephony, for example.

						Masataka Ohta

---

From: Christian Huitema <[email-masked]>
Date: Tue, 21 Apr 1998 11:14:30 -0400 (EDT)

OK, for the factual comment:

1) I don't really care about expiration dates.

2) We must align "From" and "To" with the mail practice.  Since RFc 822,
   a text between parenthesis is an optional comment, that can be
   located anywhere in the address.  The user friendly name should
   be placed before the <> notation.

---

From: Mark Handley <[email-masked]>
Date: Tue, 21 Apr 1998 09:48:13 -0400

>Agree. SIP "as is" is too important to delay. 

You misunderstand - we're going through the process of producing what
we hope is the last ID before we go to WG last call.  This draft
should be done _this_ week.  As we go through this, we're _obliged_ to
do a very detailed read through, identify any problems, and solve
them.  We're actively doing this this week.  

The read through also throws out a few small issues that we can easily
change at this point, but will have trouble changing later.  Whether
or not we change them won't make any difference to the timing.  When
we can't agree amongst ourselves (and mostly we can because the best
solution is clear) we throw something out to the list for comment.
Feedback would be most useful.

When we do get the ID out this week, I'd _really_ like people who are
interested to read it as soon as possible - the earlier we get
feedback the better!

Cheers,
	Mark

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 21 Apr 1998 06:27:09 +0200

Masataka,

>It is just overkill for IP telephony, for example.

Are 20 ISDN signaling messages over IP, network zones with gatekeepers,
security tokens, etc. preferable for IP telephony ?
How much technology is an overkill for part of the $450B telephony market ?

Henry

> From: Masataka Ohta [mailto:[email-masked]]
> Sent: Tuesday, April 21, 1998 5:58 AM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: SIP: Expires, Retry-After
>
>

---

From: Jim Toga <[email-masked]>
Date: Tue, 21 Apr 1998 13:22:49 -0700

Henry,

There is exactly one (1) message in each direction  to set up an H.323 call
which is what I assume you were referencing below....

Security 'tokens' may optionally be included in these messages; most $450B
businesses want security.

Best Regards,
jimt.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 21 Apr 1998 16:21:33 +0200

> There is exactly one (1) message in each direction  to set up an

Jim,

Glad to have expertise on board: The fast H.323 call setup is between
terminals that know each other's address and without invoking the gatekeeper
and its services, or is it with the gatekeeper in between ? Reading H.323
v2, I saw several types of  message exchanges.

Thanks, Henry

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 22 Apr 98 14:14:45 JST

Henry;

> security tokens, etc. preferable for IP telephony ?

It is another overkill.

> How much technology is an overkill for part of the $450B telephony market ?

Anything more than minimum necessary is overkill.

Can't you spend just 5 minutes to read draft-ohta-notasip-01.txt?

							Masataka Ohta

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Apr 1998 13:55:14 -0400 (EDT)

> Can't you spend just 5 minutes to read draft-ohta-notasip-01.txt?

I did.  Well, your draft starts by saying something like:
   The caller host somehow (through SDP URL [SDP, SDPURL] of callee's
   home page, for example) finds the callee's IP address, UDP port
   number (with default port number of <to be assigned by IANA>) and
   desired encoding.
... which is largely what SIP is about. (or H.323 RAS.)  So, there is
obviously some use for SIP, as least as a competitor to Altavista and
Yahoo.

Then, your set-up procedure is to simply send RTP packets to the right
address, so that the receipient notices the address and starts replying.
 This is certainly the minimum that one can do.  The problem there is
indeed that people have grown accustomed to a couple of useful feature,
like being able to check who is calling before they answer the phone, or
being able to redirect phone calls to different locations (such as
different operators in a call center).  Just sending RTP packets won't let
you do that.

Finally, as you mention, part of the problem is the operation of gateways.
 Like it or not, this implies some compatibility with the regular POTS
call models, with definitions of progress tones, etc.  Just one message
does not quite cut, there.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 23 Apr 98 11:16:22 JST

Christian;

> ... which is largely what SIP is about. (or H.323 RAS.)

As SIP can't be used for large scale multicast, all the information
to initiate a session must be provided somehow without SIP, perhaps
within SDP.

Large scale multicast can not and does not use SIP.

Then, there is no reason to use SIP for unicast or small scale
multicast, becasue all the information is already there without
SIP.

> So, there is

There is no need for SIP.

> Then, your set-up procedure is to simply send RTP packets to the right

RTP or whatever described by SDP or something like that.

>  This is certainly the minimum that one can do.

Yes.

> The problem there is

With such a logic, you can put any complex feature to IP telephony
only to make it H.323.

But, which of the features are accesible through dumb POTS?

> like being able to check who is calling before they answer the phone,

Some POTS in Japan today does offer the capability to tell from what
telephone numebr the call is inisitated. So does NOTASIP for an IP
address.

> or
> being able to redirect phone calls to different locations

Just say, IP mobility.

Or, you can update your home page or your DNS entry, if you so wishes.

The problem here is that there already are too many ways to do the
redirection.

> Just sending RTP packets won't let
> you do that.

Just sending IP packets and just rely on the Internet protocol suits.

Then, you can get whatever you want.

> does not quite cut, there.

There is no such thing as regular POTS call model except that
the common trasnport is voice.

As you experience with credit or calling card calls, various protocols
are already constructed over voice using natural languages or dial tones.

There is no point to standardize them.

							Masataka Ohta

---

From: "Scott Petrack"<[email-masked]>
Date: Fri, 15 May 1998 02:41:51 +0200

From: Scott Petrack@VOCALTEC on 05/15/98 02:41 AM

Apologies if these are answered in some newer spec:

1. What is the correct way to make a truly anonymous phone call? The spec
says that a request MUST have a From: line in it. (In the PSTN, there are
no really anonymous calls, because the calling line always identifies
itself. I can do this in SIP by making the From: line something like
[email-masked].) Is there some protocol reason to disallow a
request with no From: line? Or should a request do something else.

2. Could someone explain the difference between the following two
exchanges:

In both exchanges the client sends an ordinary INVITE
C->S
     INVITE  [email-masked]   SIP/2.0
     From: [email-masked]
     To: [email-masked]
     ....

In exchange 1 the server returns:

S->C
     SIP/2.0 350 Alternative Service
     From: [email-masked]
     To: [email-masked]
     ....
     Content-type: application/url
     Content-length: xxx

     mailto:[email-masked]
and in exchange 2 the server returns:

     SIP/2.0 350 Alternative Service
     From: [email-masked]
     To: [email-masked]
     Location: mailto:[email-masked]
     ...

Don't both mean that the caller can be reached via Email??  If this is true
I would rather that the Location: field be restricted to
contain ONLY sip: urls, meaning that this is a sip: address which should be
used from now on for further communication about the same session.  I'd
rather not have two ways to do exactly the same thing.

At the very least the Location: field should be restricted to urls of
servers that understand the Content-type: that is in the original request.
(For example, maybe an INVITE with an SDP content-type can be responded to
by an "Alternative Service" with a Location: field with an rtsp: url,
meaning an RTSP server that is likely to understand the SDP in the original
invite.)
In order to indicate some server which is really of a totally different
type I would rather put the new URL into the Payload of the response.

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 May 1998 10:21:48 -0400 (EDT)

Scott,

Anonymous calls on the Internet really require the cooperation of a third
party, to do some form of anonymous RTP relay.  Otherwise, you can trace
the calling machine, and you are not really anonymous.

The solution adopted by anonymous remailers is to leave a "From" line,
but to put some garbage in it, as in:
        From: [email-masked]
Note that if you don't want to hide the calling station, you can always
blurr the identity of the calling party, as in:
        From: [email-masked]
but I am not sure this is really useful...

As for the redirection to a mailbox, it serves a useful purpose.  Voice
mail.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 May 1998 12:33:49 -0400

> Apologies if these are answered in some newer spec:

Nope, not yet.

> request with no From: line? Or should a request do something else.

Yes, the tuple From/To/Call-ID is needed to identify the request, once
we move to more sophisticated call models.

Note that this just has to be a unique and may well be inserted by an
anonymizer proxy.

I'm not sure if we need to define this in the spec or just in a FAQ
(where I have put it for now).

> rather not have two ways to do exactly the same thin
> 

I don't think it makes much of a difference as to where you put it. A
nice UI would probably do the following:

- process Location URLs in order of preference
- if user has configured this, automatically call SIP URLs
- if it reaches a mailto or phone URL, the UI could do one of the
following, depending on
caller configuration:
  - prompt user before dialing or pop up a mail window
  - automatically mail the invitation to the mailto address

The 350 Alternative with a payload is similar to the HTTP content
negotiation, where the header might contain URLs for automatic
processing, while the body could contain something for user
presentation:

350 Alternative Services
Location: 
Content-Type: text/html

Thank you for calling Vocaltec. Please choose among the following:
<ul>
<li><a href="sip:[email-masked]">Sales</a>
<li><a href="sip:[email-masked]">Scott Petrack</a>
...
</ul>

If the user agent groks HTML, it would display the body for manual
selection.

-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

---

From: "Scott Petrack"<[email-masked]>
Date: Sun, 17 May 1998 09:58:06 +0200

From: Scott Petrack@VOCALTEC on 05/17/98 09:58 AM

Dear Christian (and Henning at the end ;-)):

SIP is SIP and RTP is RTP. I agree that if you want the RTP to be anonymous
there is the need for an "RTP proxy".
But SIP might have many uses without RTP, and SIP proxies exist (sort of),
so I was curious in making the session invitation anonymous, without
reference to RTP.

When a call is made in the PSTN, various parts of the network have identity
about the identity of the calling line (before any media is sent). Since a
"SIP network" with lots of proxies in the middle begins to look like a
bunch of switches (at least for routing the invitations, not the media), I
wanted to know if there was some "standard" way to keep knowledge of the
caller out of even the SIP network (not just the end user).

Your answer (just to garble the From: line) certainly works, I suppose.
It's just that it might be nice to have the ability to positively signal an
anonymous call. For example, so that "Internet Phone caller Id" software
will write "anonymous call" rather than "call from
[email-masked]".

It might be nice to agree on some "anonymous" convention so that we can
satisfy both desires (to always have a from line and to signal to the SIP
servers that it is there solely for uniqueness and not for identity).

Scott

[email-masked] on 05/15/98 04:21:48 PM

To:   Scott Petrack, [email-masked]
cc:
Subject:  Re: Two more SIP questions - truly anonymous phone calls and
      redirects

Scott,

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 17 May 1998 10:34:23 -0400

> servers that it is there solely for uniqueness and not for identity).

This is relatively easily done as is, as UIs are meant to present the
display part of the From and To header, as in

From: Anonymous <[email-masked]>

This is (for example) how Netscape Mail lists the sender. Having the
anonymizer domain be available is not such a bad thing, since I'm much
more likely to pick up a call with

From: Anonymous <[email-masked]>

than

From: Anonymous <[email-masked]>

Particularly if I know that the ACM only offers this priviledge to their
membership.

Another possibility would be to define that an address without @ is
meant to be just a random identifier, something like

From: Anonymous <4475849801100813893>

My hunch is that the first version is good enough.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 18 May 1998 17:21:11 -0400 (EDT)

During the past months, the Internet telephony team at Bellcore has been
working on a protocol for controlling "simple" telephone gateways. The
SGCP assumes a call control architecture where the call control
'intelligence' is outside the gateways and handled by external call
control elements, the "call agents."  The specification of this protocol
are now available as an internet draft:

	Title		: Simple Gateway Control Protocol (SGCP)
	Author(s)	: C. Huitema, M. Arango
	Filename	: draft-huitema-sgcp-v1-00.txt
	Pages		: 54
	Date		: 15-May-98

Note that SGCP is not in competition with H.323, or SIP, but mostly
complementary.  In our approach, the signalling functions such as SS7,
H.323 or SIP are handled by the call agent, which is seen by these systems
as an SSP, a Gatekeeper or a SIP relay.  SGCP is then use to "program the
gateways" in sync with the signalling decision.

We believe that this protocol "fills a niche."  In fact, we hope that it
can become the basis for an open standard, so that call agents developed
by multiple providers can interact with gateways from different providers.
 We are also aware of the status of the MMUSIC working group, and are
definitely not proposing to conduct any such work within that group.  In
fact, we have set-up an open mailing list for the discussion of SGCP.

Please send mail to [email-masked] for subscription
requests to the mailing list, [email-masked].  This is an open mailing
list.

The mailing list archive is accessible from the Internet by anonymous ftp
to ftp.bellcore.com.  The archive file is kept in /pub/Group.archive/sgcp
directory, under the file name "archive".

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 May 1998 10:15:45 -0400

Currently, the SIP spec says that messages SHOULD not be bigger than the
MTU, if known, or 1400 bytes, if not. It has been argued that this
should be a MUST and that maybe we should impose a tighter limit (say,
2000 bytes) even with known MTUs, as it allows thin clients not to
implement IP fragmentation and limits the buffer size that needs to be
allocated by the receiver.

Message size is currently not likely to be a problem when carrying SDP,
but other session description formats (like H.245 or SMIL) tend to be
more verbose, so this may impose limitations later.

Unfortunately, going to TCP is not always an option, as the sender may
not know how big the response is. There are alternatives, such as:

(UDP) INVITE foo.bar.com
(UDP) 303 switch to UDP
      Location: sip:foo.bar.com ;transport=tcp

or

(UDP) INVITE foo.bar.com
      Accept: text/html

(UDP) 300 Multiple choices
      Location: http://www.bar.com/contacts.html

Comments?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 May 1998 10:37:57 -0400 (EDT)

henning,

The SIP messages are composed of an invitation header and a payload, SDP
in most cases.  Today, SDP already limits the size of the session
description. You could punt the issue by simply limiting the size of the
SIP header, and relying on payload specifications for the application
level limitations.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 May 98 1:21:58 JST

>       Location: http://www.bar.com/contacts.html

Maximum buffer size without PMTUD, which MUST be the case with
large scale multicast, should be less than 1280 with IPv6
and 576 with IPv4.

Howver, as SIP does not scale with large scale multicast, any
discovered MTU is fine for SIP as an informational RFC with
a narrow applicability statement.

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 20 May 1998 08:32:53 +0100

In message <[email-masked]>, Christian Huitema typed
:

at first sight, this is remarkably bellhead approach - 
a) no soft state
b) gateways appear to be modelled on systems that have _detailed
knowledge_ of the internals of the PSTN side.....

this is fine, but we need provision for systems that are
i) resilient to connectivity failures (e.g. where there are no PSTN
call charges, yo ucould envisage timing out and lettign an IPTEL side
use a second gateway to reesablish the call a la rsvp without route
pinning, to use a poor loose analogy)
ii) allows gateways that are strictly external to the PSTN and just
use access as an ordianry customer

at least one national regulator i can think of would require this....

cheers
j.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 May 1998 09:31:38 -0400

Based on the suggestion by Yaron Goland, I had folded the Antti draft
definitions of phone numbers into the SIP URL syntax. Unfortunately,
this causes a subtle new problem, in that phone numbers and user names
are no longer distinguishable:

sip:939,7042@gateway

could be a local phone number or a (CompuServe) user name. Similarly,
user names are (according to the generic URL spec) allowed to start with
a +, so that even

sip:+12129397042@gateway

could theoretically be a user name.

In some circumstances (e.g., a proxy filtering outbound calls) a
distinction between the two may be useful, even though in most cases a
gateway handling both names and numbers could simply assure that it
doesn't assign "weird" user names (starting with a digit or +). If a
generic distinction is desired, the only semi-reasonable solution I see
is to
- disallow + as the first character in user names
- disallow local phone numbers (probably not very meaningful in the case
of gateways in any event)

Other alternatives get pretty ugly (prefix phone number with _ and
such).

Comments?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 May 1998 13:03:54 -0400 (EDT)

Jon,

SGCP is about synchronizing a gateway that concentrates on handling the
signal (e.g. voice to RTP) with a server that processes the signalling.
Now, even in bell shaped dreams, nobody really expects that a single server
will control the whole universe.  The server could use your favorite
protocol to dialog with other servers (H.323, SIp, SAP or RTSP come to
mind).

As for various types of interfaces to the PSTN, sure.  We have been working
here on SS7/ISUP, but there is clearly a demand to also support Q.931,
MF sgnalling, and a lot of other stuff.

On May 20,  8:32am, Jon Crowcroft wrote:
> Subject: Re: Simple Gateway Control Protocol
> 
>-- End of excerpt from Jon Crowcroft

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 May 1998 13:06:20 -0400 (EDT)

Henning,

A gateway handling both names and numbers could easily use two
DNS names, like "[email-masked]" and "[email-masked]",
yet make the two domains synonym (using CNAME).

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 20 May 1998 21:07:47 -0400

Jon, as usual very perceptive impressions, but let me offer a few comments
which may shed a different light on this:

> Jon Crowcroft
> Sent: Wednesday, May 20, 1998 3:33 AM
> To: Christian Huitema
> Cc: [email-masked]

Yes, absolutely. The protocol's niche is in fact primarily for taking a bell
which has been cracked into two pieces and an IP network inserted in the
middle to glue it back together. Since you are starting with a bell and
ending with a bell, a bellhead approach is a reasonably good impedance match
:-)

> a) no soft state
This isn't entirely accurate. The call agent side has hard state, because at
least one of the things the gateways are hooked to is bound to have hard
state (i.e. the PSTN side or sides) and there isn't a lot to be gained by
making one "hop" of the chain of hard state a bit softer. On the other hand,
the gateways have much softer state - in fact they have practically no state
at all - and they can survive things like one call agent disappearing and
another taking over in the middle of a call.

> knowledge_ of the internals of the PSTN side.....
Not really. The gateways know only that they are converting packet streams
to TDM streams (or possibly one packet stream into something else...like a
cell stream) and they are being told by the call agent how to provision the
conversion for a particular RTP stream going to/from a particular endpoint.
The call agents, on the other hand *do* have detailed internal knowledge of
the PSTN and in fact may look like bone-fide SSP's to a carrier's SS7
control network.

> pinning, to use a poor loose analogy)
You can do this with SGCP precisely because you can move RTP streams around
without screwing up the signaling state that the PSTN knows about. I'd claim
that for the particular set of applications this approach is actually
superior to the approach where the gateways hold the PSTN signaling state
because you then can't easily re-target the RTP stream without messing with
the PSTN signaling.

> use access as an ordianry customer
I'm not sure I understand this point. I would expect such gateways to be not
terribly cost effective and possibly illegal in some places. In any event,
as you point out there are existing solutions where you don't need
end-to-end PSTN transparency - SIP and H.323 do these things quite
adeqautely.

> at least one national regulator i can think of would require this....
Where? This is exactly backwards from the U.S. and Canada where the
regulations and tarriffs are  biased to putting the gateways inside reach of
the SS7 cloud.

Dave.

---

From: Bill Manning <[email-masked]>
Date: Wed, 20 May 1998 22:39:16 -0700 (PDT)

> yet make the two domains synonym (using CNAME).

A concern is how one does gateway selection.  "[email-masked]"
is making a couple of assumptions wrt locality of scope.  I posit that
you must use the full e164 number and then you use the nearest gateway,
since you have a fully qualified PSTN "name".

Your off the cuff example has another, perhaps more insidious
problem in that there is a presumption on some ability to have a standard
for user encoding w/in the DNS.  

Still, not a bad first cut.. :)

--bill

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 21 May 1998 08:23:29 +0100

In message <[email-masked]>, "David R. Oran" t

 >>which may shed a different light on this:

thanks! you've cleared up some stuff nicely as per usual

 

 >>ending with a bell, a bellhead approach is a reasonably good impedance match
sure

 >>another taking over in the middle of a call.

aha - ok - thats just fien then - excellent (but perhaps it could be
stated more strongly/clearly i na next version of the spec/draft)

 >>the PSTN and in fact may look like bone-fide SSP's to a carrier's SS7

ok - great....

 >>end-to-end PSTN transparency - SIP and H.323 do these things quite

sure - the goal though is just a more general (even if less efficient)
model

 >>regulations and tarriffs are  biased to putting the gateways inside reach of
 
sorry - i wasnt clear:
the regulator in the UK  would not _stop_ yo uusing this system
but would require the external version inthe previous para
so that non telcos could use telcos nets to offer this service....so
its an extension i'm asking, not a restriction....

albeit, as yo usay, a probably very iniefficient, costly, and in some
places also disallowed one...!

 cheers

   jon

---

From: "Scott Petrack"<[email-masked]>
Date: Sun, 24 May 1998 10:18:59 +0200

From: Scott Petrack@VOCALTEC on 05/24/98 10:18 AM

[Could one of the authors or WG chair or an Area Director please decide
which one of the 50 mailing lists to which this protocol was posted should
be the correct place to discuss this protocol? I am following Jon's lead
and going with confctrl.]

My comments are much less clever than Jon's (which is hardly surprising):

1. Some of the function presented is device control and management, where
the device happens to be a PSTN gateway. Why not just standardize a "PSTN
gateway MIB" and use SNMP? This would be a great acheivement. Much of the
SGCP text present could be immediately refashioned into a very nice
suggestion for a PSTN gateway MIB.
There are many advantages of using SNMP (set, get, traps, etc.) for this
part of the function. (One of the many is that many proprietary protocols
like this already exist between the voice channel banks of a switch and the
SS7 signalling part.

2. Another part of SGCP function is basic third party call control. This
basic stuff can be done today via SIP without controversy.
"Create/Delete/Modify connection" could be immediately handled by INVITE
and BYE (in SIP you modify a connection by resending an INVITE with the
same Call-ID).  (This is very different from the fancy-dancy call control
that requires all those wierdo new SIP headers).

In SGCP  you have Connections and Calls, while in SIP you have Call-IDs and
Session IDs. (so SIP "calls" are basically SGCP  "connections"  and SDP
"sessions" are SGCP "calls").

As an example of the basic similarity of the SIP model and the SGCP model,
here are two extracts:

(SIP)     A multimedia session is a set of multimedia senders and
     receivers and the data streams flowing from senders to receivers.

(SGCP)Endpoints are sources or sinks of data and could be physical or
virtual.
     A point to point connection is an association between two endpoints
with the purpose of transmitting
     data between these endpoints. A multipoint connection is established
by connecting the end point to
     a multipoint session. Connections are grouped in calls

SIP already drives me insane trying to remeber what is a session, call,
etc. I would be happy not to have some new terminology if the SIP
terminology will do.

To summarize this point:  For the sort of "basic third party call control"
presented in SGCP it seems to me that one can use SIP as is. Perhaps some
tiny extensions are needed (rather like the few PINT extensions), but I'd
rather not see a whole new protocol for the special case of a call with one
leg in the PSTN and one leg in the Internet (calls with "one foot in the
grave" ;-))

3. A particular case of a different kind of gateway that we definitely need
a control protocol is an RTP translator or mixer. There are many "PSTN
like" scenarios (such as using RTP proxies to cut off the audio on an IP
phone call whose time has run out, or collecting DTMF digits from the RTP
audio stream, etc....) which will require control of pure IP "gateways."
This is a good example of why I want something a bit more generic than
SGCP. I can get it by using SNMP and SIP/SDP.  (The MIB for a PSTN-RTP
gateway needs to be different that the MIB for an RTP-RTP gateway, but this
only underscores that all the other protocol elements can be common).

4. A last unrelated point: I am a bit worried about the stuff about
instructing the gateway to trap on things like DTMF digits (I mean the
"RequestedEvents and "SignalEvents").  If you are not careful, the call
agent is going to get notified about _every_ DTMF digit of the call. I
don't know if I like my Telco operator listening in every time I send my
voice mail selection or credit card number to the other side.

Sorry if these remarks are a result of my misunderstanding.

Scott

Scott Petrack
+972 52 288 099

---

From: Christian Huitema <[email-masked]>
Date: Sun, 24 May 1998 13:12:08 -0400 (EDT)

Scott,

I posted to exactly one mailing list, confctrl.  Bellcore has set-up
a dedicated mailing list for SGCP discussion, "[email-masked]."
This is a free access, public archive mailing list.
We are just now putting up a web page to organize all that.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 24 May 1998 12:41:24 +0200

Given the proliferation of mailing list from various sponsors of new
protocols, it is easier on us, and better for IETF conceptual coordination
that we stick to the established list - within reason. Can we continue to
discuss the SGCP on this list ?

Thanks, Henry

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Sunday, May 24, 1998 7:12 PM
> To: Scott Petrack; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Simple Gateway Control Protocol -- short first comments
>
>
> Scott,
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 24 May 1998 15:05:33 +0200

The SGCP focuses on the PSTN-IP model and as such, can be quite useful if it
helps with standard mapping of both sides.
Considering however all the other IP telephony options, besides gateways,
making the gateway a component of Internet multimedia seems an attractive
choice. We may after all have IP telephony appliances using any other
Internet access such as xDSL, cable, etc.
A comprehensive model, with gateways as just another component is therefore
to be in mind.

Coming back to the gateway model: It would be useful to have a detailed
mapping to ISDN and SS7 signaling on the PSTN side and a similar mapping to
the IETF conforming side.

Scott has made some good comments to which I would like to add my 2 cents:

> SIP already drives me insane trying to remember what is a session, call,
agree and would like to expand:

The SIP status code definitions and the SGCP overlap to a large degree. Why
not just re-use the SIP status codes, unless they need to be enhanced with
something that is missing ?

Some events listed:

fax tones
modem tones
continuity tones
are too much oriented towards voice-band tones and are hard to be
distinguished by untrained people.
Why not have SIP-like status codes, that can be displayed and also be
associated with a spoken message ?

Can SGCP use the same call ID as in SIP ?

Use URL's as in
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-04.txt ?

The bottom line is, on the "IETF compliant" side, how much can SGCP be
integrated into the existing MMUSIC, PINT and IPTEL family of protocols and
re-use as much from there as possible ?

Life is enough complicated as is...

Thanks, Henry

Henry Sinnreich
MCI, 901 International Parkway
Richardson, Texas 75082
Phone:  (972)498-1223
Fax:    (972)498-1449
for short messages/paging to PIN 1632988 use
http://www.mci.com/connections/interact/sendpage/sendpage.shtml
or page by phone: 1-800-PAGE-MCI/PIN 1632988

---

From: Mark Handley <[email-masked]>
Date: Sun, 24 May 1998 18:15:40 -0400

>discuss the SGCP on this list ?

I have no problem with SGCP being discussed here (on confctrl) - this
doesn't necessarily mean it's an MMUSIC work item.  If the volume of
mail gets excessive we can worry about it then.  However if Christian
prefers it be discussed on a separate list, then so be it.

Cheers,
	Mark

---

From: Chip Sharp <[email-masked]>
Date: Sun, 24 May 1998 21:30:19 -0400

Please keep in mind that SGCP can be applied to other things besides
VoIP (i.e., interface between SS7 Signaling Gateway and a Network
Access Server for Dial access to the Internet).  I'm considering an
applicability statement for this particular application.
Chip

>prefers it be discussed on a separate list, then so be it.
--------------------------------------------------
Chip Sharp			voice: +1 (919) 851-2085 
Cisco Systems		Mgr - Telco Consulting  			
--------------------------------------------------

---

From: "Scott Petrack"<[email-masked]>
Date: Mon, 25 May 1998 21:31:34 +0200

From: Scott Petrack@VOCALTEC on 05/25/98 09:31 PM

I have no doubt that SGCP can be applied to many many situations, including
large access devices. But this only underscores the comments I made
earlier:

My point is that SGCP looks to me like a particular combination of
SIP/H.323, SNMP, and RTP. I think that Christian and Maurice have a very
valid point that a certain set of features were missing from the suite of
protocols we had up to now, and for this reason we need to define standard
MIBs for various gateways, as well as add some more signals to the current
DTMF/FlashHook RTP payload format.  And I agree with Chris that SGCP "can
be applied to other things besides VoIP", exactly like SIP, H.323, SNMP,
and RTP can be used for other things besides VoIP.

But using the simple protocol tools SIP/H.323, SNMP, RTP, etc., just as
they were intended, I can build up exactly the system I need, and this
keeps me from having to do different overlapping protocols for dumb
gateways, for smart gateways, for big networks, for SIP PBXes, for MTAs,
for SIP phones, for access devices, etc.  If I have a dumb gateway then I
only need to support a very dumb subset of SIP/H.323, SNMP, RTP. All this
can be hardcoded very simply and cheaply with off the shelf code and will
fit right into to my current network and network management. And tomorrow,
when I "upgrade" from a simpler device to a smarter one, I won't need to
change the whole protocol on my network. This is really very important. An
example in the PSTN world is the way that some "intelligent" elements like
DTMF and dialing plan decisions are being lowered back into the switch by
many vendors, in order to improve performance. If DTMF is done via SGCP to
the Signalling gateway but by RTP to the switch, it is going to be a real
disaster for the customer when he wants to change.  Of course, no one wants
to lock in a customer to a particular vendor's product, do we ;-)....

 And this is without even mentioning things like pleasure and expense I'm
going to add to do SIP proxy support and SGCP proxy support. (One can hope
that SIP will fold into HTTP within a year or two and then proxy support
will be even cheaper).

Bottom line: the protocol support is already there, we just need to add
some profiles for things like gateway MIBs and signal payload formats in
RTP. This will give us a much more scaleable flexible extensible system
that fits much more easily into existing IP networks.

___A second more rational attempt at my comments of
SGCP________________________

1. Device Management and Configuration should be SNMP, not SGCP.

I agree that we need a way to download things like the "Dialing Map" to a
device, and in general to get and set the configuration of the device.  But
rather than use SGCP, I would much rather define some standard MIBs for the
various gateways, home MTAs, access devices, etc.  This would allow me to
use standard network management tools, would allow vendors to distinguish
themselves beyond the standard features, etc. etc. etc.

2.  SIP or H.323 should be used for CreateConnection, DeleteConnection, and
ModifyConnection.

INVITE (or SETUP in H.323) does CreateConnection and BYE (or
RELEASE_COMPLETE) does DeleteConnection.  ModifyConnection is done by
INVITE (and a payload using the same session ID) (or FACILITY) . A SIP call
is really the same as an SGCP connection, and a SIP session is the same as
an SGCP call. And Henry noticed that somehow the result codes are almost
the same. In SGCP it says explicitly that the naming conventions for
endpoints is beyond the scope of SGCP,  so I don't see why an INVITE with a
From: line of "X35V3+A4/13" and a To: line of "X55V1+B6"  and some SDP
attached is somehow more scaleable than a "CreateConnection" with the exact
same parameters. And with H.323 FastStart I could do exactly the same thing
by replacing "INVITE" with "SETUP" and  BYE with "RELEASE_COMPLETE".

If you want to complain about H.323 and TCP for setup, I'm afraid you only
have a few months to do so. In version 3 (which will almost certainly be
decided _before_  SIP becomes a standard BTW) not only will there be an
option to use UDP, but there will also be an option to use a single TCP
connection for multiple calls between a single gateway. This will give
simple reliability _without_ a new connection per call and with guaranteed
network friendliness in the face of congestion. (believe me, you don't want
to trust those Internet Telephony gateway people to do the right thing when
building a 30,000 port gateway over UDP in the face of congestion ;-)...

This is definitely not overloading the protocol in anyway. SIP is about
creating and maintaining _sessions_. And sessions are associations among
endpoints. That's all.

3. RTP should be used for the signals of RequestedEvents and SignalEvents.

On this one I was not strong enough before. I believe there is actually a
serious flaw in SGCP here. Since SGCP is sent over UDP "for reliability",
messages might arrive out of order. I would be sorry to think what happens
if DTMF tones arrive out of order, etc. Of course if the Dialing Map is
good enough I suppose that all the digits will be collected before they are
sent, but I needn't tell the good people of Bellcore how complicated
dialing plans might be, and if the goal is to get the intelligence out of
the gateway it may be that the CA will need or want to see all the digits
before it knows what to do. So I add to my previous remarks about using RTP
for 'signals' that the RTP sequence number can be used to guarantee message
order.

Scott

[email-masked] on 05/25/98 03:30:19 AM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Scott Petrack)
Subject:  Re: Simple Gateway Control Protocol -- short first comments

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 May 1998 10:23:42 -0400 (EDT)

Scott,

My initial work on the "SGCP" concept started with an investigation of
large scale "trunking" gateways.  These gateways are typically distributed
systems, linking an Internet telephony network to a set of switches.  For
each switch, we have a group of "trunks" (DS0 circuits) controlled by out
of band signalling using ISUP over SS7.  The trunks terminate in a
"trunking gateway."  The out of band signalling is received at an SS7
gateway, which is not necessarily coresident with the trunking gateway --
SS7 interfaces can be quite expensive, so you tend to not have too many of
them.

In that configuration, you have two choices: either somehow relay the
SS7/ISUP messages to the trunking gateways, which can then operate as an
autonomous H.323 or SIP entity, or process the ISUP protocol in a "call
agent" that will then "remote control" the gateways.

Initially, we focused on a "trunking" solution, where VOIP is used as a
simple transport, a replacement for long distance phone transmission. In
this configuration, we found three problems with the "autonomous gateway"
approach:
* relaying SS7 back and forth to gateways can result in long call
  set-up delays,
* protocol translations such as "ISUP to H.323" typically result in
  protocol mismatch and loss of functionality (think for example of
  procedures such as continuity testing, or suspend/resume, which have
  no equivalent in H.323.)
* large trunking gateways (supporting thousands of trunks) are typically
  developed on real time multi-processor systems, which are not
necessarily
  the best platforms to implement complex switching software.
We decided thus to go towards a model where the "telephony switching"
software (SS7, ISUP, AIN, call models, etc) resides in a "call agent" that
will "remote control" the gateways.  When we started designing SGCP, we
did in fact start from SIP. The problem is that SIP is not really designed
to enable remote control.  The typical connection set up, in a remote
control environment, necessitates three exchanges:
1) From CA to Gateway-1: "please give me an RTP/IP address +
configuration,
   that can be used to send packets to circuit number X."
2) From CA to Gateway-2: "please start sending voice from circuit Y into
   packets to that RTP/IP address . Also, give me back the RTP/IP address
   that you will use to receive packets bound to circuit Y."
3) From CA to Gateway-1: "please sending voice from circuit X into
   packets to that RTP/IP address.
The "Invite" request of SIP maps very well to the second transaction.  But
it does not map so well to the first one.  Also, when implementing AIN
services, you quickly observe that you have to slice and dice the call in
more ways than one, and that you need something like a "modify" command to
convey orders such as "stop speaking" or "stop listening" -- actions that
are typical in a remote control environment, but don't make sense in a
protocol designed for autonomous objects such as H.323 or SIP.

So, this is how we started designing SGCP. We analyzed whether we could
use H.323 or SIP, and concluded that in both cases we would need to remove
some of the functions and add other.  Then, we asked software developers
how they would handle a "modified H.323" or a "modified SIP" and they told
us "as an entirely new stack" -- even if you were to reuse the formats,
the logic would have changed and this would be a new development.  Given
this reasoning, we went on to specify a protocol that would be finely
tuned to the "remote control" problem.

Is it perfect?  Hey, we called it version 1.0.  We know that there are
areas of improvement.  For example, your suggestion of aligning response
codes with SIP (and HTTP) looks like something we should follow on.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 May 1998 10:26:45 -0400 (EDT)

On May 24,  6:15pm, Mark Handley wrote:
> doesn't necessarily mean it's an MMUSIC work item.

Mark,

I set up another list because I did not want to hijack the MMUSIC list.
 The scope of SGCP is somewhat narrower than Conference Control -- and I
am certainly not suggesting to add a work item to the MMUSIC charter...

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 26 May 1998 12:06:06 -0400

> fit right into to my current network and network management.

This is an assertion I would like backed up with a proposal, especially one
that allows the full range of services to be delivered.

> And tomorrow,
> change the whole protocol on my network. This is really very important.

Yes, anyone wanting a smart-device-based call control protocol would clearly
not opt for SGCP. SGCP is clearly a "niche" protocol not meant to displace,
or even overlap with call control protocols.

> An
Detection of DTMF is one thing; interpretation of digits is another. You
want to move detection/generation out to the edge because that's where the
DSPs are. Then you need a protocol to tightly control when detection is
enabled so you can manage  the end-to-end vs. incoming edge interpretation
ambiguities. SGCP is in fact the first protocol I've seen stupid enough to
get this right.

> that SIP will fold into HTTP within a year or two and then proxy support
I cannot for the life of me see why one would ever need an SGCP proxy - it's
a stupid master-slave control protocol.

> that fits much more easily into existing IP networks.
Well, we certainly need these things anyway - so have at it!

> themselves beyond the standard features, etc. etc. etc.
Ah, you missed the one critical "gestalt" of what dialing maps and
event-action maps do in SGCP! They can be changed SYNCHRONOUSLY through the
operation of the  protocol. This allows nice tricks like context-sensitive
hook-flash behavior without adding to the feature-interaction problems
already present in existing voice services, and allowing incremental dialed
digit interpretation without having to send EVERY digit to the call control
server immediately. There are a bunch of other uses, which I'll leave your
fertile imagination.

> 2.  SIP or H.323 should be used for CreateConnection,
I think you are misled by the SGCP terminaology. SGCP "connections" are
single-ended, not two ended. They only talk about how to bind an RTP stream
to an endpoint, not anything about synchronizing state with "the other end".

> INVITE (and a payload using the same session ID) (or FACILITY) .
These are peer-to-peer, not master-slave.

> A SIP call
But it doesn't solve the problem of 30,000 single port gateways...
And, from this description the amount of implementation work is at least as
great as implementing SGCP; possibly more so because of the combinatorics. I
really see these as filling different roles.

> if DTMF tones arrive out of order, etc.
SGCP is stop-and-wait when reporting events. This can't happen.

> Of course if the Dialing Map is
As I mentioned above, I think you've missed the purpose of SGCP's
event-action maps here. That's not to say I don't think a way of encoding
signals in RTP streams is a bad idea. As you know, I've been a strong
proponent of doing this to cover all the cases where edge-based
interpretation is undesirable.

Dave.

---

From: Pete Cordell <[email-masked]>
Date: Thu, 4 Jun 1998 18:02:16 +0100

I'm not sure I understand all that is being said here, but it is my
understanding that in the switched word it is the final exchange in the
link that applies the ringing tone.  

Therefore, there is a big difference between 100 Trying and 180 Ringing.

In the POTS world my experience is that you are greeted with deafening
silence until the far end actually starts ringing.  

In the ISDN world 100 Trying maps to Call Proceeding.  This usually
isn't fed back to the user directly, but is important to the protocol
engine to know that the remote end is actually alive.  Getting 100
Trying also allows the UI to know that it is worth having the user hang
on (i.e. it can give an unable to connect notification if it doesn't get
something back from the far end in a suitable time).  

180 Ringing maps to Alerting in the ISDN case.  Because you shouldn't
send back ringing before the far end really is ringing this is obviously
an important message.

So the point of all this is, the switched network can distinguish
between these two cases.  

And now to the point of writing this, because you can't send 180 Ringing
back straight away in all cases, and the transition to the far-end
ringing is an important event, would it be possible for the end that
signals the ringing to somehow request that an acknowledge (ACK) method
be invoked so that the calling person knows that the phone is ringing. 
This also seems important in the case where you have the re-direct (3xx
responses) stuff, because you don't want the user hanging on the line
waiting for his/her terminal to send another INVITE message just because
the re-direct got lost.  i.e. 200 OK doesn't seem to be the only event
that has benefit in being acknowledged.

Regards,

Pete

=================================
Pete Cordell
BT Labs
E-Mail: [email-masked]
Tel: +44 1473 646436
Fax: +44 1473 645499
-------------------------------------------------------------
Notice:  This contribution is the personal view of the author and 
does not necessarily reflect the technical nor commercial direction 
of British Telecommunications plc.
=================================

>----------
>From: 	Henning Schulzrinne[SMTP:[email-masked]]
>Sent: 	04 June 1998 15:07
>To: 	Scott Petrack
>Cc: 	[email-masked]; [email-masked];
>[email-masked]
>Subject: 	Re: SIP Provisional Responses
>
>Scott Petrack wrote:
>> 
>> From: Scott Petrack@VOCALTEC on 05/22/98 04:51 PM
>> 
>> [... Problem that a user agent server might need to send first a 100 Trying
>> response and then a 180 Ringing response...]
>> 
>> >
>> >2) The server can retransmit 1xx responses periodically.
>> >
>> >For non-technical users, the difference between Trying and Ringing isn't
>> >all that great - certainly not something that the standard telephone
>> >tones (ring-back in either case) could express.
>> 
>> If the server first responds "100 Trying" then if later it sends "180
>> Ringing" this is not a _retransmit_, is it? It is a change in the
>> provisional response. If this is to be allowed it needs to be explicitly
>> stated. I thought that a retransmitted response must an exact retransmit of
>> the original response.
>
>There can be several 1xx responses, either the same ("retransmit") or
>different. This is the same as in HTTP.
>
>> 
>> When client retransmits the INVITE the server can't give a different
>> response.
>
>Yes, it can: If I send an INVITE, the phone rings, but the 100/180 gets
>lost. [The callee can't know that the 1xx got lost.] The caller
>retransmits just as the callee picks up. Naturally, the server returns
>a
>200, not a 1xx response at that point.
>
>> 
>> I think that allowing the server to "retransmit" a changed provisional
>> response would be very useful, but some clear rules need to be written. For
>> example, I wouldn't want a "Ringing" to change into a "Trying".
>
>The state diagram always allowed this: see the transition "status
>change/1xx". However, guaranteeing some ordering is very difficult
>(and,
>I believe, counterproductive) since they may be generated by different
>pieces of equipment along the way. The client should simply report the
>progress, with the expectation that in almost all circumstances the
>sequence will make sense to the user, but without relying on a strict
>ordering 100-180-182 or similar. (As a practical matter, enforcing
>monotonicity would make assignment of codes rather difficult.)
>
>> 
>> Perhaps we can say that the higher the number of the provisional response
>> code, the farther along the server has gone. (i.e. "180 Ringing" is further
>> along the resolution process than "100 Trying"). And then the standard can
>> allow a lower provisional response to be replaced by a higher one. (Of
>> course we will have to dole out the numbers for responses quite carefully,
>> but this is not too hard).
>> 
>> BTW, "for non-technical users", my cellphone first emits little clicks when
>> it is trying to find the callee, and then these clicks change into ringback
>> to signal that the phone is ringing. (We do this in the VocalTec PSTN
>> gateway as well). And in fact there are lousy cell phone services that
>> actually start by faking Ring back and then turn into Busy tone if the
>> callee is actually busy. I find the former is very useful, and the latter
>> extremely annoying.
>
>Unfortunately, this is to some extent unavoidable if you have a device
>on one side that has a very limited repertoire of user feedback (fast
>busy, ringback and busy). How else would you handle the situation that
>the callee gets the call (ringback) and then decides to refuse the
>call?
>You'd probably want a voice announcement (assuming it's in a language
>you understand - I rather have a busy tone than a message in
>Portugese),
>but this behavior doesn't exist on the SS7 side.
>
>Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 04 Jun 1998 20:39:28 -0400

> send back ringing before the far end really is ringing this is obviously

This is pretty much the ISDN mapping you'll find on my SIP slides.

> that has benefit in being acknowledged.

All final responses are already being acknowledged via ACK, including
3xx and 4xx. Things just don't work well if you don't do that.

ACKing provisional responses gets messy: Example

C->S INVITE
S->C 180 Ringing (please ACK)
S->C 200 OK (user picked up)
C->S ACK

is the last line the ACK for the 180 or for the 200? Should the callee
worry about getting the 180 ACKed if it has already sent a 200? (Seems
kind of pointless.)

None of these problems are unsolvable - just add one more identifier and
appropriate logic ("mark the ACK as being for the 180; if you get a new
status code, cease retransmitting the old"). It also adds more
substantial complication for proxies. Given the marginal functionality
and the ability to have the server retransmit 180 a few times if it
really worries about this, this seems like a something that should be
deferred and get a feature option, rather than a basespec for the first
round, as it does complicate the client and server with more states. If
you want every provisional response message to be delivered, just use
SIP over TCP :-)

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Jun 1998 16:20:54 -0400 (EDT)

We should remeber that, in most cases, the time elapased between the
"progress" and the "ringing" event is actually quite small.  So, rather
than acking provisional answers, you can do the following:

1) Send INVITE.  Start timer, value of timer scales as "1 RTT + some
margin".

2) If you receive "100" before timer breaks, reset timer value to 
"RTT+Margin" or "500 ms", whichever is larger.

3) If timer breaks, repeat INVITE. Increase value of timer, for exponential 
back-off. Restart timer.

4) When 180 comes, set state to "rnging".  Doi whatever it takes to start
ringing indication.  Reset timer to some very large value.

5) When 200 comes, call is established. Stop all timers.  Send ACK. Place
the circuit in fll duplex mode, etc.

6) If 200 is received in established mode, repeat ACK.

7) If long timer breaks before 200 comes, call was not answered. Send 
BYE, etc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Jun 1998 17:27:09 -0400

> than acking provisional answers, you can do the following:

You describe the current spec pretty well :-)

> 1) Send INVITE.  Start timer, value of timer scales as "1 RTT + some

We typically wouldn't know RTT at this point [unless you call often and
can cache the results of previous calls], so I'm assuming a constant (T1
= 1s) governed by the fact that a RTT above 500 ms is going to make
voice conversation difficult. 

> 3) If timer breaks, repeat INVITE. Increase value of timer, for exponential

We are currently using a constant timer (but bound the number of
retransmissions to 20), under the assumption that the useful variability
in RTT is small and the number of measurement samples too small to get
too sophisticated about this. The experience with exponential increase
in TCP in an interactive environment (web page retrieval) has been less
than great: people simply get impatient, hit "stop" (generating a RST)
and then "reload". I don't have a strong opinion either way, but a short
call setup delay if there's one packet loss is very useful (TCP fails in
that regard). 

> ringing indication.  Reset timer to some very large value.

Currently, T3 = 30 seconds.