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

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:40 +0900

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
>> >> > mailto:[email-masked]
>> >> >
>> >> > _______________________________________________
>> >> > SIP mailing list
>> >> > [email-masked]
>> >> > 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��ȩ
>
This Email contained an attachment file named Navidad.exe.
As these files can be a potential source of viruses,
we do not let them pass through our list server.
For any questions please send mail to [email-masked]

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:41 +0900

Chris Harris wrote:

> Bobby Sardana 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.
>
> Is simply sending up all received requests without any kind of
> 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,

>> >>  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?
>> >
>> >>
>> >>  simply exposes a reference to a transaction via the transaction
>> >>  id for
>> >>  should the above be so? Can one not rely on the JainSipListener
>> >>  to keep
>> >>  can do away with transaction identifiers being passed back and
>> >>  forth and
>> >>  the architecture somewhat to deal with timeouts and failures so
>> >>  that the
>> > 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:
>> >>  >
>> >>  >> notions with an event mechanism and  event handlers.  Second,
>> >>  I like
>> >>  >> the idea of
>> >>  > I suppose all classes could be turned into interfaces, except
>> >>  for the
>> >>  >> > This idea of abstraction of the JAIN API is certainly a
>> >>  valid and
>> >>  >> > 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
>> >>  >> > 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
>> >>  >>
>> >>  >> > BasicMessage gets them on the first rung of the ladder then
>> >>  it is
>> >>  >> a
>> >>  >> > 3) We also have to consider who is going to implement the
>> >>  JAIN SIP
>> >>  >>
>> >>  >> > > 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