Subject: [Fwd: Re: What is the view towards H.323?]

From: Eirik Maus <[email-masked]>
Date: Thu, 12 Nov 1998 09:41:30 +0100

Subject: Re: What is the view towards H.323?
From: Eirik Maus <[email-masked]>
To: Alok Mittal <[email-masked]>
Date: Mon, 09 Nov 1998 17:38:29 +0100

Hi

Alok Mittal wrote:
> 
>  What I am interested in is the view members of this list to the picture that
>  might evolve in relation to SIP and h.323.
>
> 1. SIP has conceded to H.323

The developers of the specification will have to speak for themselves. 
I do, however, encourage them to continue working on SIP, as there
are a lot of reasons to create a better standard than H.323. 
Your view no. 2 (below), for instance, is one of them.
Most of the critizism you may find under Schultzrinne's 
SIP-pages still hold. 
The H.323 has serious flaws, even if the most acute 'bugs' will
be corrected by copying solutions from SIP.
The fact that H.323 is based on ASN.1 is by itself a good reason to
co create something better suited for computer programming. 

> 2. SIP and H.323 will converge, probably in H.323v3

I doubt that. see below.

> 3. SIP and H.323 interoperate -- Session Initiation in SIP and then H.323 takes over

H.323 is allready doing SIP-style initiation through Jumbograms (fast
setup) and 
UDP (Vocaltec suggestion). Most of the information exchanged is the same
as
the information exchanged during SIP-setup. It is thus not unreasonable
to say
that this has allready happened. The only difference is that the
signalling is
based on telecommunications-style signalling (Q.something/H.something
defined in ASN.1).
I think this difference is important to the major actors in this game:
The major telcos and suppliers like Ericsson, Nokia etc. 
They have invested huge amounts of money in developing products based on
these standards. 
Giving up  telecom standards as basis for the services will make it very
hard
to profit on these investments. They are watching the SIP-scene because
they are afraid
they might 'miss the train', just like Microsoft missed the internet
train. 
They do not, however, want SIP to be 'THE train', as this will make it
necessary to 
give up investments and start developing SIP-technology. 

Another reason is based on the logic of Telecom-standards. 
H.323 (and other) are buildt upon the assumption that it is the
responsibility (and profit-opportunity) of the access (or service-)
provider
to build and set up supplementary services. 
This is an important source of income for the telcos, and is built on
top of equipment delivered by the telco suppliers. 
SIP is more computer- and end-system-centric. Many supplementary
services will be implemented by student and small softeware companies.
These will run on ordinary computers in the user's office (or similar). 
The telcos and telco suppliers are watching SIP becacuse they are
1) afraid SIP might catch on. After all it is far better than H.323v1. 
2) afraid they might miss it if (God forbid) SIP catches on.

Running SIP as an inter-gateway protocol does not seem to dangerous as
people still are forced to use equipment based on "their" standards,
following
"their" logic. After all, something had to be done about the name
resolution 
"solution" found in H.323, and the SIP solution is good. 
Accepting SIP on user level opens up the posibility of students,
mini-firms etc
to become major suppliers of supplementary services software, taking
over
important segments of their market. 
No major firm wants to pave the way for the next Microsoft in (what used
to be,
one might add) their business domain. 

> 4. Interworking Gateways for SIP and H.323 -- here, however I have not seen
>     an argument which says *where* SIP makes more sense than H.323 and vice
>     versa (if one was absolutely better than the other, there wouldn't be a need for GW).

I've tried to sketch the message sequences necessary to provide
interoperation, 
but this is very difficult, especially if one wants to preserve 
backwards compatibility with pre fast-start h.323. 
This is due to:
- lack of expressiveness. Some H.245 media preferences are not
  possible to express using SDP. SDP is siply not strong enough.
  H.323, however, does not allow the equivalent of "Contact:" to
  contain more than one address, and it is difficult to change and still
  preserve backward compatibility. The fact that a name only has one
single
  address at a given instant is an underlying fact in the h.323 and its
related
  standards. The fact that there exist related standards, and the major
players
  have invested money developing for these standards, makes it unlikely
that
  extensions that are incompatible will be accepted. 

- information is exchanged in different order. SIP cannot open a
connection
  unless all media information is agreed upon. Basic H.323 will not
exchange
  this information until after the connection is established. 
  This problem is, however, the most easy to overcome. 

- Conference control is difficult to translate. There is no conference
control
  in SIP. It is, however, possible to build programs acting as
centralized
  conference-control as proxies. But how should the gateway handle 
  conference join invitations between SIP clients? This is strictly
illegal in H.323, 
  but the basis of conferencing in SIP. 

I would say that SIP generally makes more sense than H.323, but since
there is a 
major backing of H.323 by the leading providers of telecom, H.323 will
have
a lead in the beginning. 
The most killing fact is, of course, that H.323 has billing in place, 
whereas SIP does not. No service provider can live on delivering
free services, making H.323 the only choice. 
The billing service of one major player I know of is based on 
gatekeeper routed signalling, and the local gatekeeper generating
billing-events. It is a trivial task to build this in SIP, 
using a local proxy as "gatekeeper" and a firewall to prevent 
external calls not signalled through the proxy. 
But nobody seems to focus on other reasons than technology 
to establish and use SIP. The market players, of course, don't give a
damn
about the technology as long as they can earn money. 
And currently SIP seems more like a threat than a possibility
to do just that. 

b.r

Eirik Maus
Norwegian Computing Center*

* disclaimer: speeking only for myself

---

From: Mark Handley <[email-masked]>
Date: Thu, 12 Nov 1998 10:04:01 -0500

>are a lot of reasons to create a better standard than H.323. 

I think I speak for all the SIP authors when I say we have every
intention of continuing working on SIP.

The market will decide what solutions, hybrid or otherwise, actually
end up being used.  If a protocol can't do what's required of it, it
will either get fixed or die.  

Cheers,
	Mark

---

From: Ping Pan <[email-masked]>
Date: Fri, 13 Nov 1998 05:50:19 +0800

> external calls not signalled through the proxy.

Eirik,

Nice comment! As for a potential billing support in SIP, here is a draft that uses Diameter to
keep track of accounting data for SIP sessions:

ftp://ftp.ietf.org/internet-drafts/draft-pan-diameter-sip-00.txt

Please take a look. It still needs a lot work.

One more thing, I thought that one of the major reasons that killed the ATM-everywhere
pipedream was due to its telco-style signaling protocols (Q.something....) thankfully. Cannot
people learn from the lesson? Sticking with something like H.323 may be nice initially. But as
more people start to hacking code on their PC's, it won't be up to telco people to tell the
users what to do with their IP phones in the future.

2 cents,

--
Ping Pan

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 12 Nov 1998 16:31:11 -0600

Mark wrote:
>ide what solutions, hybrid or otherwise, actually

It took a relative simple SIP server implementation to show, that from the
perspective of a service provider, SIP can support all the existing PSTN
calling features we tried. The main attraction of SIP however is in
providing mixt web and telephony services.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark Handley
> Sent: Thursday, November 12, 1998 9:04 AM
> To: Eirik Maus
> Cc: [email-masked]
> Subject: Re: [Fwd: Re: What is the view towards H.323?]
>
>
>
> >>  What I am interested in is the view members of this list to
> the picture tha
> >t

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 13 Nov 1998 14:35:13 -0600

> Ping Pan wrote:

> ftp://ftp.ietf.org/internet-drafts/draft-pan-diameter-sip-00.txt

Why can't service providers make a living providing (at a fixed cost)
access to "free services"? Do carriers do per HTTP-transfer billing now?
How much should they charge for an email? For a call, what parameters
might be used? Bandwidth, duration, distance -- the Big Factors of the
POTS bill -- are not issues that SIP is concerned with.

The real question: Is it even reasonable to presume billing for a
best-effort IP service betwen two nodes? I suggest not. If carriers were
to try, the end-users would just tunnel around the billable parts . . .

I suggest telco-style per-call billing driven completely from SIP is
therefore pointless. But the costs of some calls are incremental -- how
to recover them and make a reasonable presentation of it?

Perhaps the appropriate elements to support in a billing model are the
"value adds". These might include:

At the network level, bandwidth reserved for the call, the duration for
which it is reserved, and other quality issues. These matters are not
properly the province of SIP, but are handled through RSVP and
Differentiated Services models. Some sort of admission control to the
bandwidth management function is required, and that might be expected to
generate accounting records. It would seem that this is a basic AAA
function and that it requires some sort of business relationship between
the caller and the carrier or the callee and the carrier (or both). Of
course, in the interim, it can be handled using log files.

At the bearer channel (call) level, going through a gateway that
connects the SIP caller to the GSTN is certainly a chargeable feature --
after all, the call IS going to generate some sort of standard switch
CDR once it hits the egress switch. For this, of course, we need AAA --
again, with a business relationship. The same applies to other gateway
functions, such as firewall traversal. One could of course bill from
those CDRs. . .

Directory operations, such as SIP proxy lookups, might be chargeable
features. Of course, this can be performed using SIP-server logs, but
centralizing in a AAA system might be handy. The same applies to
manipulations of the directory, such as customer profile management.
Again, the log files could tell you everything needed to bill, but an
AAA approach would be nicer.

Other sorts of media operations, such as retrieving or storing voice
mail, transcoding a stream, etc. might be chargeable and require the
same basic AAA functions. These operations all produce log files . . .

Given all this, I suggest that while smooth AAA integration would be
helpful in building a seamless carrier delivery environment, that its
current lack does not preclude delivery of SIP services by a carrier.

With respect to "draft-pan-diameter-sip-00.txt" -- it's a start. Is it
really necessary to add DIAMETER into SIP, or could we just let each of
the "value add" function providers apply DIAMETER on its own, using the
SIP mechanisms for authentication source, then recording the transaction
using the "accounting" parts?

--
Dean Willis

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Nov 1998 17:20:40 -0500

> current lack does not preclude delivery of SIP services by a carrier.

Well said. I agree on all points.

> using the "accounting" parts?

I don't think this draft is proposing to add DIAMETER into SIP, but
rather a way to add SIP authorization to DIAMETER (big difference).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Ping Pan <[email-masked]>
Date: Sat, 14 Nov 1998 07:38:16 +0800

> to try, the end-users would just tunnel around the billable parts . . .

Dean,

SIP is a control level protocol. To deliver real-time voice over the
Internet, we need to do more at data path. IMHO, it'll be very unlikely that
real-time voice traffic should be treated as best-effort in the future.
Rather, at network edge, voice data needs to be aggregated into DiffServ
trunks, and be treated as either Assured Service packets with high priority
or simply Expedited Forwarding packets. Treating voice better than
best-effort means allocating more network resource, and means more cost to
the ISP's. Given that's what I have in mind, here is the question: how can
regional IP-phone providers keeping track of the user's phone calls?

The SIP-DIAMETER draft is designed to allow IP-telephony providers to
interface with SIP and keep track of all SIP sessions for a) admission
control, and 2) accounting. The draft does not say anything about how to do
billing, which can be specific for each service provider. Providers should
simply use the accounting information for whatever the billing models they
like.

There is another piece of work that we didn't specify in the draft, that is,
after a SIP session is granted, how can the service provider pin-down a data
path for two involved SIP parties? We're currently working on that.

> course, in the interim, it can be handled using log files.

Again, interfacing SIP, RSVP and DiffServ may be tricky here: SIP messages
may go through a completely different path from what actual data (managed
via RSVP, RTP, etc.) may traverse. For the complete admission control and
bandwidth management package, we need to combine SIP-DIAMETER information
with RAP (RSVP Admission Control) server information together. (It will be
nice if you can all use the same protocol, :-) but this is another story.)

> AAA approach would be nicer.

Lost me here. I thought that SIP directory lookup takes place prior to the
actual SIP invitation process. The admission control and accounting apply
only during and after SIP invitation. Also directory lookup should be free
(unless you want to charge DNS operation in the internet).

> same basic AAA functions. These operations all produce log files . . .

Not really. If data is not real-time, send them over the net as best-effort.
No need for RSVP, DiffServ and per-session accounting.

Regards,

--
Ping Pan

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 16 Nov 1998 01:07:17 -0600

Excellent discussion!

Ping Pan wrote:
> Dean Willis wrote
. . .
> Rather, at network edge, voice data needs to be aggregated
> into DiffServ . . .

Exactly my point. They (carriers) can track the bandwidth reservations
at the policy edge, but can't track the Internet phone calls. The
carriers DON'T REALLY KNOW that a stream is a phone call. If the network
is good enough, I can tunnel RTP through DNS . . . but the carriers MUST
KNOW about a bandwidth reservation in order to suport adequate QoS.
Don't care if sumebody plays a real time game or does voice chat -- do
care that they need 56kbps assured delivery for 20 minutes between nodes
in locations A and B. Whole different story if a GSTN gateway is
handling a call leg . . .

> path for two involved SIP parties? We're currently working on that.

Again, the carrier doesn't really care about the call setup-- the RTP
nodes just request bandwidth reservations to the other end.  The data
path is not nailed up -- the actual network topology may change during
the call. The only requirement is that the quality contract be
maintained. The QoS channel is the interesting part for the carrier. SIP
was just the dating service to bring them together, and unless a SIP
endpoint (or midpoint) happens to be a value-added service provided by
the carrier, the fact that two Internet nodes exchanged best-effort
packets is not worth tracking.

> nice if you can all use the same protocol, :-) but this is

Don't tie them together that way. Really, what I'm fishing for here is a
way to completely separate the media stream from the call control. I
should be able to use vendor A's call control (maybe SIP, maybe H.323,
maybe something else) with vendor B's (RTP or otherwise) bearer channel
application (which makes its own RAP request for QoS) with nothing but a
simple exec/return interface between the two, and enough information in
a config file for SIP to be able to do session description and
capability negotiation.

> > manipulations of the directory, such as customer profile managemnt.

Local carriers charge for yellow pages and for directory services
information. There may well be an Internet carrier requirement to
account for this service category. This is especially true if one
extends the model to richer call control services: access filtering
(time, source, or identity based), follow-me services, user profiling,
profile management, and so on. Perhaps an end user would like to KNOW
how many calls were rejected by his junk-call SPAM filter this month.
Advertisers might need to know EXACTLY how many times a particular alias
used in an ad campaign is resolved and know what the distribution of
those resolutions was in each time zone reletive to deliveries of
television ads. For managing user profiles, we need to know when access
are being made and where they are coming from to handle capacity
planning issues. In general, directory access accounting is a key area
for telephony metrics.

> No need for RSVP, DiffServ and per-session accounting.

True in general, but there may be more real-time data than you think.

Retreiving and storing voice mail are real-time operations assuming that
the media server is network-located and remotely (RTSP) controlled. QoS
and accounting are definitely called for. Example: Provide web interface
to voice mail for roaming users, messages presented as RTP streams
controlled via RTSP. Accounting is really critical if the services in
question are provided by a third party on some kind of piece-work basis.
Transcoding, such as in the event of a low-bitrate client participating
a in a high bitrate conference through the use of an intermediary
server, is also a real-time service. It is especially interesting as it
involves multiple call legs with potentially disparate QoS requirements.

--
Dean