On 7/3/18 10:34 AM, Alex Balashov wrote:
Yeah, that's true.
It's easily forgot in an applied sense because the mainstream FOSS proxies,
e.g. Kamailio, both support dialog state tracking and issuing various kinds of
in-dialog DPD requests (e.g. OPTIONS), and even support spoofing BYEs to hang
up a dead call if DPD requests go unreplied.
But of course, that's radioactively non-standards-compliant. :-)
I don't know if they are compliant or not. To do the things you
describe, they must actually be B2BUAs. (E.g., they must rewrite all the
sequence numbers.) So they need to be judged on whether they are
compliant as UAs, not as proxies.
Thanks,
Paul
On July 3, 2018 10:20:41 AM EDT, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
On 7/3/18 3:53 AM, Alex Balashov wrote:
No, it's not illegal to retry a call to the same gateway (in case of
6xx response).
Nor is it illegal to reject it. :-)
My experience in an applied sense with SSTs (SIP Session Timers) is
that they are poorly supported, seemingly due to all the state-keeping
involved. Many UAs commit to a refresher role, for instance, but don't
actually issue the reinvites to refresh.
Instead, it is a more commonplace to approach to just use
nullary-change reinvites for signalling-level DPD (dead peer
detection), without the baggage of SSTs. So for instance, there are a
lot of carriers out there whose equipment will just send you a reinvite
every 15 minutes to check if you're alive, quite regardless of any
SSTs, roles, support for SSTs, etc.
I think people forget that UAs have no need of session timers, since
they can do as you say, whenever they wonder about the status of the
session.
The real point of session timers is in support of proxies in the
signaling path. If they want to keep session state, then they have no
way to know when to clear that state if they see no signaling for a
long
time. The session timers give them a way to ask the UAs to help them
out.
More in another reply.
Thanks,
Paul
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
