Hello all,

How should a UAC react on a SUBSCRIBE timeout for an existing dialog?
RFC 5057 appears to be in contradiction with RFC 6665 and itself.

Section 4.2 of RFC 5057 says that subscribe usages are destroyed by
refresh-SUBSCRIBE timeout; the tables in Section 5.1, on the other hand,
lists 408 as affecting only the transaction, and notes that "receiving a
408 will have the same effect [..] as a real transaction timeout as
described in Section 5.2."

Section 5.2 says that "a transaction timeout should affect only the
usage in which the transaction occurred", but doesn't really say how. It
just mentions that RFC 3261 requires the UAC to send BYE, and that
according to RFC 3265 SUBSCRIBE timeout does not terminate the usage.

Like RFC 3265, RFC 6665 is quite clear that SUBSCRIBE timeout does not
terminate the usage. Section 4.1.2.2: "If a SUBSCRIBE request to refresh
a subscription fails with any error code other than those listed above,
the original subscription is still considered valid [..]"; 408 is not
listed.


I am inclined to consider the usage as destroyed, as transaction
timeouts generally indicate an issue with the network, and a repeated
SUBSCRIBE is likely to fail again. Timer N is almost useless here, as it
may have been reset by an earlier NOTIFY crossing over with SUBSCRIBE.


Thanks,
Jānis

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to