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. :-) 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
