Victor Pascual Ávila wrote:
> 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.
The fact that it works doesn't imply that it has value.
>> 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
Certainly if you want to request it in your UA, go right ahead.
That may mean that even though you want to verify the session every 5
minutes you will end up doing it only every 5 hours because that is the
minimum the other guy supports.
Or else you will end up doing every 5 hrs for session timer and doing
every 5 mins on your own, independent of session timer, to satisfy your
own requirement. You can certainly do that because there is no
negotiation defined to limit how frequently you may send reINVITE or
UPDATE in general.
There are few if any drawbacks to having each end manage session
verification signaling on its own, at its own rate. If I decide I want
to do every 5 hrs, then each time I receive a message from the other end
I set a timer for 5 hrs. Subsequent received messages reset that timer.
So as long as there is signaling I need not do any extra. If my 5 hr
timer goes off, I send a reINVITE or UPDATE. If I get an acceptable
answer to it I set another 5 hr timer. If not then the session is dead.
The other end can be doing the same thing. If he does so more often,
then I will never need to send anything to do the verification.
The worst thing that can happen is glare if we both send at same time.
Normally that requires backoff and retry. But if I was only sending to
verify the connection then there is no need for me to retry. And same
for other side.
And that assumes you want periodic checks even if things are otherwise ok.
Personally, in a UA with a real user, I think I will rely on the user to
decide things are messed up and hang up, probably based on lack of
media. If the media is flowing to the satisfaction of the user, then
tearing down the call because the signaling has broken will probably not
be appreciated.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
