RE: Transaction timeouts

Ranga,

IMHO this is not a desirable feature: it encourages people to violate RFC3261 (aborting retransmissions), and a retransmission is not the same as a port unreachable. This breaks recovery from UDP packet loss

What applications may want to have is statistics (including retransmissions)

Regards,
Jeroen


-----Oorspronkelijk bericht -----
Van: "M. Rangnathan" <[email protected]>
Aan: "M. Rangnathan" <[email protected]>
CC: "Jeroen van Bemmel" <[email protected]>; "Andrew T Gin" <[email protected]>; [email protected]
Verzonden: 27-2-07 03:44
Onderwerp: Re: [nist-sip] Transaction timeouts

Well OK it took a few minutes to  put this feature in so there it is. 
Now you can solicit for retransmission notifications on client 
transactions ( although the stack actually does the retransmission ).

Here it is :

SIPClientTransaction.setNotifyOnRetransmit ( boolean  )


Its pretty simple. You just get notificatoin of a retransmission from 
the client transaction but the retransmission is actually done by the 
stack.  I think it does what you want -- it will allow you to kill off 
the transaction early using transaction.terminate if you want. Its 
untested code - give it a try and tell me if it works. I'll try to get 
somethign like it into the next rev of the spec ( assuming that there is 
one ). I can see why it is needed.

Ranga

M. Rangnathan wrote:

> Will that work? You need multiple sockets unles all you ever do is 
> talk to a single destination. The ICMP is delivered asynchronously and 
> will not be cached unless the socket is bound. Thus when the ICMP 
> comes back the binding better not have changed in the meanwhile. If it 
> does the ICMP is dropped I believe and hence the solution will not