Subject: RE: [SIPFORUM] Re: [SIP] JAIN SIP Specification

From: Itamar Gilad <[email-masked]>
Date: Wed, 18 Oct 2000 19:07:43 +0200

Hi again Chris,
 
I'd like to re-emphasize what Bobby says below.  The JAIN SIP specification
presented here seems to deal just with the "message layer" i.e. parsing,
encoding, message and message part containers.  I'd like to join those who
commend the fine and comprehensive work done.  However, this layer has
nothing to do with transactions and their state.  It would be a mistake to
rely on it to retain 'transaction-ids' and associate messages to them
(please correct me if I'm misinterpreting your meaning). Note that
identifying a transaction from a message is not a trivial matter and
continuously more message fields are added to the "transaction key" in order
to deal with spiraling, merging etc. A more straight-forward approach would
be to put this functionality in the "transaction layer" where transaction
objects live and make a clean separation between the two layers.
 
Regards
  Itamar
-----Original Message-----
From: Bobby Sardana [mailto:[email-masked]]
Sent: Wed, October 18, 2000 6:39 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

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: 

"M. Ranganathan" wrote: 

Hi Chris, 

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

I get one or two :) 

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 see where you're coming from alright, and I suppose changing header
classes into interfaces, could fit in with Gethin's proposal nicely? 

 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.

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 
>> 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.) 
> 
> 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. 
> 
>> 
>> 
>> 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.) 
> 
> 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! 
> 
>> 
>> 
>> Ranga. 
>> 
>> Gethin Liddell wrote: 
>> 
>> > 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 
>> > jain.protocol.ip.sip.header 
>> > jain.protocol.ip.sip.message 
>> > 
>> > 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: 
>> > > 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 
>> > > ... 
>> > > .... 
>> > > 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 
>> > > 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? 
>> > 
>> > -- 
>> > Gethin Liddell 
>> > Ubiquity Software Corporation 
>> > 
>> > http://www.ubiquity.net <http://www.ubiquity.net>  
>> > mailto:[email-masked] <mailto:[email-masked]>  
>> > 
>> > _______________________________________________ 
>> > SIP mailing list 
>> > [email-masked] 
>> > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>> 
>> -- 
>> M.Ranganathan 
>> NIST Advanced Networking Technologies Group, 
>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
>> Tel: 301 975 3664 Fax: 301 590 0932 
>> 
>> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ© 
> 

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

Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

---

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

Itamar,

It is for the very reason that identifying a transaction from a message
is not a trivial matter that I wanted to put the transaction handling
inside the JainSipProvider. I don't think the spec should just deal with
just the message layer. How many people are going to write JAIN SIP
applications if they have to implement their own transaction keys? I'd
imagine very few.

Regards,
Chris

Itamar Gilad wrote:

>  Hi again Chris,I'd like to re-emphasize what Bobby says below.  The
> JAIN SIP specification presented here seems to deal just with the
> "message layer" i.e. parsing, encoding, message and message part
> containers.  I'd like to join those who commend the fine and
> comprehensive work done.  However, this layer has nothing to do with
> transactions and their state.  It would be a mistake to rely on it to
> retain 'transaction-ids' and associate messages to them (please
> correct me if I'm misinterpreting your meaning). Note that identifying
> a transaction from a message is not a trivial matter and continuously
> more message fields are added to the "transaction key" in order to
> deal with spiraling, merging etc. A more straight-forward approach
> would be to put this functionality in the "transaction layer" where
> transaction objects live and make a clean separation between the two
> layers.Regards Itamar
>      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.
>
>     > 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:
>     > > >
>     > > >> > http://www.ubiquity.net
>     > > >> > mailto:[email-masked]
>     > > >> >
>     > > >> Hfæj)b?
>     > > b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>     > > >
>     > >
>     > > --
>     > > M.Ranganathan