[OpenSIPS-Devel] opensips presence: stateless vs stateful and wt_timer value

Kennard_White at logitech.com Kennard_White at logitech.com
Tue Jun 8 02:02:23 CEST 2010



Hi,

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.

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?

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.

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

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.

Thanks,
Kennard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20100607/583a80f3/attachment.htm 


More information about the Devel mailing list