Hi Paul, thanks for your comments. See responses inline. 2009/6/11 Paul Kyzivat <pkyzi...@cisco.com>: > There is really no particular value in using session timers in this case. > Session timer is for the benefit of record-routed proxies.
Since session timer works fine even if only one of the UAs supports it (i.e with no proxy support), I wouldn't say that there's no particular value in using rfc4028 here. > If a UA suspects that there might be a problem it can test the signaling > path by sending an in-dialog message. It could be reINVITE, or UPDATE, or > OPTIONS. OPTIONS isn't a great choice because there is some ambiguity about > whether it should fail when sent "in dialog" and the dialog is gone. So > reINVITE or UPDATE are preferred choices. > > This is pretty much like session timer, but need not be negotiated, and > messages need not be sent on any schedule - just when one end or the other > has a question about the status of the session. For instance, if media has > stopped flowing for awhile, or ICMP messages are being received on the media > stream, an UPDATE can be sent to check the status of the session. I believe it would be better to use an standard(*) mechanism (possibility to negotiate intervals and refresher while it eliminates the OPTIONS ambiguity) which does not assume the UAC/UAS to be handling also the media streams (e.g. B2BUA). In addition, one could also detect scenarios where the session has been released but the media streams are still flowing. (*) SIPit23: 63% of the implementations supported rfc4028 Cheers, -- Victor Pascual Ávila _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
