Re: [Sip-implementors] SIP Session Refresh RFC 4028
Thanks a million for the explanation. Thanks Basu On Thu, Aug 6, 2020 at 9:35 PM Paul Kyzivat wrote: > On 8/6/20 8:39 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > > Hi ! > > Details about refresher is missing in your description, but I believe > that B2BUA should accept UAS(B) value ! > > I disagree with your conclusion. > > While there is no explicit information about the refresher, the > commentary implies that the B2BUA concludes that it should be the > refresher. So I presume it was set so in the 200 response. > > Also, Party-A is irrelevant to the question at hand. The B2BUA should be > considered to be just a UA for the purposes of the analysis. > > Party-B has done two things wrong: > > 1) It included Session-Expires and Supported:timer in the response, > indicating that it does support timers, but (I guess) did not include > Require:timer. There should never be a 200 response that has that > combination of settings. > > 2) It has returned a value in Session-Expires that is less than the > value of Min-SE in the request. This is also non-conforming behavior. > > The RFC doesn't say what the UAC (B2BUA) should do in this case. The > absence of Require:timer in the response means that no timer session has > been established and so the B2BUA isn't obligated to send refreshes at > any interval. > > Party-B is of course entitled to send a BYE any time it likes. But it is > wrong to blame the B2BUA for the failure of the call. > > It is unreasonable to expect the B2BUA to act in this case by acting as > refresher with interval 240. That is less than it has already indicated > that it is willing to do. > > Party-B needs to fix its implementation. If it really feels it needs a > refresh interval of 240 then it can refuse to set up the call by > returning an error immediately. Or, it can set up the call without > session timer, and then send re-invites (or any other request) at the > interval it desires to test the session. > > Thanks, > Paul > > > As per RFC 4028, following is the behavior of UAS. > > 9. UAS Behavior > > The UAS response MAY reduce its value but MUST NOT set it to a > > duration lower than the value in the Min-SE header field in the > > request, if it is present; otherwise the UAS MAY reduce its value but > > MUST NOT set it to a duration lower than 90 seconds. The UAS MUST > > NOT increase the value of the Session-Expires header field. > > > > BR/pj > > > > > > Sensitivity: Internal > > > > -Original Message----- > > From: sip-implementors-boun...@lists.cs.columbia.edu < > sip-implementors-boun...@lists.cs.columbia.edu> On Behalf Of Basu > Chikkalli > > Sent: den 6 augusti 2020 13:22 > > To: sip-implementors > > Subject: [Sip-implementors] SIP Session Refresh RFC 4028 > > > > Hi All, > > > > A->B2BUA>B > > > > A-Party does not support session. > >no Session_Expires,no Min-SE and no Supported:timer > >So no session refresh between A and B2BUA. > > > > When B2BUA supports timer. > > It sends INVITE to B with following details > > B2BUA---INVITE-->B > > Supported : timer > > Session_Expires : 840 > > Min-SE : 360 > > > > > > B2BUA<<200-OK--B > > Supported:timer > > Session_Expires:240 > > Min-SE: 120 > > > >The B2BUA not obeying B' session_expires and starts timer on 840 sec. > > resulting B-Party sending BYE to the session after it's timer expiry. > > > > Should B2BUA should start timer on B's session_expires value (240sec) or > it's own session_expires (840)? > > > > Thanks > > Basu > > ___ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=02%7C01%7Cper-johan.sundbaum%40telenor.se%7C5912c13c441e41452e0f08d839faed6b%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C1%7C637323097177046922&sdata=aYNwmn%2Ba0zpNYY7JMtkODt1Zeg3SJHovwBB34yc6PjY%3D&reserved=0 > > ___ > > 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 Session Refresh RFC 4028
Yes, my bad, you are correct ! BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Paul Kyzivat Sent: den 6 augusti 2020 18:05 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP Session Refresh RFC 4028 On 8/6/20 8:39 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > Hi ! > Details about refresher is missing in your description, but I believe that > B2BUA should accept UAS(B) value ! I disagree with your conclusion. While there is no explicit information about the refresher, the commentary implies that the B2BUA concludes that it should be the refresher. So I presume it was set so in the 200 response. Also, Party-A is irrelevant to the question at hand. The B2BUA should be considered to be just a UA for the purposes of the analysis. Party-B has done two things wrong: 1) It included Session-Expires and Supported:timer in the response, indicating that it does support timers, but (I guess) did not include Require:timer. There should never be a 200 response that has that combination of settings. 2) It has returned a value in Session-Expires that is less than the value of Min-SE in the request. This is also non-conforming behavior. The RFC doesn't say what the UAC (B2BUA) should do in this case. The absence of Require:timer in the response means that no timer session has been established and so the B2BUA isn't obligated to send refreshes at any interval. Party-B is of course entitled to send a BYE any time it likes. But it is wrong to blame the B2BUA for the failure of the call. It is unreasonable to expect the B2BUA to act in this case by acting as refresher with interval 240. That is less than it has already indicated that it is willing to do. Party-B needs to fix its implementation. If it really feels it needs a refresh interval of 240 then it can refuse to set up the call by returning an error immediately. Or, it can set up the call without session timer, and then send re-invites (or any other request) at the interval it desires to test the session. Thanks, Paul > As per RFC 4028, following is the behavior of UAS. > 9. UAS Behavior > The UAS response MAY reduce its value but MUST NOT set it to a > duration lower than the value in the Min-SE header field in the > request, if it is present; otherwise the UAS MAY reduce its value but > MUST NOT set it to a duration lower than 90 seconds. The UAS MUST > NOT increase the value of the Session-Expires header field. > > BR/pj > > > Sensitivity: Internal > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > On Behalf Of Basu > Chikkalli > Sent: den 6 augusti 2020 13:22 > To: sip-implementors > Subject: [Sip-implementors] SIP Session Refresh RFC 4028 > > Hi All, > > A->B2BUA>B > > A-Party does not support session. >no Session_Expires,no Min-SE and no Supported:timer >So no session refresh between A and B2BUA. > > When B2BUA supports timer. > It sends INVITE to B with following details > B2BUA---INVITE-->B > Supported : timer > Session_Expires : 840 > Min-SE : 360 > > > B2BUA<<200-OK--B > Supported:timer > Session_Expires:240 > Min-SE: 120 > >The B2BUA not obeying B' session_expires and starts timer on 840 sec. > resulting B-Party sending BYE to the session after it's timer expiry. > > Should B2BUA should start timer on B's session_expires value (240sec) or it's > own session_expires (840)? > > Thanks > Basu > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=02% > 7C01%7Cper-johan.sundbaum%40telenor.se%7Cb0e9290a7df14515616e08d83a229 > 41d%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637323267478462483&am > p;sdata=MEqUSmLNe%2FqAtEjg5Cma9pXD1PJANmtytJUCnWo9i6s%3D&reserved= > 0 ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=02% > 7C01%7Cper-johan.sundbaum%40telenor.se%7Cb0e9290a7df14515616e08d83a229 > 41d%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637323267478462483&am > p;sdata=MEqUSmLNe%2FqAtEjg5Cma9pXD1PJANmtytJUCnWo9i6s%3D&reserved= > 0 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.e
Re: [Sip-implementors] SIP Session Refresh RFC 4028
On 8/6/20 8:39 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: Hi ! Details about refresher is missing in your description, but I believe that B2BUA should accept UAS(B) value ! I disagree with your conclusion. While there is no explicit information about the refresher, the commentary implies that the B2BUA concludes that it should be the refresher. So I presume it was set so in the 200 response. Also, Party-A is irrelevant to the question at hand. The B2BUA should be considered to be just a UA for the purposes of the analysis. Party-B has done two things wrong: 1) It included Session-Expires and Supported:timer in the response, indicating that it does support timers, but (I guess) did not include Require:timer. There should never be a 200 response that has that combination of settings. 2) It has returned a value in Session-Expires that is less than the value of Min-SE in the request. This is also non-conforming behavior. The RFC doesn't say what the UAC (B2BUA) should do in this case. The absence of Require:timer in the response means that no timer session has been established and so the B2BUA isn't obligated to send refreshes at any interval. Party-B is of course entitled to send a BYE any time it likes. But it is wrong to blame the B2BUA for the failure of the call. It is unreasonable to expect the B2BUA to act in this case by acting as refresher with interval 240. That is less than it has already indicated that it is willing to do. Party-B needs to fix its implementation. If it really feels it needs a refresh interval of 240 then it can refuse to set up the call by returning an error immediately. Or, it can set up the call without session timer, and then send re-invites (or any other request) at the interval it desires to test the session. Thanks, Paul As per RFC 4028, following is the behavior of UAS. 9. UAS Behavior The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field. BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Basu Chikkalli Sent: den 6 augusti 2020 13:22 To: sip-implementors Subject: [Sip-implementors] SIP Session Refresh RFC 4028 Hi All, A->B2BUA>B A-Party does not support session. no Session_Expires,no Min-SE and no Supported:timer So no session refresh between A and B2BUA. When B2BUA supports timer. It sends INVITE to B with following details B2BUA---INVITE-->B Supported : timer Session_Expires : 840 Min-SE : 360 B2BUA<<200-OK--B Supported:timer Session_Expires:240 Min-SE: 120 The B2BUA not obeying B' session_expires and starts timer on 840 sec. resulting B-Party sending BYE to the session after it's timer expiry. Should B2BUA should start timer on B's session_expires value (240sec) or it's own session_expires (840)? Thanks Basu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=02%7C01%7Cper-johan.sundbaum%40telenor.se%7C5912c13c441e41452e0f08d839faed6b%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C1%7C637323097177046922&sdata=aYNwmn%2Ba0zpNYY7JMtkODt1Zeg3SJHovwBB34yc6PjY%3D&reserved=0 ___ 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 Session Refresh RFC 4028
Hi ! Details about refresher is missing in your description, but I believe that B2BUA should accept UAS(B) value ! As per RFC 4028, following is the behavior of UAS. 9. UAS Behavior The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field. BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Basu Chikkalli Sent: den 6 augusti 2020 13:22 To: sip-implementors Subject: [Sip-implementors] SIP Session Refresh RFC 4028 Hi All, A->B2BUA>B A-Party does not support session. no Session_Expires,no Min-SE and no Supported:timer So no session refresh between A and B2BUA. When B2BUA supports timer. It sends INVITE to B with following details B2BUA---INVITE-->B Supported : timer Session_Expires : 840 Min-SE : 360 B2BUA<<200-OK--B Supported:timer Session_Expires:240 Min-SE: 120 The B2BUA not obeying B' session_expires and starts timer on 840 sec. resulting B-Party sending BYE to the session after it's timer expiry. Should B2BUA should start timer on B's session_expires value (240sec) or it's own session_expires (840)? Thanks Basu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=02%7C01%7Cper-johan.sundbaum%40telenor.se%7C5912c13c441e41452e0f08d839faed6b%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C1%7C637323097177046922&sdata=aYNwmn%2Ba0zpNYY7JMtkODt1Zeg3SJHovwBB34yc6PjY%3D&reserved=0 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SIP Session Refresh RFC 4028
Hi All, A->B2BUA>B A-Party does not support session. no Session_Expires,no Min-SE and no Supported:timer So no session refresh between A and B2BUA. When B2BUA supports timer. It sends INVITE to B with following details B2BUA---INVITE-->B Supported : timer Session_Expires : 840 Min-SE : 360 B2BUA<<200-OK--B Supported:timer Session_Expires:240 Min-SE: 120 The B2BUA not obeying B' session_expires and starts timer on 840 sec. resulting B-Party sending BYE to the session after it's timer expiry. Should B2BUA should start timer on B's session_expires value (240sec) or it's own session_expires (840)? Thanks Basu ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
