<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Technology and fun</title>
	<atom:link href="http://technfun.wordpress.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://technfun.wordpress.com</link>
	<description>software development and computer gaming</description>
	<lastBuildDate>Tue, 27 Oct 2009 02:56:58 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Lands of Lore: throne of chaos by JoanTheDark</title>
		<link>http://technfun.wordpress.com/2007/12/18/lands-of-lore-throne-of-chaos/#comment-449</link>
		<dc:creator>JoanTheDark</dc:creator>
		<pubDate>Tue, 27 Oct 2009 02:56:58 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/2007/12/18/lands-of-lore-throne-of-chaos/#comment-449</guid>
		<description>Hey there, I liked the ways to cheat this game with hexadecimal editors. And all thanks to you. I didn&#039;t know I could play with Dawn and now that I realized it, I want to make a step further. 

I was wondering if I can make the second and the third character with characters like Ak&#039;shel and Michael (My primary is Kieran, so I can have all Strength, Magic, and Fast at the same time, being in the beggining of the game) I tried it and I can do it. The only problem is that when I want them to say something, it only talks the first character (Kieran). Can I make them talk? Thank you!

PS: I know this was posted on 2007, I&#039;m a little bit late for this, but I hope you can help me!</description>
		<content:encoded><![CDATA[<p>Hey there, I liked the ways to cheat this game with hexadecimal editors. And all thanks to you. I didn&#8217;t know I could play with Dawn and now that I realized it, I want to make a step further. </p>
<p>I was wondering if I can make the second and the third character with characters like Ak&#8217;shel and Michael (My primary is Kieran, so I can have all Strength, Magic, and Fast at the same time, being in the beggining of the game) I tried it and I can do it. The only problem is that when I want them to say something, it only talks the first character (Kieran). Can I make them talk? Thank you!</p>
<p>PS: I know this was posted on 2007, I&#8217;m a little bit late for this, but I hope you can help me!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Making Win32 GUI applications in OCaml by Anonymous</title>
		<link>http://technfun.wordpress.com/2007/06/15/making-win32-gui-applications-in-ocaml/#comment-448</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Thu, 15 Oct 2009 16:11:20 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/2007/06/15/making-win32-gui-applications-in-ocaml/#comment-448</guid>
		<description>yeahHHHH</description>
		<content:encoded><![CDATA[<p>yeahHHHH</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Networking in Java: non-blocking NIO, blocking NIO and IO by Scott</title>
		<link>http://technfun.wordpress.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/#comment-447</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Wed, 09 Sep 2009 04:34:28 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=120#comment-447</guid>
		<description>thanks for your post... java nio is not that complicated.  i was wondering if it would work without reading a 100 page framework doc, thanks for your encouragement.  maybe a lot of programmers are obsessed with creating and consuming 4 letter frameworks to fill up resumes.

It seems if an application is important enough to use nio one probably can justify spending the time optimizing the number of thread,etc to match the application and server hardware.  incredible how many hundred of thousands of servers are wasted in the server farms because of threaded i/o.</description>
		<content:encoded><![CDATA[<p>thanks for your post&#8230; java nio is not that complicated.  i was wondering if it would work without reading a 100 page framework doc, thanks for your encouragement.  maybe a lot of programmers are obsessed with creating and consuming 4 letter frameworks to fill up resumes.</p>
<p>It seems if an application is important enough to use nio one probably can justify spending the time optimizing the number of thread,etc to match the application and server hardware.  incredible how many hundred of thousands of servers are wasted in the server farms because of threaded i/o.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Legend of seven paladins by Rock&#8217;n Shaolin: Legend of the Seven Paladins 3D &#187; The Obscuritory</title>
		<link>http://technfun.wordpress.com/2007/06/07/legend-of-seven-paladins/#comment-446</link>
		<dc:creator>Rock&#8217;n Shaolin: Legend of the Seven Paladins 3D &#187; The Obscuritory</dc:creator>
		<pubDate>Wed, 09 Sep 2009 01:52:36 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/2007/06/07/legend-of-seven-paladins/#comment-446</guid>
		<description>[...] and other non-essentials, so the controls and plot weren&#8217;t immediately obvious. One blog thanklessly offered the convoluted controls, apparently involving a number of strange but ultimately [...]</description>
		<content:encoded><![CDATA[<p>[...] and other non-essentials, so the controls and plot weren&#8217;t immediately obvious. One blog thanklessly offered the convoluted controls, apparently involving a number of strange but ultimately [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Tracing facilities and tools for Unix by whitelassiblog</title>
		<link>http://technfun.wordpress.com/2009/05/28/tracing-facilities-and-tools-for-unix/#comment-445</link>
		<dc:creator>whitelassiblog</dc:creator>
		<pubDate>Sun, 30 Aug 2009 09:06:02 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=172#comment-445</guid>
		<description>There is one Linux open source project that i love. 

Its call Linux Virtual Server (LVS), to provide HA and VIP failover out of the box at the OS level. I have found it useful from a telco product point of view and used it to provide VIP failover for JBOSS AS.</description>
		<content:encoded><![CDATA[<p>There is one Linux open source project that i love. </p>
<p>Its call Linux Virtual Server (LVS), to provide HA and VIP failover out of the box at the OS level. I have found it useful from a telco product point of view and used it to provide VIP failover for JBOSS AS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A study on Java APIs for SIP. Part 1: JAIN SIP API by kmatveev</title>
		<link>http://technfun.wordpress.com/2009/05/15/java-sip-2/#comment-444</link>
		<dc:creator>kmatveev</dc:creator>
		<pubDate>Thu, 20 Aug 2009 08:34:00 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=138#comment-444</guid>
		<description>Hi!

1. The debate where is a border between stack and application is a long one. Let&#039;s do it one more time.

There are three layers which I can see: stack, container and application, each one has clear responsibilities. Stack handles protocol-level logic, application handles business logic, container &quot;manages&quot; them: wires them together (sets application as listener of stack) and controls their lifecycle. JAIN SIP API is an API between stack and container+application. SIP Servlets API is an API between stack+container and application. 

You say that &quot;If you are developing a SIP Proxy server, you are the Transaction User (TU)&quot;. Yes, I know that. I suppose you mean that criteria is that &quot;Stack is everything below TU&quot;. But this is not the case for JAIN SIP API. This API supports dialogs, which are also part of TU layer. I strongly suspect that JAIN SIP API doesn&#039;t have a real criteria of what should be a part of stack: they just include features they feel nesessary.

You say that &quot;The SIP Stack cannot govern your application’s business logic whether you wish to use dialogs or not, whether you are transaction stateful or stateless etc)&quot; - I totally agree, and I never said the opposite. When I say that stack should support proxying, then I mean that it is application who will decide if message will be handled in UAS way, B2BUA way or Proxy way. But I believe that inventing proxy over and over again in applications is a bad idea, especially because proxying is so well specified. And I don&#039;t see how support of proxying turns SipServlet API into &quot;app server/container&quot; type.

So, I again say that stack having features from TU layer such as suport of dialogs and support of proxying is a good thing. It is stack which is re-usable, and application which is volatile.

And I totally agree that Sip Servlets API is not a generic stack, but an application server. You cannot build a softphone on it. My idea of &quot;perfect&quot; stack is that it will be even more powerful and easy to use as SipServlet container, but without &quot;container&quot; module and overhead of &quot;enterprize features&quot; like deployment. Such stack could be used in building both desktop applications and enterprize applications. A SipServlet layer on top of such stack will be very thin.

2. I&#039;ll do it

3. I meant that JAIN SIP API doesn&#039;t allow you to implement fault tolerance in portable way. Your example applies only to NIST implementation.

4. I&#039;m sorry, but this doesn&#039;t convince me. Even if they &quot;are top vendors in this space&quot;, such stack management is shit. One interface is enough. SipProvider and ListeningPoint are bad. Three entities instead of one: this brings relationships between them. Why overcomplicate things?

5. Like in 3, I meant an API feature, not a NIST stack feature.

6. Thank you for that information, I didn&#039;t new that. So, JAIN SIP RA includes both protocol-level features and SLEE-specific features. In my opinion, this is not good. RA should contain only SLEE-specific features, and all protocol-level features should be part of stack. This is my opinion about modular design: functionality of one type is in one module, and different funcitonalities are in separate modules.

Please come back, nice to talk with you!</description>
		<content:encoded><![CDATA[<p>Hi!</p>
<p>1. The debate where is a border between stack and application is a long one. Let&#8217;s do it one more time.</p>
<p>There are three layers which I can see: stack, container and application, each one has clear responsibilities. Stack handles protocol-level logic, application handles business logic, container &#8220;manages&#8221; them: wires them together (sets application as listener of stack) and controls their lifecycle. JAIN SIP API is an API between stack and container+application. SIP Servlets API is an API between stack+container and application. </p>
<p>You say that &#8220;If you are developing a SIP Proxy server, you are the Transaction User (TU)&#8221;. Yes, I know that. I suppose you mean that criteria is that &#8220;Stack is everything below TU&#8221;. But this is not the case for JAIN SIP API. This API supports dialogs, which are also part of TU layer. I strongly suspect that JAIN SIP API doesn&#8217;t have a real criteria of what should be a part of stack: they just include features they feel nesessary.</p>
<p>You say that &#8220;The SIP Stack cannot govern your application’s business logic whether you wish to use dialogs or not, whether you are transaction stateful or stateless etc)&#8221; &#8211; I totally agree, and I never said the opposite. When I say that stack should support proxying, then I mean that it is application who will decide if message will be handled in UAS way, B2BUA way or Proxy way. But I believe that inventing proxy over and over again in applications is a bad idea, especially because proxying is so well specified. And I don&#8217;t see how support of proxying turns SipServlet API into &#8220;app server/container&#8221; type.</p>
<p>So, I again say that stack having features from TU layer such as suport of dialogs and support of proxying is a good thing. It is stack which is re-usable, and application which is volatile.</p>
<p>And I totally agree that Sip Servlets API is not a generic stack, but an application server. You cannot build a softphone on it. My idea of &#8220;perfect&#8221; stack is that it will be even more powerful and easy to use as SipServlet container, but without &#8220;container&#8221; module and overhead of &#8220;enterprize features&#8221; like deployment. Such stack could be used in building both desktop applications and enterprize applications. A SipServlet layer on top of such stack will be very thin.</p>
<p>2. I&#8217;ll do it</p>
<p>3. I meant that JAIN SIP API doesn&#8217;t allow you to implement fault tolerance in portable way. Your example applies only to NIST implementation.</p>
<p>4. I&#8217;m sorry, but this doesn&#8217;t convince me. Even if they &#8220;are top vendors in this space&#8221;, such stack management is shit. One interface is enough. SipProvider and ListeningPoint are bad. Three entities instead of one: this brings relationships between them. Why overcomplicate things?</p>
<p>5. Like in 3, I meant an API feature, not a NIST stack feature.</p>
<p>6. Thank you for that information, I didn&#8217;t new that. So, JAIN SIP RA includes both protocol-level features and SLEE-specific features. In my opinion, this is not good. RA should contain only SLEE-specific features, and all protocol-level features should be part of stack. This is my opinion about modular design: functionality of one type is in one module, and different funcitonalities are in separate modules.</p>
<p>Please come back, nice to talk with you!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on SIP stories, part 3: INVITE retransmission by whitelassiblog</title>
		<link>http://technfun.wordpress.com/2008/11/06/sip-stories-part-3-invite-retransmission/#comment-443</link>
		<dc:creator>whitelassiblog</dc:creator>
		<pubDate>Sat, 15 Aug 2009 09:22:13 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=103#comment-443</guid>
		<description>excellent !</description>
		<content:encoded><![CDATA[<p>excellent !</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A study on Java APIs for SIP. Part 1: JAIN SIP API by whitelassiblog</title>
		<link>http://technfun.wordpress.com/2009/05/15/java-sip-2/#comment-442</link>
		<dc:creator>whitelassiblog</dc:creator>
		<pubDate>Sat, 15 Aug 2009 09:02:55 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=138#comment-442</guid>
		<description>PS: When i said that forking proxies are a kind of app servers, i meant that they are a kind of UAC core / proxy servers. I didn&#039;t mean that they require a JSLEE/Sip Servlet app server to be implemented.</description>
		<content:encoded><![CDATA[<p>PS: When i said that forking proxies are a kind of app servers, i meant that they are a kind of UAC core / proxy servers. I didn&#8217;t mean that they require a JSLEE/Sip Servlet app server to be implemented.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A study on Java APIs for SIP. Part 1: JAIN SIP API by whitelassiblog</title>
		<link>http://technfun.wordpress.com/2009/05/15/java-sip-2/#comment-441</link>
		<dc:creator>whitelassiblog</dc:creator>
		<pubDate>Sat, 15 Aug 2009 08:56:46 +0000</pubDate>
		<guid isPermaLink="false">http://technfun.wordpress.com/?p=138#comment-441</guid>
		<description>Hello,

Sorry for the late response. Nice posts..

1. The proxy facility is not the function of the SIP Stack. A SIP proxy resides on top of the transaction layer of the stack (if its stateful). If you are developing a SIP Proxy server, you are the Transaction User (TU). 

If the stack starts providing utilities to implement proxy behavior, it will not remain just a stack. It will start resembling a container, which it is not. I agree that Inversion of Control is one of the many characteristics of a framework. 

However, according to me, in addition to IoC, once a software component starts deciding the life cycle, sequencing and behavior of your application logic, then it becomes a framework. The SIP Stack is only providing you with the SIP messages. What you do with them and how you do it is the part of the application logic. 

The SIP Stack cannot govern your application&#039;s business logic (whether you wish to use dialogs or not, whether you are transaction stateful or stateless etc) , it can only assist the application by providing a &#039;standard&#039; interface to communicate with other SIP entities and exposing a friendly API to go about creating requests/responses and dialogs. 

Just like you mentioned in the point about the SIP Servlet API (and its implementation in the form of a container), in your response above, it is important to note that it is a full application server..and not a  generic SIP Stack. If you look at the Mobicents SIP Servlets implementation, they also &#039;build upon&#039; the JAIN SIP Stack to provide the application (SIP Servlet) with proxy utilities and even B2BUA utilities. It even provides utilities to route sip messages, STUN support, DNS utilities etc that contribute to the ease of development even if the developer has modest knowledge of SIP.

2. When the stack creates a transaction for a request, it stores the original request as part of the transaction context for retransmissions (to be sent by the CT or filtered at the ST). At the application, you need to get the request from the transaction, clone it and then work on it (add/remove headers, decrement max forwards etc). If there are more holes, it will be very nice to dedicate a post for it. It will be worth it and will be for the better of the community.

3. For fault tolerance, you need not override the stack layers/or behavior. As for example, if you need fault tolerant dialogs, you will first need to use a transactional cache (such as JBOSS cache) and simply cache the created dialog object and then retrieve it later like this from the application and re-create it in the stack:

//a. Get the dialog object from the Persistent Cache like JBOSS Cache here.

//b. Set the SipProvider for the Dialog like this:
((SIPDialog)dialog).setSipProvider((SipProviderImpl)sipProvider);

//c. Put the dialog in the SIP stack&#039;s dialog table here:                 ((SipStackImpl)sipProvider.getSipStack()).putDialog((SIPDialog)null);

Where is the need for overriding the stack&#039;s behavior here ? 

4. Listeners, Providers etc are present in every stack. I have worked with SIP Stacks from 3 more vendors (implemented in C++). They are top vendors in this space. Stack management in their products was similar to what JAIN SIP provides &#039;conceptually&#039;. 
By the way, why do you wish to add/remove listening points at runtime? You have a multi-homed host?  It is possible in JAIN SIP to create/delete Listening Points and Sip providers at runtime. Refer to this: http://snad.ncsl.nist.gov/proj/iptel/jain-sip-1.2/javadoc/javax/sip/SipStack.html 

5. Message Parsing is already happening at the SIP Stack. What i understand is that you want the stack to provide a more friendly API to return the Start line well parsed with the SIP version, method, request line separately using getters. This is also being done at the Stack. 

Use the getters of the RequestLine object to get the sip version, uri, method etc like this: 

 Request request = requestEvent.getRequest(); 
       Request testing = requestEvent.getRequest();
          RequestLine line = ((SIPRequest)testing).getRequestLine();

       System.out.println(line.getMethod());
       System.out.println(line.getSipVersion());
       System.out.println(line.getUri());

6. Nice post. If for once we start calling the SIP Stack a framework, even then functions such as proxying, or other helper utilities are outside its scope. As per 3261, it is the responsibility of the Transaction User (TU). 

7. The JAIN SLEE SIP RA contains protocol logic. Refer to Appendix D a of JSR 240. It has its own transparent handling of request cancellation and also request forking. The SIP RA also fires the DialogForked events, characterized by javax.sip.Dialog.FORKED net.java.slee 1.2  event type. The SIP RA also provides an API to create dialogs at the stack and activities at the RA. The DialogActivity interface of the SIP RA provides dialog management utilities..like associating SIP transactions to dialogs, creating requests and responses that need to be sent in-dialog etc. All these protocol specific utilities are provided in the SIP RA SBB interface and are documented in the specification. If you look at appendix section D.12.1, it provides the entire state machine implemented at the SIP RA for its internal dialog management, which of course matches the states given in 3261. Section D.14.3 shows the SIP RA&#039;s implementation of forking behavior and its FSM. 

Thus the RA is indeed an architectural framework of the JSLEE standard and is not just a plain adaptation layer for the JSIP API. It can encapsulate any network protocol (standard or proprietary), and provides a well defined life cycle for all its activities and passes events of interests to event router. It influences the application&#039;s behavior by asking it to attach/detach to activity contexts, that the SLEE container maps from the Resource Adaptor. If we remove the RAs from the JSLEE container, it will be rendered redundant. Thats why i call it as part of a framework. The Container cannot be used without the RA.</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>Sorry for the late response. Nice posts..</p>
<p>1. The proxy facility is not the function of the SIP Stack. A SIP proxy resides on top of the transaction layer of the stack (if its stateful). If you are developing a SIP Proxy server, you are the Transaction User (TU). </p>
<p>If the stack starts providing utilities to implement proxy behavior, it will not remain just a stack. It will start resembling a container, which it is not. I agree that Inversion of Control is one of the many characteristics of a framework. </p>
<p>However, according to me, in addition to IoC, once a software component starts deciding the life cycle, sequencing and behavior of your application logic, then it becomes a framework. The SIP Stack is only providing you with the SIP messages. What you do with them and how you do it is the part of the application logic. </p>
<p>The SIP Stack cannot govern your application&#8217;s business logic (whether you wish to use dialogs or not, whether you are transaction stateful or stateless etc) , it can only assist the application by providing a &#8217;standard&#8217; interface to communicate with other SIP entities and exposing a friendly API to go about creating requests/responses and dialogs. </p>
<p>Just like you mentioned in the point about the SIP Servlet API (and its implementation in the form of a container), in your response above, it is important to note that it is a full application server..and not a  generic SIP Stack. If you look at the Mobicents SIP Servlets implementation, they also &#8216;build upon&#8217; the JAIN SIP Stack to provide the application (SIP Servlet) with proxy utilities and even B2BUA utilities. It even provides utilities to route sip messages, STUN support, DNS utilities etc that contribute to the ease of development even if the developer has modest knowledge of SIP.</p>
<p>2. When the stack creates a transaction for a request, it stores the original request as part of the transaction context for retransmissions (to be sent by the CT or filtered at the ST). At the application, you need to get the request from the transaction, clone it and then work on it (add/remove headers, decrement max forwards etc). If there are more holes, it will be very nice to dedicate a post for it. It will be worth it and will be for the better of the community.</p>
<p>3. For fault tolerance, you need not override the stack layers/or behavior. As for example, if you need fault tolerant dialogs, you will first need to use a transactional cache (such as JBOSS cache) and simply cache the created dialog object and then retrieve it later like this from the application and re-create it in the stack:</p>
<p>//a. Get the dialog object from the Persistent Cache like JBOSS Cache here.</p>
<p>//b. Set the SipProvider for the Dialog like this:<br />
((SIPDialog)dialog).setSipProvider((SipProviderImpl)sipProvider);</p>
<p>//c. Put the dialog in the SIP stack&#8217;s dialog table here:                 ((SipStackImpl)sipProvider.getSipStack()).putDialog((SIPDialog)null);</p>
<p>Where is the need for overriding the stack&#8217;s behavior here ? </p>
<p>4. Listeners, Providers etc are present in every stack. I have worked with SIP Stacks from 3 more vendors (implemented in C++). They are top vendors in this space. Stack management in their products was similar to what JAIN SIP provides &#8216;conceptually&#8217;.<br />
By the way, why do you wish to add/remove listening points at runtime? You have a multi-homed host?  It is possible in JAIN SIP to create/delete Listening Points and Sip providers at runtime. Refer to this: <a href="http://snad.ncsl.nist.gov/proj/iptel/jain-sip-1.2/javadoc/javax/sip/SipStack.html" rel="nofollow">http://snad.ncsl.nist.gov/proj/iptel/jain-sip-1.2/javadoc/javax/sip/SipStack.html</a> </p>
<p>5. Message Parsing is already happening at the SIP Stack. What i understand is that you want the stack to provide a more friendly API to return the Start line well parsed with the SIP version, method, request line separately using getters. This is also being done at the Stack. </p>
<p>Use the getters of the RequestLine object to get the sip version, uri, method etc like this: </p>
<p> Request request = requestEvent.getRequest();<br />
       Request testing = requestEvent.getRequest();<br />
          RequestLine line = ((SIPRequest)testing).getRequestLine();</p>
<p>       System.out.println(line.getMethod());<br />
       System.out.println(line.getSipVersion());<br />
       System.out.println(line.getUri());</p>
<p>6. Nice post. If for once we start calling the SIP Stack a framework, even then functions such as proxying, or other helper utilities are outside its scope. As per 3261, it is the responsibility of the Transaction User (TU). </p>
<p>7. The JAIN SLEE SIP RA contains protocol logic. Refer to Appendix D a of JSR 240. It has its own transparent handling of request cancellation and also request forking. The SIP RA also fires the DialogForked events, characterized by javax.sip.Dialog.FORKED net.java.slee 1.2  event type. The SIP RA also provides an API to create dialogs at the stack and activities at the RA. The DialogActivity interface of the SIP RA provides dialog management utilities..like associating SIP transactions to dialogs, creating requests and responses that need to be sent in-dialog etc. All these protocol specific utilities are provided in the SIP RA SBB interface and are documented in the specification. If you look at appendix section D.12.1, it provides the entire state machine implemented at the SIP RA for its internal dialog management, which of course matches the states given in 3261. Section D.14.3 shows the SIP RA&#8217;s implementation of forking behavior and its FSM. </p>
<p>Thus the RA is indeed an architectural framework of the JSLEE standard and is not just a plain adaptation layer for the JSIP API. It can encapsulate any network protocol (standard or proprietary), and provides a well defined life cycle for all its activities and passes events of interests to event router. It influences the application&#8217;s behavior by asking it to attach/detach to activity contexts, that the SLEE container maps from the Resource Adaptor. If we remove the RAs from the JSLEE container, it will be rendered redundant. Thats why i call it as part of a framework. The Container cannot be used without the RA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on About by Alekh</title>
		<link>http://technfun.wordpress.com/about/#comment-440</link>
		<dc:creator>Alekh</dc:creator>
		<pubDate>Tue, 11 Aug 2009 11:16:36 +0000</pubDate>
		<guid isPermaLink="false">#comment-440</guid>
		<description>Hello friend

I came across your blog while surfing the internet on sip. nice work sir !!
I am a student doing graduation and now I m in my final yr.I am having &quot;sip client&quot; as my final yr project. I am beginner as a developer. so sir I want your help.
I want to know what I have to do,and read i order to develop a sip client.

Thanks 
Alekh</description>
		<content:encoded><![CDATA[<p>Hello friend</p>
<p>I came across your blog while surfing the internet on sip. nice work sir !!<br />
I am a student doing graduation and now I m in my final yr.I am having &#8220;sip client&#8221; as my final yr project. I am beginner as a developer. so sir I want your help.<br />
I want to know what I have to do,and read i order to develop a sip client.</p>
<p>Thanks<br />
Alekh</p>
]]></content:encoded>
	</item>
</channel>
</rss>
