Re: Transaction timeouts

Andrew T Gin wrote:

> Hi
>
>> You can be informed of retransmission alerts on the Server 
>> transaction. See ServerTransaction.enableRetransmissionAlerts. On the 
>> client side of the transaction, there is no retransmission alert.
>
> I'm interested in the reasoning behind this :)


We did not think it was necessary. What is the use case? On the server 
side, if you want to remain true to RFC 3216, the server retransmits 
till ACK

>>>     timeOutEvent) method only ever receives Timeout.TRANSACTION timeout
>>>     events. How do I make it so my application is notified of 
>>> retransmit
>>>     timeouts? Are they received at processTimeout?
>>>
>>>     When the destination host is unreachable, the application gets ICMP
>>>     unreachable replies to each UDP retransmission. Is it possible 
>>> to be
>>>     notified *immediately* when the destination is unreachable?
>>>
>> Let me think of this a bit. I could use the public void 
>> processIOException(IOExceptionEvent exceptionEvent)   event 
>> notification mechansm for this.  How does the UDP socket see this. I 
>> think I would have to use  SOCTL to enable ICMP  packets to be seen 
>> right ?. Is the feature available on J1.42 ? If not it becomes a J 5 
>> only thing which I want to avoid if possible. I will take a look to 
>> see if I can hook this in but some hacking from you would speed the 
>> process. See if you can hack UDPMessageChannel to get notifications 
>> for ICMP packets. Call a dummy method when you get the necessary 
>> notificaiton. I'll take it from there.
>
> So it doesn't appear to be a current way to do it? I was more 
> interested in whether this was possible with the current 
> implementation. Ill just try work around it :D THanks for your efforts!


No there is not but there should be. Its an important feature that is 
missing. Figure out how to read ICMP messages from the UDP socket 
imbedded in UDPMessageChannel. If needed, we can make a 1.5 only feature 
that allows you to inform the application asynchronously when an ICMP 
notification comes along. If you find a work around , share it here and 
we can figure out how to make it work in the stack.

>
> Currently, TCP 'io exceptions' do not go through processIOException; 
> they are caught as a SIP exception in the try catch block of each 
> method. So if the UDP "io exception" implemented should they be 
> treated the same?


Are you using JSIP 1.2 ? If so, IO Exceptions should be reported as 
IOExceptions. If not there is a bug.


>> That would be in violation of the SIP transaction state machine - 
>> something that I want to avoid. You can try implementing the 
>> setBaseTimer on SipProvider ( currently disabled  -- throws 
>> UnsupportedOperation).
>
> So this is a 'requirement' of SIP? I guess so from the RFC. Again I'll 
> work around this. THanks again!
>
>>>
>>>     Thanks for your help, I'm usually a bit sceptical of mailing 
>>> lists, as
>>>     questions usually go unanswered, so even if I happen to  find 
>>> someone
>>>     else with the exact same problem, sometimes there are no replies!
>>
>> Have faith. :-)
>
> What I meant here was that this Jain-SIP project is practically a 
> model of how all projects should be! Active support, quick replies, a 
> working implementation, and most importantly, comprehensive 
> documentation!


Ah! I should put this up on the user experiences page. :-)

>
> Thanks for all your help so far! I'll make sure to acknowledge you all 
> in my thesis :)


Thanks. Keep hacking till you get there. :-)

Ranga

> Andrew
>


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!