Subject: RE: question on OSP

From: Henry Sinnreich <[email-masked]>
Date: Wed, 01 Dec 1999 11:32:11 -0600

Page 50 shows the "ETSI Protocol Stack". There is no such thing. These (IP,
TCP, SSL/TLS, HTTP) ) are all IETF protocols and the IETF has the
intellectual property rights and change control. I believe the same applies
to W3C web protocols, XML, etc.

Henry

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Phil
> Mutooni
> Sent: Tuesday, November 30, 1999 4:42 PM
> To: [email-masked]'; 'Stephen Thomas'
> Cc: 'Jonathan Rosenberg'; 'Gerry Reilly'; 'IPTEL IETF Mailing List';
> 'Matt Squire'
> Subject: RE: question on OSP
>
>
> Attached is a paper that I wrote early this year that compares
> the pros and
> cons of
> the OSP vs the ITU-T H.225 Annex G. It appeared in the June issue
> of Billing
> World.
>
> Philip Mutooni
> iBasis, Inc.
> w: http://www.ibasis.net
> t: 781.505.7523
> f: 781.505.7300
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, November 30, 1999 6:12 AM
> To: Stephen Thomas
> Cc: Jonathan Rosenberg; Gerry Reilly; IPTEL IETF Mailing List; Matt
> Squire
> Subject: Re: question on OSP
>
>
>
>
> The convergence between OSP v2 and H.225 v3 Annex G doesn't
> appear obvious,
> there seems some major differences between the two approaches. Below is a
> rough comparison I sketched.
>
> System Model
> ---------------------
> - Different administrative domain organisations are supported in the H.225
> Annex G, such as: Hierarchical, Distributed or Full mesh,
> ClearingHouse,...organisation. H.225 Annex G doesn't mandate a specific
> organisation among, or within, administrative
> domains. An architecture with Border Elements (BEs) for communication
> between administrative domains is defined. The protocol is fundamentally
> peer to peer.
>
> - OSP seems to be LIMITED to the centralised ClearingHouse administrative
> domain organisation. The architecture is fundamentally
> client-server. There
> appear NO WAY FOR direct relationships  between administrative domains
> (hiearchical, distributed or full
> meshed...).
>
> Message definition, format and encoding
> ------------------------------------------------------------
> Message fields and headers are quite different in both cases. The messages
> are encoded using ASN.1 for the H.225 Annex G, while OSP exchanges textual
> information using the XML for message structuring.
>
> The set of message types are also different in both cases. Today
> the current
> scope of OSP is inter-Domain pricing, authorization and usage
> exchange, and
> not inter-domain call routing.
>
>
> P.S. the  H.225 Annex G specifications can be found at the following URLs
>  ftp://standard.pictel.com/avc-site/9910_Red/   the name of the
> specification is TD-027.
>
>
> Philippe Terrien
> Alcatel SRD
> 10 rue Latecoere BP 57
> 78141 Velizy Cedex  France
>
>
>
>
>
> "Stephen Thomas" <[email-masked]> on 29/11/99 20:17:44
>
>
>
>  To:      Philippe TERRIEN/FR/ALCATEL@ALCATEL, "Jonathan
>           Rosenberg" <[email-masked]>
>
>  cc:      "Gerry Reilly" <[email-masked]>,
>           "IPTEL IETF Mailing List"
>           <[email-masked]>, "Matt Squire"
>           <[email-masked]>
>
>
>
>  Subject: Re: new subscriber question on OSP
>
>
>
>
>
> Although there is some overlap between Annex G and OSP, there are
> some important philosophical differences. Annex G is, by it's
> very definition, an extension of the H.323 protocol suite. Like
> the rest of H.323, Annex G is fundamentally a peer-to-peer
> protocol. OSP, on the other hand, is independent of call signaling
> protocols. It is also architected as a client-server protocol.
> In some ways, OSP is quite close to SIP. It is text encoded
> (actually XML) and relies on standard Internet protocols (HTTP
> and TLS) for transport. A more detailed analysis would also show
> some functionality differences, but they are relatively modest.
>
> As for status, OSP was approved as an ETSI Technical Specification
> in December 1998. ETSI standards are available to the public at no
> charge, though ETSI does require you to register before downloading
> a final copy. (Thus I cannot provide a simple URL.) The ETSI
> web site is www.etsi.org.
>
> Stephen
>
>
>
> ----- Original Message -----
> From: <[email-masked]>
> To: "Jonathan Rosenberg" <[email-masked]>
> Cc: "Stephen Thomas" <[email-masked]>; "Gerry Reilly"
> <[email-masked]>; "IPTEL IETF Mailing List"
> <[email-masked]>; "Matt Squire"
> <[email-masked]>
> Sent: 25 November 1999 6:17 AM
> Subject: Re: new subscriber question on OSP
> |
> |
> | I have an additional question.
> |
> | How OSP is positionned, compared with the ITU-T H.225 Annex G standard
> which provides an architecture, protocol and operations to solve
> inter-domain routing ? My feeling is that they are competitors.
> | What is the rationale, scope, and current status of OSP ?
> |
> | Attached below the H.225 annex G for those who are not aware o this
> standard
> | (See attached file: TD-27.zip)
> |
> |
> ||
> | Jonathan Rosenberg <[email-masked]> on 23/11/99 22:35:29
> |
> ||  To:      Stephen Thomas <[email-masked]>
> |
> |  cc:      Gerry Reilly <[email-masked]>, IPTEL
> |           IETF Mailing List
> |           <[email-masked]>, Matt Squire
> |           <[email-masked]>(bcc: Philippe
> |           TERRIEN/FR/ALCATEL)
> |
> |
> |
> |  Subject: Re: new subscriber question on OSP
> ||
> |
> | Thanks for the clarification, Stephen.
> |
> | Based on this, I see their roles as complementary. An OSP server needs
> | some way to build up the routing table it uses to answer OSP queries.
> | TRIP fits this need perfectly. In fact, OSP is effectively what is
> | called "the front end" in the TRIP framework document; its the way by
> | which TRIP databases are accessed. OSP is a query protocol, and TRIP is
> | more like a routing protocol.
> |
> | -Jonathan R.
> |
> | Stephen Thomas wrote:
> | >
> | > Matt has some of the essentials exactly right, but OSP
> | > can (optionally) provide call routing information as
> | > well as authorization. A typical application would
> | > work something like this:
> | >
> | >   Server X in domain 1 needs to locate a peer (e.g.
> | >     a terminating gateway to complete a call to the
> | >     PSTN).
> | >
> | >   Server X uses OSP (as a client) to query a third
> | >     party for the call routing and authorization
> | >     information.
> | >
> | >   Server X recieves the IP address of Server Y and
> | >     an authorization token that will grant it access
> | >     to the peer (sort of like Kerberos).
> | >
> | >   Server X sets up a the call to server Y (e.g. SIP
> | >     INVITE), including the authorization token
> | >     (e.g. as per draft-thomas-mime-osp-token-00.txt).
> | >
> | >   After the call is released, servers X and Y use OSP
> | >     to report usage information.
> | >
> | > To Matt's specific questions:
> | >
> | >   OSP Servers can route based on E.164 numbers as well as other
> | >     identifiers (e.g. email addresses).
> | >
> | >   Routing policies and route selection are up to the OSP
> | >     Server.
> | >
> | > At a high enough level, there is overlap between TRIP and
> | > OSP. OSP does things other than call routing as well, but
> | > where the overlap exists, I would characterize the
> | > difference as primarily one of philosophy. TRIP is
> | > a distributed protocol like IP routing protocols (BGP,
> | > and also RIP, OSPF, ...). OSP is a hierarchical protocol
> | > like directory service protocols (DNS, LDAP, ...)
> | >
> | > Stephen
> | >
> | > ----- Original Message -----
> | > From: "Matt Squire" <[email-masked]>
> | > To: "Gerry Reilly" <[email-masked]>;
> | > <[email-masked]>
> | > Sent: 23 November 1999 10:32 AM
> | > Subject: Re: new subscriber question on OSP
> | >
> | > |
> | > | My understanding of OSP was that it was basically an
> authorization and
> | > | accounting protocol - server X in domain 1 can request access to
> server Y
> | > | in domain 2, transmit usage records, etc.  I know its a bit more
> | > | complicated than this, but this is my one sentence summary.  OSP is,
> | > | generally, much more comparable to the work going on in AAA
> than here.
> I
> | > | didn't think it was designed to route signalling messages.
> | > |
> | > | So I'm not aware of the route selection capabilities of OSP, in
> particular
> | > | whether it makes routing decisions based upon E164 numbers,
> what kind
> of
> | > | routing policies and route selection it supports, etc.  To
> the extent
> that
> | > | OSP does these things, there may indeed be overlap.  Just don't know
> | > enough
> | > | about OSP to answer definitively.
> | > |
> | > |
> | > | At 03:11 PM 11/22/99 +0000, Gerry Reilly wrote:
> | > | >Hi
> | > | >
> | > | >Please forgive this newbee question.
> | > | >
> | > | >I've been reading through the TBGP, SCSP & TRIP drafts with great
> | > | >interest:-) As a relative newcomer to the VoIP area, I'm
> not entirely
> | > | >clear as to where the Open Settlements Protocol fits into
> the model,
> if
> | > at
> | > | >all.
> | > | >
> | > | >OSP seems to claim to be designed for inter-domain route
> selection as
> | > well
> | > | >as facilitating billing.
> | > | >Would this protocol supplement TRIP, or am I missing the point?
> | > | >
> | > | >Kind Regards
> | > | >
> | > | >Gerry Reilly
> | > | >
> | > | >
> | > | >
> | > | >---------
> | > | >This message came from the IETF IPTEL Working Group Mailing List.
> | > | >
> | > |
> | > | Matt Squire
> | > | Nortel Networks
> | > | innovations.lab
> | > | [email-masked]
> | > | (919)992-9048
> | > |
> | > | ---------
> | > | This message came from the IETF IPTEL Working Group Mailing List.
> | > |
> | >
> | > ---------
> | > This message came from the IETF IPTEL Working Group Mailing List.
> |
> | --
> | Jonathan D. Rosenberg                       200 Executive Drive
> | Chief Scientist                             Suite 120
> | dynamicsoft                                 West Orange, NJ 07052
> | [email-masked]                     FAX:   (732) 741-4778
> | http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> | http://www.dynamicsoft.com
> |
> | ---------
> | This message came from the IETF IPTEL Working Group Mailing List.
> |---------
> This message came from the IETF IPTEL Working Group Mailing List.
>
>
>
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
>
>

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Phil Mutooni <[email-masked]>
Date: Wed, 1 Dec 1999 17:44:38 -0500

What you have pointed out is correct - there is a factual error in the
titling of that text box - this was an addition by the technical editors at 
the magazine.

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Wednesday, December 01, 1999 12:32 PM
To: Phil Mutooni; [email-masked]; 'Stephen Thomas'
Cc: 'Jonathan Rosenberg'; 'Gerry Reilly'; 'IPTEL IETF Mailing List';
'Matt Squire'

Henry

---------