Re: Transaction timeouts

IIRC you can only learn about ICMP errors if you use a connected UDP socket 
(in Java at least). Unfortunately that means you would need to create a 
socket for each peer, which scales poorly.

Regards,
Jeroen

M. Rangnathan wrote:
> 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