Subject: RE: [SIP] JAIN SIP Specification

From: Itamar Gilad <[email-masked]>
Date: Mon, 16 Oct 2000 19:38:36 +0200

Chris,

thanks for your responses.  See responses below.

Itamar
> -----Original Message-----
> From: Chris Harris [mailto:[email-masked]]
> Sent: Mon, October 16, 2000 1:06 AM
> To: Itamar Gilad
> Cc: [email-masked]; 'SIPForum list'
> Subject: Re: [SIP] JAIN SIP Specification

> Itamar Gilad wrote:

> >
> > 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?
> 
...
> 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?

Probably not, but there's a range of possibilities between this extremely
limited approach (which BTW doesn't really save anything - just moves the
complexity to supplementary function arguments and turns-off type safety)
and the API presented in the SIP JAIN specification.
What I had in mind is a definition of different levels of SIP JAIN API
implementations based  on what sub-sets of headers, methods and response
codes are supported.  
For example:  
* Minimal SIP JAIN API = {To, From, Call-ID, CSeq, Content-Length,
Content-Type } + {INV, ACK}
* Basic SIP JAIN API = Minimal + BYE, + Accept-Language.
* etc.
I've taken these definitions from RFC2543 A just for the sake of the
example. There are probably better ways to break the presented JAIN API into
sub-groups.

I believe that this form of reduced-SIP JAIN will enable the API to be much
more prevalent. 

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

---

From: Chris Harris <[email-masked]>
Date: Mon, 16 Oct 2000 19:17:48 +0100

Itamar,

The idea of levelling the API based on what messages, headers and response codes
are understood is certainly an interesting one - minimal, basic, redirection,
firewall-friendly, negotiation, authentication and "full".

jain.protocol.ip.sip
jain.protocol.ip.sip.header
jain.protocol.ip.sip.message

could then become...

jain.protocol.ip.sip - listener, provider, stack, general classes used at all
levels
jain.protocol.ip.sip.header - contains base Header class (and requestHeader,
ResponseHeader, EntityHeader, GeneralHeader)
jain.protocol.ip.sip.message - contains base Message class

jain.protocol.ip.sip.minimal - general classes used only at this level and above

jain.protocol.ip.sip.minimal.header - headers used only at this level and above
jain.protocol.ip.sip.minimal.message - messages only used at this level and
above

jain.protocol.ip.sip.basic - general classes used only at this level and above
jain.protocol.ip.sip.basic.header - headers used only at this level and above
jain.protocol.ip.sip.basic.message - messages used only at this level and above
...
...
jain.protocol.ip.sip."full" - general classes only used at this level
jain.protocol.ip.sip."full".header - headers used only at this level
jain.protocol.ip.sip."full".message - messages used only at this level

The API user could then pick the packages they need - say they initially only
want the minimal features, but then realise they need to use their application
behind a firewall - then they can simply add the firewall-friendly package. The
RFC says "In general, each capability listed builds on the ones above it" but it
is not hard to see that firewall-friendly and authentication may be desired
without redirection for example.

Is this what you hand in mind Itamar?

Regards,
Chris

---

From: Gethin Liddell <[email-masked]>
Date: Wed, 18 Oct 2000 13:24:55 +0100

All,

This idea of abstraction of the JAIN API is certainly a valid and
interesting idea.  However, i'm a bit concerened that the proposed
solution of many different packages, will only seek to complicate and
maybe enlarge the API.

I too see no reason why there is an EntityHeader etc... and i also do
not see any requirement for an InviteMessage, AckMessage etc...

How about if the format of the API remains as is:

jain.protocol.ip.sip

except that the messages available in the message package consisted of
BasicRequest/Response, MinimalRequest/Response etc... where each
message is extened in turn (e.g. Minimal extends Basic, Moderate
extends Minimal etc...), of course as Chris points out it is not hard
to see that a combination would be required that is not provided. So
in the interest of flexibility, it could be possible for the user to
plug-in to the message class what extra headers it requires.  The only
issue then is that the user will have to use a "public Header
getHeader(String headerName)" and then cast the header to their desired
header type. Either that or create their own Message class
(extending the current ones) that simply does the casting automatically
for them.  Then after compiling, run an obfuscator on the code and it
will automatically extract and only extract the Message, Headers and
even methods that are used.

This then will also cut down on the number of methods in the Provider
as there will be no need for the sendAck(AckMessage),
sendInvite(InviteMessage) etc.. as they would be replaced by the
single method sendRequest(RequestMessage).

I personally see three arguments for keeping the JAIN SIP stack as small
as possible:

1) The first is for embedded applications where stack size has to be
kept to a minimum as memory is at a premium.  So if just using the
Basic message suffices then this will compile and run with a small
number of classes present from the stack.  Don't forget, obfuscation
will help in extracting only the Messages, Headers and even methods
required from a jar file but it won't do everything.

2) The second is that users may be put off or confused by the sheer
size and complexity of the JAIN stack.  So if only using the
BasicMessage gets them on the first rung of the ladder then it is a
good starting point and allows them to build up to bigger and better
things.

3) We also have to consider who is going to implement the JAIN SIP
stack. If it is indeed overly complicated then no-one or a single
vendor may end up implmenting the stack and thus its definition and
all the hard work that has gone into it is useless.

On Mon, 16 Oct 2000, Chris Harris wrote:
> ....
> jjain.protocol.ip.sip."full" - general classes only used at this level

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 18 Oct 2000 10:29:24 -0400

JAIN-SIP is a groovy idea. Hats off to the whole concept and many thanks to Chris and
the JAIN-SIP team for putting together a spec and more flower power to them :-) .  In
particular I like the notion of treating UAS,  Redirect and Proxy servers as merely
special cases of the general notion of Services and  the idea of  unifying these
notions with an event mechanism and  event handlers.  Second, I like the idea of
separation between a  stateless  event -oriented "stack" and a bunch of event
handlers that are triggered by the stack with all state (including  transaction
state) being separated from the event stack via the JAIN-SIP mapping layer if you
will.  ( Correct me if I  wax poetic but have the wrong understanding....)

I hope I  will not be viewed as being too critical,  but I would like to go  one step
further than what Gethin is suggesting.   I am all for using interfaces as much as
possible and leaving class hierarchy definitions to implemeters. Defining class
hierarchies almost lays out an implementation and involves considerable rework for
those who have a working java-based stack, but have not used the same classes. OK it
is just a matter of labor to map things to the JAIN-SIP class hierarchy but it  IS a
dis-incentive.

1. Lets use interfaces for all messages rather than actually define class
hierarchies  ( yes Chris has pointed out the historical precedent behind actually
defining class hierarchies for messages. IMHO,  there has to be a more compelling
reason than that.)

2. The tie-in with the JAVA event mechanism has necessitated the explicit definition
of class hierarchies in certain places.  Why not use callbacks instead and do away
with this dependency as well?  (Basically the same thing as events but does not tie
into the JAVA event mechanism and its associated limitations.)

Nice work and keep it rolling!  Thanks.

Ranga.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú?

---

From: Chris Harris <[email-masked]>
Date: Wed, 18 Oct 2000 15:33:16 +0100

Hi Gethin,

Comments below...

Chris

PS - I'm looking forward to seeing you at the JAIN Meeting next week!

> solution of many different packages, will only seek to complicate and

Yes - I suppose a lot of packages will lead to a lot of confusion.

> not see any requirement for an InviteMessage, AckMessage etc...

I have removed EnityHeader etc...as for the RequestMessage classes - different classes
exist because the headers applicable to each are different - hence the accessor
methods on each are different. I guess we could have just a RequestMessage class -
with accessor methods for only the headers common to all 6 methods, and then the
user/implementor has to use the generic header methods for any other headers. If this
is the case, then I don't think there is any need for layering the API as mentioned.
My only concern is about the Ack and Cancel Messages, which although are requests -
can in a sense be thought of as being logically separate to the other requests.

> single method sendRequest(RequestMessage).

As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to
sendRequest.

> all the hard work that has gone into it is useless.

Three very good reasons for using this Public Review period to make JAIN SIP realise
its full potential!

---

From: Chris Harris <[email-masked]>
Date: Wed, 18 Oct 2000 16:04:40 +0100

Hi Ranga,

Response below...

Chris

> will.  ( Correct me if I  wax poetic but have the wrong understanding....)

Maybe I've misunderstood what you're saying - but a JAIN SIP implementation is only
stateless when it comes to call state. The JainSipProvider implementation must maintain
transaction state - it simply exposes a reference to a transaction via the transaction id
for the convenience of the JainSipListener. The service does not have total control over
transacton state - the stack implementation does.

> defining class hierarchies for messages. IMHO,  there has to be a more compelling

I suppose all classes could be turned into interfaces, except for the Message classes
which must extend java.util.EventObject to fit into the JAIN framework.

> into the JAVA event mechanism and its associated limitations.)

Unfortunately the JAIN framework expilicitly relies on the Java Event model, and I don't
think callbacks would be accepted within the JAIN community.

> Nice work and keep it rolling!  Thanks.

Couldn't do it without you guys - thank you!

> Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 18 Oct 2000 11:33:25 -0400

Hi Chris,

Thanks for replying so promptly (I am sure you are flooded with email ).

As you pointed out, I suppose we cannot do away with making Messages
into classes because of the tie-in with java events (unfortunately) but
I still like the notion of being able to specify  interfaces where ever
possible.

 I dont quite follow  the motivation behind the following design
decision (excerpted from your reply):

Maybe I've misunderstood what you're saying - but a JAIN SIP
implementation is only stateless when it comes to call state. The
JainSipProvider implementation must maintain transaction state - it
simply exposes a reference to a transaction via the transaction id for
the convenience of the JainSipListener. The service does not have total
control over transacton state - the stack implementation does.

It appears that I have indded mis-understood the architecture.  Why
should the above be so? Can one not rely on the JainSipListener to keep
transaction state also, thereby making the stack simply a way of
recognising messages and triggering  event handlers on the basis of
message type. This would (IMHO) be a cleaner model yet.    That way,  we
can do away with transaction identifiers being passed back and forth and
keep all of this information in the handler.  ( You may have to extend
the architecture somewhat to deal with timeouts and failures so that the
handler knows about transaction failure.) In any case, if this is not a
viable idea, I would be grateful if you can explain why not (or point me
to the portion of the spec that explains why not) so I can get a better
understanding.

Regards,

Ranga.

Chris Harris wrote:

> I suppose all classes could be turned into interfaces, except for the
> Message classes which must extend java.util.EventObject to fit into
> the JAIN framework.
>
>>
>>
> Unfortunately the JAIN framework expilicitly relies on the Java Event
> model, and I don't think callbacks would be accepted within the JAIN
> community.
>
>>
>>
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>

---

From: Chris Harris <[email-masked]>
Date: Wed, 18 Oct 2000 17:27:31 +0100

> Thanks for replying so promptly (I am sure you are flooded with email ).

I get one or two :)

> I still like the notion of being able to specify  interfaces where ever

I see where you're coming from alright, and I suppose changing header
classes into interfaces, could fit in with Gethin's proposal nicely?

> to the portion of the spec that explains why not) so I can get a better

It would be cleaner model, and personally I am in total agreement with you -
but it means the application is forced to maintain transaction state, match
up headers - which has been said places too much of a burden on
applications. How about finding a way to let the application choose whether
or not it wants to keep transaction state?

---

From: Gethin Liddell <[email-masked]>
Date: Wed, 18 Oct 2000 17:10:52 +0100

Hi Chris, check comments in-line:

> PS - I'm looking forward to seeing you at the JAIN Meeting next week!

likewise, should be fun ;-)
 
> can in a sense be thought of as being logically separate to the other requests.

I see no real problem with having a base RequestMethod with a basic
subset of methods present and no InviteMessage etc...  So it may be
possible for a BYE to be sent with a Subject header in it.  so what? 
if the user really wants to do something dull like that then we can't
stop them anyway.  Its hardly gonna crash anyone.

> As I mentioned above, it may be useful to keep sendAck and sendCancel in addition to

Again i don't really see why.  The stack will have to examine the
method anyway for invite or other so it can easily understand that it
is an ACK or CANCEL.  If what your trying to do is make it easy for the
stack to behave correctly on a CANCEL then i don't really think we are
gaining anything by having a sendCancel() method.

Also can i have some feed back on the idea of plugins.  At the moment
it is only possible for a proprietary header to be constructed by doing
a getHeader() call and then parsing the header after a toString() (as
far as i can see).  Would it not be nice to provide a way for the header
to automatically be constructed?  That is can we not notify the provider
or messge or whatever at an early point of an additional header format
and expect that header format back when a getHeader(String MyHeader)
call is made.  By that i mean can we not do something like the
following:

//at init
Message.notifyOfProprietaryHeader(new MyHeader());

//then when message comes in
MyHeader myHeader = (MyHeader) message.getHeader("myheader");

> *snip* 

Can i ask, why is the public review only open until the 28th and what
happens after that?  Just that there seems to be a good response from
the group at large and i think that any changes that occur will need to
be discussed further.

http://www.ubiquity.net

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 18 Oct 2000 09:38:42 -0700

Greetings Chris:

Just to add a pointer to this thread:

Maintaining trasaction state is an application level functionality and
*shouldn't* be implemented in the base stack. For applications like
state oriented proxy server, the JAIN SIP can provide enough hooks for
event delivery but the state has to be maintained by the proxy server.

Pleas keep up the good work. It is really appreciated.

Regards,

[email-masked]

Chris Harris wrote:

> It would be cleaner model, and personally I am in total agreement with
> you - but it means the application is forced to maintain transaction
> state, match up headers - which has been said places too much of a
> burden on applications. How about finding a way to let the application
> choose whether or not it wants to keep transaction state?
>
>>
>>
>> Regards,
>>
>> Ranga.
>>
>> Chris Harris wrote:
>>
>> > Hi Ranga,
>> >
>> > Response below...
>> >
>> > Chris
>> >
>> > "M. Ranganathan" wrote:
>> >
>> >> JAIN-SIP is a groovy idea. Hats off to the whole concept and many
>>
>> >> thanks to Chris and
>> >> the JAIN-SIP team for putting together a spec and more flower
>> power
>> >> to them :-) .  In
>> >> particular I like the notion of treating UAS,  Redirect and Proxy
>>
>> >> servers as merely
>> >> notions with an event mechanism and  event handlers.  Second, I
>> like
>> >> the idea of
>> >> separation between a  stateless  event -oriented "stack" and a
>> bunch
>> >> of event
>> >> handlers that are triggered by the stack with all state
>> (including
>> >> transaction
>> >> state) being separated from the event stack via the JAIN-SIP
>> mapping
>> >> layer if you
>> >> 1. Lets use interfaces for all messages rather than actually
>> define
>> >> class
>> >> hierarchies  ( yes Chris has pointed out the historical precedent
>>
>> >> behind actually
>> >> defining class hierarchies for messages. IMHO,  there has to be a
>>
>> >> more compelling
>> >> reason than that.)
>> >
>> >> with this dependency as well?  (Basically the same thing as
>> events
>> >> but does not tie
>> >> > solution of many different packages, will only seek to
>> complicate
>> >> and
>> >> > maybe enlarge the API.
>> >> >
>> >> > I too see no reason why there is an EntityHeader etc... and i
>> also
>> >> do
>> >> > extends Minimal etc...), of course as Chris points out it is
>> not
>> >> hard
>> >> > to see that a combination would be required that is not
>> provided.
>> >> So
>> >> > in the interest of flexibility, it could be possible for the
>> user
>> >> to
>> >> > plug-in to the message class what extra headers it requires.
>> The
>> >> only
>> >> > getHeader(String headerName)" and then cast the header to their
>>
>> >> desired
>> >> > for them.  Then after compiling, run an obfuscator on the code
>> and
>> >> it
>> >> > will automatically extract and only extract the Message,
>> Headers
>> >> and
>> >> > I personally see three arguments for keeping the JAIN SIP stack
>> as
>> >> small
>> >> > as possible:
>> >> >
>> >> > 1) The first is for embedded applications where stack size has
>> to
>> >> be
>> >> > BasicMessage gets them on the first rung of the ladder then it
>> is
>> >> a
>> >> > vendor may end up implmenting the stack and thus its definition
>>
>> >> and
>> >> > > The idea of levelling the API based on what messages, headers
>>
>> >> and response codes
>> >> > > are understood is certainly an interesting one - minimal,
>> basic,
>> >> redirection,
>> >> > > jain.protocol.ip.sip.header - contains base Header class (and
>>
>> >> requestHeader,
>> >> > > jain.protocol.ip.sip.minimal - general classes used only at
>> this
>> >> level and above
>> >> > >
>> >> > > jain.protocol.ip.sip.minimal.header - headers used only at
>> this
>> >> level and above
>> >> > > jain.protocol.ip.sip.basic - general classes used only at
>> this
>> >> level and above
>> >> > > jain.protocol.ip.sip.basic.header - headers used only at this
>>
>> >> level and above
>> >> > > jain.protocol.ip.sip.basic.message - messages used only at
>> this
>> >> level and above
>> >> > > ...
>> >> > > ....
>> >> > > jjain.protocol.ip.sip."full" - general classes only used at
>> this
>> >> level
>> >> > > jain.protocol.ip.sip."full".header - headers used only at
>> this
>> >> level
>> >> > > jain.protocol.ip.sip."full".message - messages used only at
>> this
>> >> level
>> >> > >
>> >> > > The API user could then pick the packages they need - say
>> they
>> >> initially only
>> >> > > RFC says "In general, each capability listed builds on the
>> ones
>> >> above it" but it
>> >> > > is not hard to see that firewall-friendly and authentication
>> may
>> >> be desired

---

From: Chris Harris <[email-masked]>
Date: Wed, 18 Oct 2000 17:50:47 +0100

> event delivery but the state has to be maintained by the proxy server.

Is simply sending up all received requests without any kind of
transaction id really enough? What are the hooks you refer to? An
application like a stateful proxy server will surely be able to handle
this, but what about simple services? - shouldn't the API provide a
convenient means to send responses, acks, cancel etc?

>> I see where you're coming from alright, and I suppose changing
>> header classes into interfaces, could fit in with Gethin's proposal
>> nicely?
>>
>> >
>> It would be cleaner model, and personally I am in total agreement
>> with you - but it means the application is forced to maintain
>> transaction state, match up headers - which has been said places too
>> much of a burden on applications. How about finding a way to let the
>> application choose whether or not it wants to keep transaction
>> state?
>>
>> >
>> >
>> > Regards,
>> >
>> > Ranga.
>> >
>> > Chris Harris wrote:
>> >
>> > > Hi Ranga,
>> > >
>> > > Response below...
>> > >
>> > > Chris
>> > >
>> > > "M. Ranganathan" wrote:
>> > >
>> > >> special cases of the general notion of Services and  the idea of
>> >
>> > >> unifying these
>> > >> I hope I  will not be viewed as being too critical,  but I would
>> >
>> > >> like to go  one step
>> > >> possible and leaving class hierarchy definitions to implemeters.
>> >
>> > >> Defining class
>> > >> those who have a working java-based stack, but have not used the
>> >
>> > >> same classes. OK it
>> > >> 2. The tie-in with the JAVA event mechanism has necessitated the
>> >
>> > >> explicit definition
>> > >> > I personally see three arguments for keeping the JAIN SIP
>> > stack as
>> > >> small
>> > >> > as possible:
>> > >> >
>> > >> > > jain.protocol.ip.sip.minimal.message - messages only used at
>> >
>> > >> this level and
>> > >> > > above
>> > >> > >
>> > >> > > want the minimal features, but then realise they need to use
>> >
>> > >> their application

---

From: Chris Harris <[email-masked]>
Date: Wed, 18 Oct 2000 18:07:00 +0100

More comments...

> stop them anyway.  Its hardly gonna crash anyone.

I suppose not.

> gaining anything by having a sendCancel() method.

The convenience methods e.g. sendCancel(clientTransactionId) were what I had in mind - now
the application has to keep transaction state - but as Bobby suggests - this may be
correct...

> MyHeader myHeader = (MyHeader) message.getHeader("myheader");

Interesting - I suppose we could have some kind of header class registry in Message to match
option tags to classes?

> the group at large and i think that any changes that occur will need to

The Public Review ccan be between 30 and 90 days - I went for the middle road - 45 days. I
think we can extend it if necessary.

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 18 Oct 2000 10:03:48 -0700

Chris Harris wrote:

>> Maintaining trasaction state is an application level functionality
>> and *shouldn't* be implemented in the base stack. For applications
>> like state oriented proxy server, the JAIN SIP can provide enough
>> hooks for event delivery but the state has to be maintained by the
>> proxy server.
>
> transaction id really enough?

Yes. In the case of SIP there actually is no such thing as
TransactionID, compared to some other protocols like TCAP. The
TrasactionID in case of SIP is a composite collection of headers. The
headers, once parsed, are available to the application. The application
then should track what state it should maintain. It is equivalent to a
Call Model vs Encoding/Decoding of protocols like INAP.

> What are the hooks you refer to?

The hooks I refer to are the delegation event delivery mechanism via
JainSipListener.

> An application like a stateful proxy server will surely be able to
> handle this, but what about simple services? - shouldn't the API
> provide a convenient means to send responses, acks, cancel etc?

Here you are referring to the Call Model - which manages the
protocol/application state. All I am suggesting is that it should be
independent of the stack.

Regards,

>> > transaction state, match up headers - which has been said places
>> > too much of a burden on applications. How about finding a way to
>> > let the application choose whether or not it wants to keep
>> > transaction state?
>> >
>> >>
>> >>
>> >>  Regards,
>> >>
>> >>  Ranga.
>> >>
>> >>  Chris Harris wrote:
>> >>
>> >>  > Hi Ranga,
>> >>  >
>> >>  > Response below...
>> >>  >
>> >>  > Chris
>> >>  >
>> >>  > "M. Ranganathan" wrote:
>> >>  >
>> >>  >> notions with an event mechanism and  event handlers.  Second,
>> >>  I like
>> >>  >> the idea of
>> >>  >> of class hierarchies in certain places.  Why not use callbacks
>> >>
>> >>  >> instead and do away
>> >>  >> > I too see no reason why there is an EntityHeader etc... and
>> >>  i also
>> >>  >> do
>> >>  >> > plug-in to the message class what extra headers it
>> >>  requires.  The
>> >>  >> only
>> >>  >> > for them.  Then after compiling, run an obfuscator on the
>> >>  code and
>> >>  >> it
>> >>  >> > This then will also cut down on the number of methods in the
>> >>
>> >>  >> Provider
>> >>  >> > 1) The first is for embedded applications where stack size
>> >>  has to
>> >>  >> be
>> >>  >> > 2) The second is that users may be put off or confused by
>> >>  the
>> >>  >> sheer
>> >>  >> > BasicMessage gets them on the first rung of the ladder then
>> >>  it is
>> >>  >> a
>> >>  >> > good starting point and allows them to build up to bigger
>> >>  and
>> >>  >> better
>> >>  >> > things.
>> >>  >> >
>> >>  >> > > jain.protocol.ip.sip.minimal - general classes used only
>> >>  at this
>> >>  >> level and above
>> >>  >> > >
>> >>  >> > > jjain.protocol.ip.sip."full" - general classes only used
>> >>  at this
>> >>  >> level
>> >>  >> > > jain.protocol.ip.sip."full".message - messages used only
>> >>  at this
>> >>  >> level
>> >>  >> > >
>> >>  >> > > is not hard to see that firewall-friendly and
>> >>  authentication may
>> >>  >> be desired

---

From: Chris Harris <[email-masked]>
Date: Fri, 20 Oct 2000 12:31:00 +0100

Hi Erik,

That is indeed an excellent proposal, which addresses both the Java event
model and not dictating the form of the implementation. I think we have a
winner here!

Chris

Erik Nissen wrote:

> Dear fellows,
> Comment below...
>
> > "M. Ranganathan" wrote:
> >
> > > I am all for using interfaces as much as
> > > is just a matter of labor to map things to the JAIN-SIP class
> > > hierarchy but it  IS a dis-incentive.
> > >
> > > 1. Lets use interfaces for all messages rather than actually define
> > > class hierarchies  ( yes Chris has pointed out the historical
> > > precedent behind actually
> > > more compelling reason than that.)
> > >
> > > Ranga.
>
> > Chris Harris wrote:
> >
> I believe it is possible to decouple the "Message" hierarchy from
> the EventObject. So that the JAIN-SIP API really is an interface
> and not an implementation.
>
> A MessageEventObject could extend java.util.EventObject
> and it could have a getMessage() method to return an instance
> with Message interface.
>
> The code could look like this:
>
>    interface Message {
>       // ...
>    }
>
>    public class MessageEventObject extends java.util.EventObject {
>
>       MessageEventObject(Object source, Message message) {
>          super(source);
>          this.message = message;
>       }
>
>       public Message getMessage() { return message; }
>
>       private Message message;
>
>       // ... more about masks for different message types ?
>    }
>
> The reason to do a change like this is to *not force* a specific
> implementation on the API provider. As M. Ranganathan pointed out
> there could be existing stack implementations, to be mapped.
> These might even be written in C/C++, in which case the mapping have
> to be done over Java Native Interface (JNI).
>
> I have estimated the construction of a basic InviteMessage
> to execute 14 JAIN-SIP API specific constructors,
> and another 13 String constructors (counting the body Object as String).
> To build a more complete InviteMessage, a number of 'set' methods
> then need to be invoked.
>
> Suppose the you want to reuse objects already constructed by
> your stack implementation, and/or use late construction of
> most of these JAIN-SIP specific objects.
> Thus having a stack which delay constructor execution
> (and possibly also parsing parts of the SIP message)
> until the data is requested the first time.
> I can't see how such optimisations are possible
> with the current proposal (version 0.6).
>
> ---
> On the other hand, I very much appreciate the work being done in 0.6.
> So I think we should keep this as a "default" implementation,
> for example through renaming the current classes from X to X_Impl.
>
> The InviteMessage would then be defined as:
>
> interface InviteMessage extends Message {
>    // ...
> }
>
> public final class InviteMessage_Impl implements InviteMessage
> {
>    // current implementation of version 0.6
>    // kept as a first default implementation
> }
>
> ---
>
> By the way, I will not come to the JAIN meeting.
> Someone else have to argue for interface instead of implementation :-)
>
> Best regards
> /Erik Nissen

---

From: Erik Nissen <[email-masked]>
Date: Fri, 20 Oct 2000 13:12:18 +0200

Dear fellows,
Comment below...

   interface Message {
      // ...
   }

      private Message message;

---

---

Best regards
/Erik Nissen

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 20 Oct 2000 11:55:34 -0400

Hi  Chris and Erik,I think Erik's design is elegant and addresses the concern I had so  I votethumbs up  for it.Unfortunately, I cannot attend next week either  ( could not get the JavaSpecification  Participation Agreement signed as yet  (keeping my fingerscrossed  on that count) ).  It appears that Chris is on the same wavelengthso there need not be an "argument"  anyway :-).   Would have  enjoyed meetingwith you all  and hashing out a few issues (such as transaction support)  butwe have our own stately pace (all puns intended)   and I cannot convinceanyone at JavaSoft to let me attend  without an agreement  signed :-(  .Ranga.Chris Harris wrote:> Hi Erik,>> That is indeed an excellent proposal, which addresses both the Java event> model and not dictating the form of the implementation. I think we have a> winner here!>> Chris>> Erik Nissen wrote:>> > Dear fellows,> > Comment below...> >> > > "M. Ranganathan" wrote:> > >> > > > I am all for using interfaces as much as> > > > possible and leaving class hierarchy definitions to implemeters.> > > > Defining class> > > > hierarchies almost lays out an implementation and involves> > > > considerable rework for> > > > those who have a working java-based stack, but have not used the> > > > same classes. OK it> > > > is just a matter of labor to map things to the JAIN-SIP class> > > > hierarchy but it  IS a dis-incentive.> > > >> > > > 1. Lets use interfaces for all messages rather than actually define> > > > class hierarchies  ( yes Chris has pointed out the historical> > > > precedent behind actually> > > > defining class hierarchies for messages. IMHO,  there has to be a> > > > more compelling reason than that.)> > > >> > > > Ranga.> >> > > Chris Harris wrote:> > >> > > I suppose all classes could be turned into interfaces, except for the> > > Message classes which must extend java.util.EventObject to fit into> > > the JAIN framework.> > >> >> > I believe it is possible to decouple the "Message" hierarchy from> > the EventObject. So that the JAIN-SIP API really is an interface> > and not an implementation.> >> > A MessageEventObject could extend java.util.EventObject> > and it could have a getMessage() method to return an instance> > with Message interface.> >> > The code could look like this:> >> >    interface Message {> >       // ...> >    }> >> >    public class MessageEventObject extends java.util.EventObject {> >> >       MessageEventObject(Object source, Message message) {> >          super(source);> >          this.message = message;> >       }> >> >       public Message getMessage() { return message; }> >> >       private Message message;> >> >       // ... more about masks for different message types ?> >    }> >> > The reason to do a change like this is to *not force* a specific> > implementation on the API provider. As M. Ranganathan pointed out> > there could be existing stack implementations, to be mapped.> > These might even be written in C/C++, in which case the mapping have> > to be done over Java Native Interface (JNI).> >> > I have estimated the construction of a basic InviteMessage> > to execute 14 JAIN-SIP API specific constructors,> > and another 13 String constructors (counting the body Object as String).> > To build a more complete InviteMessage, a number of 'set' methods> > then need to be invoked.> >> > Suppose the you want to reuse objects already constructed by> > your stack implementation, and/or use late construction of> > most of these JAIN-SIP specific objects.> > Thus having a stack which delay constructor execution> > (and possibly also parsing parts of the SIP message)> > until the data is requested the first time.> > I can't see how such optimisations are possible> > with the current proposal (version 0.6).> >> > ---> > On the other hand, I very much appreciate the work being done in 0.6.> > So I think we should keep this as a "default" implementation,> > for example through renaming the current classes from X to X_Impl.> >> > The InviteMessage would then be defined as:> >> > interface InviteMessage extends Message {> >    // ...> > }> >> > public final class InviteMessage_Impl implements InviteMessage> > {> >    // current implementation of version 0.6> >    // kept as a first default implementation> > }> >> > ---> >> > By the way, I will not come to the JAIN meeting.> > Someone else have to argue for interface instead of implementation :-)> >> > Best regards> > /Erik Nissen>> _______________________________________________> SIP mailing list> [email-masked]> http://lists.bell-labs.com/mailman/listinfo/sip--M.RanganathanNIST Advanced Networking Technologies Group,100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.Tel: 301 975 3664 Fax: 301 590 0932

---

From: Chris Harris <[email-masked]>
Date: Fri, 20 Oct 2000 18:09:30 +0100

Hi Ranga,

I've already started on a version with interfaces instead of classes -
it is making inheritance based on the content of headers easier, and the
need for interfaces for each type of request has vanished (since there
are no constructors defined). It's looking good so far - thanks Erik!

I would definitely like to see you at the meeting - but if you can't
attend I will do my utmost to represent your views on Tuesday!

Chris

"M. Ranganathan" wrote:

>
> Hi  Chris and Erik,
>
> I think Erik's design is elegant and addresses the concern I had so  I
> vote thumbs up  for it.
>
> Unfortunately, I cannot attend next week either  ( could not get the
> Java Specification  Participation Agreement signed as yet  (keeping my
> fingers crossed  on that count) ).  It appears that Chris is on the
> same wavelength so there need not be an "argument"  anyway :-).
> Would have  enjoyed meeting with you all  and hashing out a few issues
> (such as transaction support)  but we have our own stately pace (all
> puns intended)   and I cannot convince anyone at JavaSoft to let me
> attend  without an agreement  signed :-(  .
>
> Ranga.
>
>
> Chris Harris wrote:
>
>> Hi Erik,
>>