<html><body>
<p>Hi,<br>
<br>
I have two related questions regarding the presence module's handling of SUBSCRIBE replies. Both questions consider the case where the SUBSCRIBE reply (200 or 202) is lost in the network, and then the client re transmits the SUBSCRIBE message. Upon re-transmission, the request is delivered to the presence module, where it will see a duplicate CSEQ number and respond with 412 errror code. Some (most?) clients treat this as a fatal error and give up.<br>
<br>
1. Why does the module support sending stateless (sl instead of tm) replies to SUBSCRIBE? Prior to Nov 2008, only stateless replies were supported and after Nov 2008 the option of stateless replies exist via the signal module (if script doesn't create transaction). When sending reply statelessly, the retransmission of the request by client will be seen as duplicate CSEQ by presence module with 412 error code. When is this (stateless reply) useful or appropriate?<br>
<br>
2. Why is the default "wt_timer" value only 5sec? If I understand correctly, this timer server as Timer J (of RFC3261) for server-side non-INVITE transactions such as SUBSCRIBE. When handle_subscribe() is wrapped by t_newtrans() and t_release(), re-transmits that arrive 5sec later are not caught by the tm layer (because the transaction has been deleted), and are then delivered to module and again generate 412 error code.<br>
<br>
There are similiar but less severe issues for PUBLISH. With PUBLISH, the stateless reply or stateful 5sec guard reply does cause 412 errror but it does trigger extra NOTIFY messages (I think).<br>
<br>
It seems "correct" behavior requires handling SUBSCRIBE statefully and requires wt_timer to be 32sec. But seems opensips developers have a different way of making things work and I'd like to understand how.<br>
<br>
Thanks,<br>
Kennard</body></html>