Subject: Re: [SPIRITS] Some Thoughts On Protocol Requirements

From: [email-masked]
Date: Mon, 26 Mar 2001 11:20:59 +0200

Hi Bruce,

I think you have provided a clever set of comments/ideas. It is excellent
to have someone proposing a different protocol for SPIRITS. I think that It
is better to compare possibilities and not just follow what the rest of the
world is saying.

Your proposal to use XML is very interesting, and I agree it needs to be
considered a candidate protocol for SPIRITS. By the way, I understand that
you mean XML based on HTTP (since XML is just about contents and needs a
protocol) .. or do you mean XML using SIP?.

After a very quick thought (and not being a SIP expert), I think that the
use of XML would be preferrable if we decide to map a lot of INAP protocol
information into SPIRITS protocol (and not if the amount of information we
pass to SPIRITS is limited).

I tend to think that we will not need to copy many INAP parameters into
SPIRITS protocol, and SIP could be better, but I would need to think more
into it.

What does the rest of the list think about it?.

Best Regards,

Jorge Gato

P.D. By the way, did you send the proposal to use XML to transfer ISUP
messages using SIP (instead that using MIME) to the SIP group ?.

My conclusions
--------------

XML may well be the best way to encode the structured data in the INAP
messages at the boundary of the architecture into a text based protocol
for use within the architecture.

Given that there are standard, machine readable definition 'languages'
DTD for XML and ASN.1 for INAP et al, then automatic code generation of
the translator would offer many benefits.

There has been some work looking at encoding various ITU/T protocols
into SIP, but these merely put the ITU/T message into the body as a new
MIME type. This approach means that each element in the architecture
needs to support SIP as a transport protocol, then be able to decode the
embedded INAP message. If as builders of SPIRITS applications we have to
do that, would it not be easier to drop SIP and just decode the binary
ASN.1 encoded data?

There are some unusual requirements and characteristics on the B interface
which may make most commonly used tranport protocols unacceptable.

regards

Bruce

-------------------------------------------------------
Bruce Chapman, Software Systems Architect,
NEC New Zealand
LEVEL 6
CORNER TARANAKI AND MANNERS STREETS
WELLINGTON
PHONE: 64  4  381-6279
FAX:   64  4  381-1110
EMAIL: [email-masked]
--------------------------------------------------------

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: "Kumar V. Vemuri" <[email-masked]>
Date: Mon, 26 Mar 2001 08:44:30 -0600

Bruce, Jorge,
 that was a very interesting discussion. Here are some thoughts
 on how we could proceed with the protocol work if we continued
 to pursue using SIP. As you very well know, use of SIP does
 not preclude the use of XML. Comments?
regards,
Kumar.
--
There seem to be at least four alternatives for addressing how 
the Spirits related information could be carried within the body 
of SIP messages. We need to agree on a particular technique after 
studying the various possibilities and their associated pros and 
cons. I'm not claiming these are THE only ways of doing this, 
just that these are some ideas for discussion.
--
 Alternatives:
1. Extend the traditional SDP as defined, to encode Spirits data 
   as well. This is (sort of) supported by the SDP draft. To 
   quote from RFC 2327 (The SDP Protocol):
   "Some lines in each description are required and some are 
    optional but all must appear in exactly the order given here 
    (the fixed order greatly enhances error detection and allows 
    for a simple parser). Optional items are marked with a `*'.

    Session description
        v=  (protocol version)
        o=  (owner/creator and session identifier).
        s=  (session name)
        i=* (session information)
        u=* (URI of description)
        e=* (email address)
        p=* (phone number)
        c=* (connection information - not required if included in 
              all media)
        b=* (bandwidth information)

         One or more time descriptions (see below)
         z=* (time zone adjustments)
         k=* (encryption key)
         a=* (zero or more session attribute lines)

         Zero or more media descriptions (see below)
         Time description
         t=  (time the session is active)
         r=* (zero or more repeat times)

         Media description
         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information - optional if included at 
              session-level)
         b=* (bandwidth information)
         k=* (encryption key)
         a=* (zero or more media attribute lines)

   The set of `type' letters is deliberately small and not 
   intended to be extensible -- SDP parsers must completely 
   ignore any announcement that contains a `type' letter that it 
   does not understand. The 'attribute' mechanism ("a=" described 
   below) is the primary means for extending SDP and tailoring it 
   to particular applications or media. Some attributes (the ones 
   listed in this document) have a defined meaning but others may 
   be added on an application-, media- or session-specific basis. 
   A session directory must ignore any attribute it doesn't 
   understand.

   [...]
   
   Attributes

   a=<attribute>
   a=<attribute>:<value>

   Attributes are the primary means for extending SDP.  
   Attributes may be defined to be used as "session-level" 
   attributes, "media-level" attributes, or both.

   A media description may have any number of attributes
   ("a=" fields) which are media specific.  These are referred
   to as "media-level" attributes and add information about the 
   media stream.  Attribute fields can also be added before the 
   first media field; these "session-level" attributes convey 
   additional information that applies to the conference as a 
   whole rather than to individual media; an example might be 
   the conference's floor control policy. 

   Attribute fields may be of two forms:
   o property attributes.  A property attribute is simply of the 
     form "a=<flag>".  These are binary attributes, and the 
     presence of the attribute conveys that the attribute is a 
     property of the session.
     An example might be "a=recvonly".

   o value attributes.  A value attribute is of the form
     "a=<attribute>:<value>".  An example might be that a 
     whiteboard could have the value attribute 
     "a=orient:landscape"

   Attribute interpretation depends on the media tool being 
   invoked. Thus receivers of session descriptions should be 
   configurable in their interpretation of announcements in 
   general and of attributes in particular.

   Attribute names must be in the US-ASCII subset of 
   ISO-10646/UTF-8.

   Attribute values are byte strings, and MAY use any byte value 
   except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, 
   attribute values are to be interpreted as in ISO-10646 
   character set with UTF-8 encoding.  Unlike other text fields, 
   attribute values are NOT normally affected by the `charset' 
   attribute as this would make comparisons against known values 
   problematic.  However, when an attribute is defined, it can be 
   defined to be charset-dependent, in which case it's value 
   should be interpreted in the session charset rather than in 
   ISO-10646.

   Attributes that will be commonly used can be registered with 
   IANA (see Appendix B).  Unregistered attributes should begin 
   with "X-" to  prevent inadvertent collision with registered 
   attributes.  In either case, if an attribute is received that 
   is not understood, it should simply be ignored by the 
   receiver." (end excerpt).

   We can therefore embed the Spirits information that needs to 
   be conveyed using the "a" parameter in traditional SDP bodies,
   and proposing extensions to the attribute header set to carry
   the parameters of immediate interest to us.

2. develop a new "description protocol" called (say) the "Trigger 
   and Event Description Protocol" (TEDP), write a draft on it, 
   encode the Spirits level details into that, and set up the 
   attribute list with a set of letters for appropriate use in 
   identifying the contents of the message so that fast parsers 
   could be written.

    An example message would then look like:
      INVITE sip:[email-masked] SIP/2.0
      v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
      v:SIP/2.0/UDP 128.16.64.19
      f:sip:[email-masked]
      t:sip:[email-masked]
      i:[email-masked]
      c:application/tedp
      CSeq: 4711 INVITE
      l:187

      <tedp fields and body>

3. define an XML encoding with suitable DTD to encode the 
   information Spirits requires. Thus, one now has a 
   Spirits-specific format that is easily extensible and usable, 
   and has a standard means of sharing this information. Either 
   suitably extended CPL or a new XML DTD may be developed for 
   this. Note that the latter is probably preferable, since 
   standard CPL is unlikely to have existing support for the
   encoding of Spirits information. The message would have a "c" 
   field (see above for reference) that would look like: 
   "c:application/xml" if we have a specific type of XML for 
   this purpose (TEXML?) then if there is a registered 
   non-binary MIME type registered for this, the MIME encoding 
   may be done as "MIME subtype name: texml+xml". 
   Please see CPL draft for this.

4. follow the ISUP encoding techiques as in SIP-T, and support 
   the encapsulation of binary encoded INAP message data into the 
   SIP message body. This way, the Spirits client does not need 
   to do much of a parsing function. Can define a new MIME type 
   to do this:
   (adapted from the ISUP and QSIG MIME proposal draft)
      "Media type name: application
       Media subtype name: SPIRITS
       Required parameters: version
       Optional parameters: base
       Encoding scheme: binary
       Security considerations: ..."
--

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 26 Mar 2001 16:50:27 +0100

Hi fellow SPIRITualists,

I believe that Bruce has given a good argument for the use of SIP.
...............................................^^^

Bruce mentions the need for protection, plus the need for a large number
of long lived but low data rate sessions. AFAIK, SIP copes with these
requirements; calls are quite long lived, and there had better be a lot
of them (or we're all out of business :). SIP runs over UDP so that we
don't have the problem that HTTP/HTTPS servers have with limits to the
number of concurrent sessions.

We based PINT on SIP - it works for us, so you may need to give some
details on why it doesn't work for SPIRITS.

PINT messages traverse existing SIP (and 3GPP CSCF) proxies.
I was particularly happy that we didn't have to re-invent a
worldwide infrastructure.

I'm intrigued by the comment that:
>  "These sessions need to have the characteristic that the Gateway can
>  determine if the session is still active.

Perhaps an expansion would be useful?
-- 
[email-masked]: +44 1794 833666::<my opinions>: