Re: [Sip-implementors] SIP 422 and RFC 4028
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 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
Re: [Sip-implementors] SIP 422 and RFC 4028
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 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
Re: [Sip-implementors] SIP 422 and RFC 4028
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 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
Re: [Sip-implementors] SIP 422 and RFC 4028
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 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SIP 422 and RFC 4028
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 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
Re: [Sip-implementors] SIP 422 and RFC 4028
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] SIP 422 and RFC 4028
Hi All, We have noticed that one provider is not reattempting the call with new session-expire value once the call is rejected with 422 Session Interval Too Small. But RFC 4028 doesn't say its mandatory to retry the call by UAC, but isn't a wrong behavior of UAC? I understand that session-expire is not a mandatory header field but in real word scenario, you can't live without this. Please share your valuable thoughts on this. Thanks, Amanpreet Singh. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
