Subject: RE: [SIP] JAIN SIP Specification

From: Itamar Gilad <[email-masked]>
Date: Sun, 15 Oct 2000 20:34:02 +0200

Hi Chris,

a few comments:

Requirement 3.3.1.2 (JAIN SIP Events) names only SIP messages as SIP events.
RFC2543 specifies that a TCP connection-close event should sometimes be
interpreted as reception of CANCEL, which might qualify it as an event for
the purposes of JAIN.

This seems to be a very comprehensive API.  I didn't count, but I estimate
you have over 500 methods listed (many of which throw exceptions) in dozens
of classes. This is only the part of the API that deals with SIP messages.
In real life a SIP stack needs to export APIs also for calls, transactions,
SDP and more. Implementing such an extensive API on a system with limited
resources may not be feasible in the near future.  Also, it's very likely
that many SIP-capable devices will not require the entire scope of the
specified API as they may not use all message types and headers.  Any
thoughts on generating a specification for a minimal/mid-level JAIN API
implementation, perhaps in the spirit of RFC2543 appendix A?

Regards,
  
  Itamar Gilad  

> -----Original Message-----
> From: Chris Harris [mailto:[email-masked]]
> Sent: Fri, October 13, 2000 12:52 PM
> To: [email-masked]
> Subject: [SIP] JAIN SIP Specification
> 
> 
> Dear SIP WG,
> 
> The JAIN SIP Specification is available from today for Public 
> Review on
> the Java website. It can be found at
> http://java.sun.com/aboutJava/communityprocess/review/jsr032/i
ndex.html.

The Public Review will close on 28th November.

Regards,
Chris Haris

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

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

---

From: Chris Harris <[email-masked]>
Date: Mon, 16 Oct 2000 00:06:13 +0100

Hello Itamar,

Thanks for the comments. I have included responses below.

Regards,
Chris

> interpreted as reception of CANCEL, which might qualify it as an event for

The JAIN SIP API is independent of the underlying transport, and if something
happens at the transport level, such as your example, then it would be up to the
JAIN SIP implementation to interpret the underlying event, and generate an
appropriate SIP message to send to JAIN SIP applications.

> implementation, perhaps in the spirit of RFC2543 appendix A?

Yes - it is true that there are many classes and methods. This is for the
benefit of the API user - it removes the need for users to parse the standard
headers, reduces the risk of users using incorrect header values, and ensures
greater application portability. The API certainly could have been defined with
just one generic Header and Message class, but that would that be a very helpful
SIP API?

The JAIN SIP API does not permit applications to have direct access to
transactions. An application is given a transaction id as a reference by the
JainSipProvider, and it can use the reference to invoke send methods on the
JainSipProvider - but the Provider has control over transactions and may throw
an exception if an application attempts to do something it doesn't like.

There is no notion of call control in this API - it is intended only as a Java
interface to SIP. Within the JAIN framework, call control is handled by JCC
(Java Call Control) which is an Application Level API - the JAIN SIP API needs
to fit beneath this call control API. There have been several requests for a
higher level API for SIP-specific services, but whether this will be within the
JAIN framework is not clear. This high level API could sit on top of the current
API - or could be used instead - making it a candidate for the minimal/mid-level
JAIN API you suggest. I would be very interested to hear suggestions from people
about this.

As for SDP, I have created classes for JAIN SDP which can be used across all the
JAIN Protocol API's, but their use is not mandated by the JAIN SIP API - the
body is simply an Object (whose toString() method will be called). In hindsight,
the SDP classes should probably have been included in the Javadoc and jar-file,
but since these classes are within the scope of more than just this API, I
postponed their inclusion.