Thanks a million for the explanation. Thanks Basu
On Thu, Aug 6, 2020 at 9:35 PM Paul Kyzivat <pkyzi...@alum.mit.edu> 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 <Sip-implementors@lists.cs.columbia.edu> > > 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
