I find out an interesting conversation exactly about my scenario, when RFC 4028 was a draft and was in discussion mode, https://www.ietf.org/mail-archive/web/sip/current/msg00743.html
Call flow: UAC ----- P-A ----- P-B ------ UAS 1. UAC sends a simple INVITE w/o any session timer. 2. P-A inserts Session-Expires: 600 3. P-B detects that this value is too small and generates a 422 Session Timer too small Session-Expires: 900 4. P-A forwards this up the UAC The INVITE transaction has completed so P-A clears all state (there was no call established). 5. The UAC receives 422 Response but does not understand it. Hence, the 422 defaults to 400 class response; no retry with different timer value is done. So what I understood is the proposed solution is to have the proxy(P-A) insert a Min-SE header in this case. Question is, if proxy P-A does the same, is it mandatory or not for UAC to retry the INVITE with suggested session-expire value even if the response code is 4XX. Thanks, Amanpreet Singh. On Tue, Jul 3, 2018 at 1:24 PM Alex Balashov <abalas...@evaristesys.com> 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. > > -- 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
