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

From: Itamar Gilad <[email-masked]>
Date: Thu, 19 Oct 2000 14:02:52 +0200

Hi Chris,
 
It could be argued that it makes just as much sense for the Provider to
identify also the Call-Leg and Call. Still I think I understand what you are
after and I agree that this might help applications that for some reason
want to know about transaction 'ids', but don't want to work with
transaction objects. 
 
Regards 
  Itamar 

-----Original Message-----
From: Chris Harris [mailto:[email-masked]]
Sent: Thu, October 19, 2000 12:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar, 

I can't really think of any applications other than a stateless proxy that
don't care about transactions. And since stateless proxies are really just
SIP routers and need maximum performance, I can't really see anyone
implementing them with JAIN SIP. 

I think any application that does anything interesting needs to know about
transactions, so the the JAIN SIP API should include some means of
identifying transactions or transaction control. But this has to fit in with
the Listener/Provider event model, so we can't hand a Listener a transaction
object that they can work with directly - we need to give an application
access to transactions through the Provider. I thought a transaction id
would be the simplest way to achieve this. Do you have any suggestions for
improving transaction control for the event model? 

Chris 

Itamar Gilad wrote: 

 No, that's not it.  The application uses a stack to do all of this.  The
stack should export a message-related API like the one defined in the JAIN
SIP specification you presented.  The stack should also export interfaces
for Call control and Transaction control.  It seems more logical for the
application to use a transaction object which handles messaging and notifies
it whenever a message belonging to this transaction is received rather then
having a message object that tells it which transaction it belongs too.
Stateless proxies for example would use only the message layer and they
don't care at all about transactions. I'm Sorry to be so picky, but I just
think that this makes for a cleaner design both in the application and in
the stack.  Our experience with our SIP stack proves that this model works
fine.Itamar 

-----Original Message----- 
From: Chris Harris [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wed, October 18, 2000 8:18 PM 
To: [email-masked] 
Cc: Itamar Gilad; 'Bobby Sardana'; [email-masked]; [email-masked];
[email-masked] 
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification 
 
OK - so if an application just sends a message to the Provider, it has to
check all response messages to see if they match - this is so messy for an
application. What if a response message never arrives - how should the
Provider inform the application of a timeout? Call a timeout method and pass
the request message back? 

Itamar Gilad wrote: 

 Chris, I agree that few SIP applications would like to bother with
transaction mapping.  This is clearly the responsibility of the stack as is
transaction management in general. However in a previous thread you
explained that the issue of managing call and transaction state is outside
the scope of this API specification, which led me to believe that the goal
is to define message-related functionality. I think that injecting
transaction keys into the mix is crossing the lines you defined. Regards,
Itamar 

-----Original Message----- 
From: Chris Harris [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wed, October 18, 2000 7:44 PM 
To: Itamar Gilad 
Cc: 'Bobby Sardana'; [email-masked]; [email-masked];
[email-masked]; [email-masked] 
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification
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 
-----Original Message----- 
From: Bobby Sardana [ mailto:[email-masked]
<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: Thu, 19 Oct 2000 14:30:10 +0100

Hi Itamar,

Sure - after all an application can completely ignore the transaction
ids given to it by the Provider, and use the send methods that don't
take transaction id parameters - the Provider has to cover both types of
application.

Note that I don't necessarily think an application can't have an object
to represent a transaction, just that such an object must operate
through the Provider - since the Provider is supposed to be the
applications only access to the SIP stack. So you could have a client
transaction object containing the request sent returned by the Provider,
and have a cancel method on it - that calls the sendCancel method on the
Provider etc... But I'm not sure how useful this would be - you are also
forcing an application that is not interested in transactions to extract
messages from transaction objects.

Then again, we could always define two JainSipListener subtypes -
JainSipMessageListener and JainSipTransactionListener...this might be a
good idea - then we can have an application indicate to the Provider
whether it is interested in transactions - if it isn't it just receives
Message objects, and if it is it receives Transaction objects
(incorporating the associated Messages) The Transaction objects contain
a transaction id, and can by ClientTransaction or ServerTransaction, and
their methods can call the Provider's methods with the transaction id
parameters. Opinions?

I think incorporating call-legs and calls into the API is asking too
much of an API that deals with messages and transactions - unless we
create a JainSipCall(Leg)Listener...but now we're mandating that the
inderlying implementation has to keep call state...and above we have to
map JCC onto these...that could get very messy!

Chris

Itamar Gilad wrote:

>  Hi Chris,It could be argued that it makes just as much sense for the
> Provider to identify also the Call-Leg and Call. Still I think I
> understand what you are after and I agree that this might help
> applications that for some reason want to know about transaction
> 'ids', but don't want to work with transaction objects. Regards
> Itamar
>
>      I can't really think of any applications other than a
>      stateless proxy that don't care about transactions. And
>      since stateless proxies are really just SIP routers and need
>      maximum performance, I can't really see anyone implementing
>      them with JAIN SIP.
>
>      I think any application that does anything interesting needs
>      to know about transactions, so the the JAIN SIP API should
>      include some means of identifying transactions or
>      transaction control. But this has to fit in with the
>      Listener/Provider event model, so we can't hand a Listener a
>      transaction object that they can work with directly - we
>      need to give an application access to transactions through
>      the Provider. I thought a transaction id would be the
>      simplest way to achieve this. Do you have any suggestions
>      for improving transaction control for the event model?
>
>      Chris
>
>      Itamar Gilad wrote:
>
>     > No, that's not it.  The application uses a stack to do all
>     > of this.  The stack should export a message-related API
>     > like the one defined in the JAIN SIP specification you
>     > presented.  The stack should also export interfaces for
>     > Call control and Transaction control.  It seems more
>     > logical for the application to use a transaction object
>     > which handles messaging and notifies it whenever a message
>     > belonging to this transaction is received rather then
>     > having a message object that tells it which transaction it
>     > belongs too.  Stateless proxies for example would use only
>     > the message layer and they don't care at all about
>     > transactions. I'm Sorry to be so picky, but I just think
>     > that this makes for a cleaner design both in the
>     > application and in the stack.  Our experience with our SIP
>     > stack proves that this model works fine.Itamar
>     >
>     >      Cc: Itamar Gilad; 'Bobby Sardana';
>     >      [email-masked]; [email-masked];
>     >      [email-masked]
>     >      OK - so if an application just sends a message
>     >      to the Provider, it has to check all response
>     >      messages to see if they match - this is so messy
>     >      for an application. What if a response message
>     >      never arrives - how should the Provider inform
>     >      the application of a timeout? Call a timeout
>     >      method and pass the request message back?
>     >
>     >      Itamar Gilad wrote:
>     >
>     >      >  Chris, I agree that few SIP applications would
>     >      > like to bother with transaction mapping.  This
>     >      > is clearly the responsibility of the stack as
>     >      > is transaction management in general. However
>     >      > in a previous thread you explained that the
>     >      > issue of managing call and transaction state is
>     >      > outside the scope of this API specification,
>     >      > which led me to believe that the goal is to
>     >      > define message-related functionality. I think
>     >      > that injecting transaction keys into the mix is
>     >      > crossing the lines you defined. Regards,
>     >      > Itamar
>     >      >
>     >      >      Cc: 'Bobby Sardana';
>     >      >      [email-masked];
>     >      >      [email-masked];
>     >      >      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
>     >      >     >  From: Bobby Sardana
>     >      >     >  [mailto:[email-masked]]
>     >      >     >
>     >      >     >  Cc: [email-masked];
>     >      >     >  [email-masked];
>     >      >     >  [email-masked]
>     >      >     >       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,
>     >      >     >
>     >      >     >       Bobby.Sa
>     >      >     >       [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
>     >      >     >      >>  >> >
>     >      >     >      >>  >> > except that the
>     >      >     >      >>  messages available in
>     >      >     >      >>  the message package
>     >      >     >      >>  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
>     >      >     >      >>  >> > to see that a
>     >      >     >      >>  combination would be
>     >      >     >      >>  required that is not
>     >      >     >      >>  provided.
>     >      >     >      >>  >> > in the interest
>     >      >     >      >>  of flexibility, it
>     >      >     >      >>  could be possible for
>     >      >     >      >>  the user
>     >      >     >      >>  >> > plug-in to the
>     >      >     >      >>  message class what
>     >      >     >      >>  extra headers it
>     >      >     >      >>  requires.  The
>     >      >     >      >>  >> > issue then is
>     >      >     >      >>  that the user will
>     >      >     >      >>  have to use a "public
>     >      >     >      >>  Header
>     >      >     >      >>  >> > getHeader(String
>     >      >     >      >>  headerName)" and then
>     >      >     >      >>  cast the header to
>     >      >     >      >>  their
>     >      >     >      >>  >> > header type.
>     >      >     >      >>  Either that or create
>     >      >     >      >>  their own Message
>     >      >     >      >>  >> > (extending the
>     >      >     >      >>  current ones) that
>     >      >     >      >>  simply does the
>     >      >     >      >>  casting
>     >      >     >      >>  >> > for them.  Then
>     >      >     >      >>  after compiling, run
>     >      >     >      >>  an obfuscator on the
>     >      >     >      >>  code and
>     >      >     >      >>  >> > will
>     >      >     >      >>  automatically extract
>     >      >     >      >>  and only extract the
>     >      >     >      >>  Message, Headers
>     >      >     >      >>  >> > This then will
>     >      >     >      >>  also cut down on the
>     >      >     >      >>  number of methods in
>     >      >     >      >>  the
>     >      >     >      >>  >> > as there will be
>     >      >     >      >>  no need for the
>     >      >     >      >>  sendAck(AckMessage),
>     >      >     >      >>  sendInvite(InviteMessage)
>     >      >     >      >>  etc.. as they would be
>     >      >     >      >>  replaced by the
>     >      >     >      >>  >> > single method
>     >      >     >      >>  >> > I personally see
>     >      >     >      >>  three arguments for
>     >      >     >      >>  keeping the JAIN SIP
>     >      >     >      >>  stack as
>     >      >     >      >>  >> > 1) The first is
>     >      >     >      >>  for embedded
>     >      >     >      >>  applications where
>     >      >     >      >>  stack size has to
>     >      >     >      >>  >> > 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,
>     >      >     >      >>  >> > will help in
>     >      >     >      >>  extracting only the
>     >      >     >      >>  Messages, Headers and
>     >      >     >      >>  even
>     >      >     >      >>  >> > 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
>     >      >     >      >>  >> > 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
>     >      >     >      >>  >> > good starting
>     >      >     >      >>  point and allows them
>     >      >     >      >>  to build up to bigger
>     >      >     >      >>  >> > 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
>     >      >     >      >>  >> > all the hard work
>     >      >     >      >>  that has gone into it
>     >      >     >      >>  is useless.
>     >      >     >      >>  >> > On Mon, 16 Oct
>     >      >     >      >>  2000, Chris Harris
>     >      >     >      >>  wrote:
>     >      >     >      >>  >> > > The idea of
>     >      >     >      >>  levelling the API
>     >      >     >      >>  based on what
>     >      >     >      >>  messages, headers
>     >      >     >      >>  >> > > are understood
>     >      >     >      >>  is certainly an
>     >      >     >      >>  interesting one -
>     >      >     >      >>  minimal, basic,
>     >      >     >      >>  firewall-friendly,
>     >      >     >      >>  negotiation,
>     >      >     >      >>  authentication and
>     >      >     >      >>  "full".
>     >      >     >      >>  >> > > could then
>     >      >     >      >>  become...
>     >      >     >      >>  jain.protocol.ip.sip -
>     >      >     >      >>  listener, provider,
>     >      >     >      >>  stack, general
>     >      >     >      >>  - contains base Header
>     >      >     >      >>  class (and
>     >      >     >      >>  >> > > ResponseHeader,
>     >      >     >      >>  EntityHeader,
>     >      >     >      >>  GeneralHeader)
>     >      >     >      >>  - 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
>     >      >     >      >>
>     >      >     >      >>  >> >
>     >      >     >      >>  mailto:[email-masked]
>     >      >     >      >>
>     >      >     >      >>  >> >
>     >      >     >      >>  >> >
>     >      >     >      >>  >> NIST Advanced
>     >      >     >      >>  Networking
>     >      >     >      >>  Technologies Group,
>     >      >     >      >>  >> 100 Bureau Drive,
>     >      >     >      >>  Stop 8920,
>     >      >     >      >>  Gaithersburg, MD
>     >      >     >      >>  20899.
>     >      >     >      >>  >> 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: "Orit Levin" <[email-masked]>
Date: Thu, 19 Oct 2000 12:15:28 -0400

Hello!
I am sure we are going to have this discussion during the JAIN meeting next
week. But it is hard from not intervening here.

The great benefit of SIP (compared to other competing technologies :-)) is
the abstraction it defines, starting from the low protocol’s level. The
lowest one is the “messages”. The next one is the “transaction”. The next
one is the “call (leg)”.
In our case, we are talking about the keeper of the “Transactions State
machine”.  This point is obvious.

Based on the discussions here, yet another point is less obvious. In order
to define an efficient and interoperable API, there should be (in my
opinion, MUST) one single MASTER of the “Transactions State machine”. The
API itself should be driven by this main architectural decision. It doesn’t
preclude from “exporting” by this Master both the “transaction states” and
“the SIP messages”. It does not preclude from providing by this Master
“modification tools” for both transaction state machine and the SIP
messages.
My point is, that depending on this FIRST decision, the semantic of the “SIP
messages API” part would be very different, even if its syntax may look
alike!!!

Therefore, before diving into the API details, SPEC should define the chosen
model, clearly specifying the real “state machine” MASTER for each
abstraction level. This is the only way to define an interoperable API.

BTW, my technical opinion is to use the SIP design advantage at its best and
to define the Provider, to be the MASTER for the transaction state machine.

Best Regards,
Orit Levin
RADVision Inc.
TEL: 201.529.4300 x 230
FAX:201.529.3516
mailto:[email-masked]
http://www.radvision.com
575 Corporate Drive Suite 420 Mahwah, NJ 07430

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Chris Harris
Sent: Thursday, October 19, 2000 9:30 AM
To: Itamar Gilad
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar,
Sure - after all an application can completely ignore the transaction ids
given to it by the Provider, and use the send methods that don't take
transaction id parameters - the Provider has to cover both types of
application.
Note that I don't necessarily think an application can't have an object to
represent a transaction, just that such an object must operate through the
Provider - since the Provider is supposed to be the applications only access
to the SIP stack. So you could have a client transaction object containing
the request sent returned by the Provider, and have a cancel method on it -
that calls the sendCancel method on the Provider etc... But I'm not sure how
useful this would be - you are also forcing an application that is not
interested in transactions to extract messages from transaction objects.
Then again, we could always define two JainSipListener subtypes -
JainSipMessageListener and JainSipTransactionListener...this might be a good
idea - then we can have an application indicate to the Provider whether it
is interested in transactions - if it isn't it just receives Message
objects, and if it is it receives Transaction objects (incorporating the
associated Messages) The Transaction objects contain a transaction id, and
can by ClientTransaction or ServerTransaction, and their methods can call
the Provider's methods with the transaction id parameters. Opinions?
I think incorporating call-legs and calls into the API is asking too much of
an API that deals with messages and transactions - unless we create a
JainSipCall(Leg)Listener...but now we're mandating that the inderlying
implementation has to keep call state...and above we have to map JCC onto
these...that could get very messy!
Chris
Itamar Gilad wrote:
 Hi Chris,It could be argued that it makes just as much sense for the
Provider to identify also the Call-Leg and Call. Still I think I understand
what you are after and I agree that this might help applications that for
some reason want to know about transaction 'ids', but don't want to work
with transaction objects. Regards   Itamar
-----Original Message-----
From: Chris Harris [ mailto:[email-masked]]
Sent: Thu, October 19, 2000 12:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Itamar,
-----Original Message-----
From: Chris Harris [ mailto:[email-masked]]
Sent: Wed, October 18, 2000 8:18 PM
To: [email-masked]
Cc: Itamar Gilad; 'Bobby Sardana'; [email-masked]; [email-masked];
[email-masked]
-----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:

Regards,
Ranga.

---

From: Chris Harris <[email-masked]>
Date: Thu, 19 Oct 2000 19:35:00 +0100

Hi Orit,

Yes, there is plenty to discuss at next week's meeting :)

I totally agree that the Provider should be the master of transaction
state - (by "master" I assume you mean who has absolute control). In
fact I think the Provider should be the Master of everything it exports
through the API. I believe this is the case in API as it stands...

For example, an application invokes a send method on the Provider, which
the Provider can reject. You could say the application is only making a
request of the Provider, and the result of this request is given by a
thrown exception or a returned transaction id. A similar situation
exists for cancelling a transaction.

Doesn't this fulfil the role of master you mention?

Chris

Orit Levin wrote:

> Hello!
>
> I am sure we are going to have this discussion during the JAIN meeting
> next week. But it is hard from not intervening here.
>
> The great benefit of SIP (compared to other competing technologies J)
> is the abstraction it defines, starting from the low protocol’s level.
> The lowest one is the “messages”. The next one is the “transaction”.
> The next one is the “call (leg)”.
>
> In our case, we are talking about the keeper of the “Transactions
> State machine”. This point is obvious.
>
> Based on the discussions here, yet another point is less obvious. In
> order to define an efficient and interoperable API, there should be
> (in my opinion, MUST) one single MASTER of the “Transactions State
> machine”. The API itself should be driven by this main architectural
> decision. It doesn’t preclude from “exporting” by this Master both the
> “transaction states” and “the SIP messages”. It does not preclude from
> providing by this Master “modification tools” for both transaction
> state machine and the SIP messages.
>
> My point is, that depending on this FIRST decision, the semantic of
> the “SIP messages API” part would be very different, even if its
> syntax may look alike!!!
>
> Therefore, before diving into the API details, SPEC should define the
> chosen model, clearly specifying the real “state machine” MASTER for
> each abstraction level. This is the only way to define an
> interoperable API.
>
> BTW, my technical opinion is to use the SIP design advantage at its
> best and to define the Provider, to be the MASTER for the transaction
> state machine.
>
> Best Regards,
>
> Orit Levin
>
> RADVision Inc.
>
> TEL: 201.529.4300 x 230
>
> FAX:201.529.3516
>
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Chris Harris
> take transaction id parameters - the Provider has to cover both types
> of application.
>
> Note that I don't necessarily think an application can't have an
> object to represent a transaction, just that such an object must
> operate through the Provider - since the Provider is supposed to be
> the applications only access to the SIP stack. So you could have a
> client transaction object containing the request sent returned by the
> Provider, and have a cancel method on it - that calls the sendCancel
> method on the Provider etc... But I'm not sure how useful this would
> be - you are also forcing an application that is not interested in
> transactions to extract messages from transaction objects.
>
> JainSipMessageListener and JainSipTransactionListener...this might be
> a good idea - then we can have an application indicate to the Provider
> whether it is interested in transactions - if it isn't it just
> receives Message objects, and if it is it receives Transaction objects
> (incorporating the associated Messages) The Transaction objects
> contain a transaction id, and can by ClientTransaction or
> ServerTransaction, and their methods can call the Provider's methods
> with the transaction id parameters. Opinions?
>
> inderlying implementation has to keep call state...and above we have
> to map JCC onto these...that could get very messy!
>
> Chris
>
> Itamar Gilad wrote:
>
> I can't really think of any applications other than a stateless proxy
> that don't care about transactions. And since stateless proxies are
> really just SIP routers and need maximum performance, I can't really
> see anyone implementing them with JAIN SIP.
>
> I think any application that does anything interesting needs to know
> about transactions, so the the JAIN SIP API should include some means
> of identifying transactions or transaction control. But this has to
> fit in with the Listener/Provider event model, so we can't hand a
> Listener a transaction object that they can work with directly - we
> need to give an application access to transactions through the
> Provider. I thought a transaction id would be the simplest way to
> achieve this. Do you have any suggestions for improving transaction
> control for the event model?
>
> Chris
>
> Itamar Gilad wrote:
> No, that's not it.  The application uses a stack to do all of this.
> The stack should export a message-related API like the one defined in
> the JAIN SIP specification you presented.  The stack should also
> export interfaces for Call control and Transaction control.  It seems
> more logical for the application to use a transaction object which
> handles messaging and notifies it whenever a message belonging to this
> transaction is received rather then having a message object that tells
> it which transaction it belongs too.  Stateless proxies for example
> would use only the message layer and they don't care at all about
> transactions. I'm Sorry to be so picky, but I just think that this
> makes for a cleaner design both in the application and in the stack.
> Our experience with our SIP stack proves that this model works
> fine.Itamar
> Cc: Itamar Gilad; 'Bobby Sardana'; [email-masked];
> OK - so if an application just sends a message to the Provider, it has
> to check all response messages to see if they match - this is so messy
> for an application. What if a response message never arrives - how
> should the Provider inform the application of a timeout? Call a
> timeout method and pass the request message back?
>
> Itamar Gilad wrote:
> Chris,I agree that few SIP applications would like to bother with
> transaction mapping.  This is clearly the responsibility of the stack
> as is transaction management in general. However in a previous thread
> you explained that the issue of managing call and transaction state is
> outside the scope of this API specification, which led me to believe
> that the goal is to define message-related functionality. I think that
> injecting transaction keys into the mix is crossing the lines you
> defined.Regards,  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
>
> From: Bobby Sardana [mailto:[email-masked]]
> *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.
>
> 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:
> >

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 19 Oct 2000 15:50:24 -0400

Hi Chris!
Conceptually we definitely agree here. Which is great :-)
I am not sure either the “proposed wording” completely grasps the whole
concept.
There are still a number of “subtle” technical issues here, that, I believe,
the SPEC should explicitly specify.
It has to be explained how
-                      the Provider has the control of the Transaction State
machine
-                      the Application has the whole freedom to look and
edit all the messages fields
And all this without
-                      putting a huge overhead on the Provider’s
“consistency checking” logic
-                      and still providing means for keeping the Transaction
State in both the Provider and the Application in complete synch!
Some compromises have obviously be defined and agreed upon.

The next week is going to be interesting, for sure!
Regards,
Orit Levin
RADVision Inc.
TEL: 201.529.4300 x 230
FAX:201.529.3516
mailto:[email-masked]
http://www.radvision.com
575 Corporate Drive Suite 420 Mahwah, NJ 07430

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Chris Harris
Sent: Thursday, October 19, 2000 2:35 PM
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [SIPFORUM] Re: [SIP] JAIN SIP Specification

Hi Orit,
Yes, there is plenty to discuss at next week's meeting :)
I totally agree that the Provider should be the master of transaction
state - (by "master" I assume you mean who has absolute control). In fact I
think the Provider should be the Master of everything it exports through the
API. I believe this is the case in API as it stands...
For example, an application invokes a send method on the Provider, which the
Provider can reject. You could say the application is only making a request
of the Provider, and the result of this request is given by a thrown
exception or a returned transaction id. A similar situation exists for
cancelling a transaction.
Doesn't this fulfil the role of master you mention?
Chris

Orit Levin wrote:
Hello!

-----Original Message-----
From: [email-masked] [
mailto:[email-masked]]On Behalf Of Chris Harris
-----Original Message-----

Hi Itamar,
-----Original Message-----

transaction keys into the mix is crossing the lines you defined.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:

---

From: Chris Harris <[email-masked]>
Date: Thu, 19 Oct 2000 21:06:51 +0100

Hi David,

OK - I definitely went overboard on this one :)

Chris

David Ferry wrote:

> snip
> I dont see what this really gains you.
>
> The current API allows the application to care about transactions if it
> wants to. The transaction ID (or handle if you want to think of it that
> way) is sufficient for writing apps that care about transaction state.
>
> The app can also chose to *not* care about transactions very easily.
> Making the API larger, to do something which it already does cleanly
> seems unneccesary to me.
>
> Just my 2 cents.
>
> Cheers,
> Dave

---

From: David Ferry <[email-masked]>
Date: Fri, 20 Oct 2000 08:32:45 +1300 (NZDT)

snip

Just my 2 cents.

Cheers,
Dave