Re: Transaction timeouts

Jeroen,

Actually all this does is alert the application that a retransmit is 
about to happen ( thus allowing the application to log its own stats). 
Transaction.terminate allows you to abort the transaction early.  
Perhaps this is not a good feature for the API to include
and there are better ways  to get statistics. I am open to suggestions. 
This is just a quick hack - lets see if this meets the use case of 
Andrew and Amos.

 You are right - retransmission is not same as port unreachable although 
port unreachable implies your client transaciton will retransmit. I dont 
know how ( or even if ) we need to support port unreachable 
notifications however.  Would be nice to have but it seems to be tough 
to support in general besides being expensive ( one would need multiple 
sockets - one for each destination as you have pointed out and then nat 
boxes would not like that because they want you to use the same socket 
to transmit etc. Lots of painful stuff it seems. )

Regards,

Ranga
Jeroen van Bemmel wrote:

>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 
>>    
>>
>
>
>  
>


-- 
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!