Thanks Paul for your inputs. Yes, UAC doesn't include 'Supported:timer' in the INVITE, then this is a bad implementation.
~ Aman On Tue, Jul 3, 2018 at 7:57 PM Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > On 7/3/18 6:15 AM, Aman wrote: > > 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. > > Did UAC include > > Supported:timer in the invite? > If not, it may well not implement session timer at all, and so can't be > expected to understand the 422. > > > 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. > > No, it isn't. For one, as noted above, it may not support s-t at all. > Even if it does, it might not wish a call with a larger value. (But that > is implausible in this case, since it expressed no desire for a s-t at all. > > *If* UAC does support s-t, then this behavior indicates a poor > implementation, yet it is still a conforming implementation. > > Thanks, > Paul > > > 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 > > > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
