Alexander Krassiev wrote:
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.
Yes, the B2BUA does need to accomodate session-timer in case something
else in the signaling path wants to use it. I haven't carefully thought
through all the cases, but I think it can arrange to be passive,
allowing the the two endpoints to negotiate with each other who will
take the UAC role and who will take the UAS role.
Paul
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
