Yes, my bad, you are correct !
BR/pj
Sensitivity: Internal
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
<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
> <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%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.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%7Cb0e9290a7df14515616e08d83a22941d%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637323267478462483&sdata=MEqUSmLNe%2FqAtEjg5Cma9pXD1PJANmtytJUCnWo9i6s%3D&reserved=0
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
