Subject: [SIP] JAIN SIP Meeting Results

From: Chris Harris <[email-masked]>
Date: Sat, 28 Oct 2000 15:34:44 -0700

Dear SIP community,

The JAIN SIP Expert Group met on 24th October to discuss the comments
that have been received since the specification moved into public
review. One of the several issues discussed was whether to use classes
of interfaces to define JAIN SIP messages and headers. The feeling in
the meeting was that classes were either acceptable, but several other
important pros and cons for each approach have been raised since then. I
have included a summary of the pros and cons for the use of classes
pointed out so far:

 Pros of Classes                    Cons of Classes
                                    Classes force implementation to
 Classes are better for application fully parse messages and headers
 portability because behaviour is   before creating events - even if an
 fully defined in class. Interfaces application is only interested in
 may lead to subtle differences in  one header. Interfaces allow
 behaviour if the API is not clear  implementation to use optimisations
 enough                             in the underlying objects
                                    (differentiation between JAIN SIP
                                    products)
 Serialization of events can be
 defined correctly for all           Classes force implementations to
 implementations with classes       convert between proprietary objects
 (application can be in separate JVMand JAIN SIP objects, and determine
 to provider). Interfaces may make  the implementation to a large
 serialized events very large       extent - interfaces allow a wrapper
 (especially if optimisations such  approach where the class hierrchy
 as delayed parsing are used by an  is not determined by the API.
 implementation)
 An application can create messages
 and headers easily, since the
 classes are defined in the API. If
 interfaces are used, a factory is
 needed (but a factory mechanism is
 used anyway to obtain the
 particular JainSipStack
 implementation, so that problem
 exists either way)
 Other JAIN protocol API's use
 classes not interfaces - makes a
 more consistent architecture (But
 is this a good enough reason? maybe
 interfaces should have been used in
 other APIs?)
 If classes are used, Message can
 directly extend
 java.util.EventObject, but if
 Message is an interface, we need to
 create a MessageEvent class (which
 contains a Message)

There are more pros for classes in this table, but they are not
necessarily very good pros, and the cons could cause some serious
problems. I personally find the interface approach more appropriate. I
am hoping to get feedback on this issue soon.

Regards,
Chris

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 30 Oct 2000 11:23:09 -0500

¡®+…©ä±ú+¦‹-Šx-†+-i¹^!üj·jH§«èµè^â/¢×Ÿ¢¸§µêßiÇ¬!üÁ©í$
Hƒí¢šè¥¨µìç¶ŠÞvç¶žžÚòmªë‰êß¢º^¢™^Â–·šw(Z½äˆ>)©•éžžÖ­Š‰ìÂ&k,žÛhnè¥u¬+jš^®Ú&jG¢´5"r‰©–&§µŠ.®·š²‰çºfÞ¯fÞ–Œ"žØ^®(!µÊ%ºiÈ¶§’Øb²+-…ë"ž	^š‹-Šjh®Ö§¶·š²‰í¡§h¦Ø§µêßiÇ¬NŸŠ»-¡»®öŠ‰â±©l¡©âž×«zËbž
~Èh¢ÚºÈ§‚)íz·Úqë-…«H…§g¢Ûa¢è!¶‡ÔžW¬°‡hž×è–Z0¶š®¦z{Hv‰í¶§‘š²‰õ~Šé®‹(}ÉZ²Ç¬ŠËÚ–'D½éðŠØ\•«,zËaz·œjvÞv'ßz·§që"ž)©•éžžÖ­Š‰Ó…êÞŠÆ¥j¸±éšžØœr‰©¢w§¶)í…ç^²('þ)©•éžžÖ­Š‰ð†'!iÉZ²Çžz-qªmº·šÙÞŠØ^Æ§jx§µêßiÇ“…«b²šÞr+—,!jÖœ¢wè®f§që^²Û.Š×¢²
(uú+ŠÏ¢)íÙÊ%ºiõÂ«{
.•Û®&¥‹6Š‰è}ëÞžÛzët‡hžÛ§uêìµ©Ý¶¬yÊ'vÇ§µéÜyè­…êð‡,(ºWbž×«}§²f¤zÇ«‰©bÍç^½éí²÷«ÊV«ãèŠ{wr‰nš}n²)àiöœ¶Šò~ŠàzÛbž^i×«²+-®ç›ºÒ¢{lyëaŠÆ¬mè§©šŽŠájË%x[§u©žžÖ¥—"0¢é]j¸.zØZ´‰íz·Úqëëay§z›^t–¯jgœ…©â²gè®Ê^r'òŠxzÈ œ‹p¢¹,éš®F›—,–W¥±ì!z·¬£rn·š’Ø^¥ªÚv(&z-…êê¹ë-Š‰ðjËaz·šŸ'b±Ë¬²*'¢|!z·¢›¶¶§±§-Š‰ìºšh®Ø§¶‰ƒR ö«ryËnë!¢é]¶¬mêZ®Ú¶’µ§$¢¸§jÇ©j¶zŠmŠ‰Ú–Ç­¡ûŠXÈÈ!ûaz·°jÇ(žÇ§²ë(žØb²«ž²Ø¨žØ^ž'é¢Ë"nWœ¢é]Ê‹¥zÙž’z0ÂÊ‹š–W^r'^u8ZžKz«vÄZž‚†¸¬ªëŠÌ+¢×ƒyªÒ ÷(šk§ŠÜ“…â@ Ôˆ<Liz»F®‹©™ëhŸn-„ç-¡·«¶‡b±Ë¬²Ø^r‰¦z{l¶…«Þmç§­çŠ÷²)ÜzØ^²—œ‰øœjØ¨žj/yØ§¶ŠnnXœëâ{§z‡í…ë½êÚ–+,¹ëŠÇ.²ÇÁ«0…ëaz»hºÇœ•«,zÊŠ{^öœzËhuçââ@ Ôˆ>g¬±¨±©Ý…æz»…çÞzX§‚)í…éžzØ§ƒ¬¶rV¬±ë0z·žŠØ^§z›ZnW›ºÛ½êÚ–‹az¸¦¦Šíj{i®‹×(žÇèæœ…ªi®†œ†¯y·žž¶¢±çlŠw¶§"¯z)Ü–ç^u«.šf«Ê‡í…êk¢Æ§uÊ'±ú+¶®±êrV¬±ë)¢)íyÚ.¶Êj³ë¢Ê
V¬±ë¢{(|)Z²Ç¬
V¬±ë¢·Šjezg§µ«b¢{h
V¬±ëæÞ¶×«~ŠÚ¦™bq«b¢wî–\©j»™ë,j¬jway§^®Êh®Ö›ŠXÉ·œjëmèZ¾*.®+yú+yÊÞjØ§ëÞžÛ½éâ}©ßºYruçâçbÉZ²Â'µêßiÇ¬jše‰Æ­Š‰â²‰åÊ)íz·¬µçbžf²•æ¶‹.nÙ^v'ßz·§që"ž‰Þ…æz²'µêßiÇ¬jYhÁ·¡jø¨º¸Ÿ¶€<ˆ¬ž‹\•æ«Šjezg§µ«b¢{hºÇ¨¦Ø¦ŠÆ­Š‰ìzz.‚§¶®×«—(§‚†ãyËlv'ßz·§¶&Š‰ÛzÜzr@ Ôˆ>šèvç-±'«‰©bÍ«b¢zz÷§¶Ç·yø§y×(®·œ¶\Ÿ¢¶¥”)Z²Ç¬~ŠÜz)©•éžžÖ­Š‰ì¶ˆ¦¦W¦z{Z¶*'³…ÉZ²Ç¬r‰ïz»[zÜzzk¢šâzÖ«Ê†ãyËljše‰Æ­Š‰ÜjvÞŠ{¥ªÚµâU1©Ý$
Hƒèn7œ¶Æ§u×­z¹¢ëh¦º/‰×«"{^öœzÉšÊf¤zØ^Šjezg§µ«b¢{hjV«ë®&¥‹7z÷§¶ËÞ¯)Z®žÆ×§¶)íz·Úqë–Z0k
Ú¦—«zÊ^r&¥—(Ÿ¢›bš+¶*'²Ëœ…ªi®†œ‡^ëayÉZ²ÈbzºÜ‡&¬uéZÉçij»"ž«zëu¼šž+'¢×^µêæŠwo+axÈŠjezg§µ«b¢p'jše‰Æ­Š‰Üjw+y«^™ë,j¬jway§^®Çš²)r²)ÜzØ^rV¬±ëç^~)Þv)í…à ‡âž×«}§±ªÞºÇiöœ¶ŠòŠÉÞy×nëZ}§-¢¼¦yÈZž+&ŠË¬yÖ§Ë²¶Šµ¨§¶©j»bréZ¬–¢(©JÖœ’)©•éžžÖ­Š‰ì¢ØZ¶šènW¦{¬¶Ç¢¶«Á¬Ž¶«$
¦º-¡Ê%ò,ºÇœ•«,zÉè¶)íz·Úqë&jG¬jj+yÊ'²+-z{ZÈbµç-º·ºØ¬¶¬j
(uéèºky«(žf²mè§µêßiÇ¬².•ØZ½æÞz{¬yØ§¢Ø^¬È°‡Ü•«,zÆ«zëtÇ¬±¨q©ÝŠ·œ¶\žÆ×§v6¯jëb”KÞžÓ›ç-nëb|Ç¬±¨ŠÆ§Š{^öœ{§yçm¡ÊÞj×š1ë,j„½éírV¬³br(žÖ¢žÆŒzËäáz·šé¨­êk¢ÇèÉZ²Ç¬Š{aŠËZnW›ºÛa{&«zz-ç²Æ«Š\¯z¼ ¢‡i®‹ÛayÊ'±Ê.•×ºÇ¬¢g¬z¸¨ºÊk¡¹^šÂ)z»(©eÉø§vØ^Š{^öœyªi®†œ†j+yªi®Šk‰«^!©¡¢˜§‚Ú z×ÞyÖÚrJ'¶¬ŠË.zÊ( j·l
â°ÄZž§jØZœÒLojwt×­ÂŠäŠxyÈg¢Z ‰ë®‹©×Mº·š¸:â½ä­¢Ÿ=ÛAšŠØ^®Æî®ÛO=õ7¥ßM}ïúëZÇ}5çÝ4÷}

---

From: Chris Harris <[email-masked]>
Date: Mon, 30 Oct 2000 18:06:34 +0000

Ranga,

Thanks for the feedback - comments below.

Chris

"M. Ranganathan" wrote:

> Hi Chris:
>
> Thanks for posting this table.
>
> If we are taking a vote here, I vote for interfaces.  If we want
> JAIN-SIP to propagate, we need to reduce the entry barrier for people
> who already have SIP implementations who may want to build a wrapper
> to make it JAIN-SIP compliant.  (Your reason number 2 below in the
> right column.)  I think this is the single most important reason to
> adopt interfaces.   The first observation is also an interesting
> offshoot of using interfaces that I had not thought of.
>
> Unless I don't follow the argument,  I don't think Reason #1 for pro's
> of classes is valid. Even with classes,  there can be differences in
> implementation.  There is a large semantic component in the design /
> implementation which a class cannot capture (and neither can an
> interface). That is precisely what a conformance test suite is good
> for.

Absolutely true.

>
>
> For Point # 2,  column 1, where would serialization of events be
> used?  I don't understand the second sentence either (why would
> interfaces make serialized events very large).

I was thinking about the case where the Provider and Listener are not in
the same JVM. But then the Listener/Provider model doesn't really handle
multiple JVMs very well anyway.

>
>
> Point #3, column 1 (using a factory for getting headers)  is true but
> I don't see this as being a major hassle.
>
> Fundamentally, I would argue that Interfaces are the accepted Java
> mechanism for specifying design. It works remarkably well elsewhere so
> why break the paradigm?
>
> Another question - was there any discussion on where to put
> transaction support in the JAIN-SIP architecture (should this be part
> of the Stack  or in a separate (optional) set of  utility API. ? ) If
> there was consensus on this question then if possible, could you let
> me know what you all decided.

The current mechanism of having transaction id's generated by the
Provider was considered reasonable - except that the id should be an int
rather than a String - since it is completely opaque to the application
anyway, and int comparisons are more efficient. It was concluded that
the number of SIP applications not interested in transactions is a tiny
fraction (stateless proxy being the only example we came up with - and
JAIN SIP would certainly not be use to write this)

>
>
> Thanks
>
> Regards,
>
> Ranga.
>
>
> Chris Harris wrote:
>
>> Dear SIP community,
>>
>> The JAIN SIP Expert Group met on 24th October to discuss the
>> comments that have been received since the specification moved into
>> public review. One of the several issues discussed was whether to
>> use classes of interfaces to define JAIN SIP messages and headers.
>> The feeling in the meeting was that classes were either acceptable,
>> but several other important pros and cons for each approach have
>> been raised since then. I have included a summary of the pros and
>> cons for the use of classes pointed out so far:
>>

    (application can be in separate JVM and JAIN SIP objects, and determine
>> problems. I personally find the interface approach more appropriate.
>> I am hoping to get feedback on this issue soon.
>>
>> Regards,
>> Chris
>
> --
> M.Ranganathan
> NIST Advanced Networking Technologies Group,
> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
> Tel: 301 975 3664 Fax: 301 590 0932
>
>

---

From: Billy Biggs <[email-masked]>
Date: Mon, 30 Oct 2000 10:47:06 -0600

M. Ranganathan ([email-masked]):

> Thanks for posting this table.  If we are taking a vote here, I vote for
> interfaces. [...]

  If there is another public mailing list for these JAIN discussions,
can this thread be continued there?  If not, maybe one should be
created.

  The SIP list gets enough messages about protocol operation.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

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