Hello, Having implemented session timers in one b2bua, and currently facing same requirement with another b2bua, we are asking ourselves the question "why?". We needed only to release stale sessions. Why then had we bothered with assymetric 3pcc-style re-INVITES sent out by b2bua instead of plain "OPTIONS", considering rfc3261 compliance of end points? Definitely, rfc-4028-proposed mechanism describes more advanced handshake, bandwidth-concerned refreshing, when one should drop the connection, etc. But the keep-alive mechanism is essentially for b2buas/proxies, since end points either do or does not have established media session, - the essence they need. If the mechanism is for signalling entities, so why those have to bother with SDP in refresh requests? A re-INVITE may result in getting new SDP in 200 OK, which will bring new round of SDP negotiation between end points by b2bua. Having said that, signalling entity (event if it is an SBC, which terminates media streams) would rather deal with plain OPTIONS refresh requests instead.
I must be missing some significant benefit here, any clarification is appreciated. Alexander. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
