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
