Thank you, Paul, that is helpful. > That is true. But if it happens, it is because one of the endpoints wants it to happen. I suppose an endpoint could be perverse and change something even when it has no need to, but that would be silly. If it does > that it will probably do other perverse stuff too. So I don't think this is a big concern.
It is a concern: 1. 3-step transaction (if we logically attribute ACK to the INVITE transaction) brings more complexity in processing of good flows as well as bed ones, compared to 2-step. 2. SDP update involves updating media session (theoretically they may change), and an implementation may have dependencies if media stream changes (like ongoing voice recodring, mixing/conferencing, supervising, etc), processing of which may add up complexity. Still, b2bua needs to implement this RFC, if it wants to support it, due to the fact the b2bua is also kind of perverse with all the arbitrary switching it may conduct. For instance, if it wants to re-INVITE Leg1-from-call1 with Leg1-from-call2, it should be concerned with possibility of breaking session-timer mechanism on call1 or call2. Alexander. -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 12:47 PM To: Alexander Krassiev Cc: [email protected] Subject: Re: [Sip-implementors] Justification for using RFC-4028 Alexander Krassiev wrote: > Hello, > > Having implemented session timers in one b2bua, and currently facing > same requirement with another b2bua, we are asking ourselves the > question "why?". That is a very good question for you to be asking. I doubt there is a good answer. > 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. The mechanism is really only for proxies. If a proxy is record-routed, and is holding state about the call, then it needs a way to know when to release that state. session-timer provides it with a way when it otherwise had no good options. A B2BUA does not need session-timer because it is in a position to initiate requests within the dialog. It can do exactly the same thing that session-timer calls for (a reinvite) without the need for session-timer. And yes, the B2BUA could also send an OPTIONS instead of a reinvite. > 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. That is true. But if it happens, it is because one of the endpoints wants it to happen. I suppose an endpoint could be perverse and change something even when it has no need to, but that would be silly. If it does that it will probably do other perverse stuff too. So I don't think this is a big concern. > Having said that, signalling entity (event if it is an SBC, which > terminates media streams) would rather deal with plain OPTIONS refresh > requests instead. As noted above, an entity that terminates sip signaling (such as an SBC) is quite free to forego session-timer and use whatever signaling it likes, at whatever intervals it likes, to test the liveness of the session. One could second guess whether session-timer could have used OPTIONS. But that is water over the dam. Session timer was proposed eons ago, and just happened to take terribly long to reach a conclusion. By then people were more interested in getting it done than in making it better. There are precious few cases in which it should be interesting. I am pretty sure your case is not one of those. > I must be missing some significant benefit here, any clarification is > appreciated. Does the above help? Paul > Alexander. > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
