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
