Re: [Sip-implementors] session refresh
No problem, thank you ! BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Paul Kyzivat Sent: den 24 september 2019 16:24 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] session refresh On 9/24/19 6:03 AM, Philipp Schöning wrote: > This was most likely a typo, RFC 3264 describes SDP offer/answer model. Yes, it was a typo. Sorry. > Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan > (Telenor Sverige AB) : > >> Thank you, really helpful, but I need help on what I should look for >> in RFC3265, I can't find that there is any mention of SDP's in it ? >> BR/pj >> > ___ > 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] session refresh
On 9/24/19 6:03 AM, Philipp Schöning wrote: This was most likely a typo, RFC 3264 describes SDP offer/answer model. Yes, it was a typo. Sorry. Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor Sverige AB) : Thank you, really helpful, but I need help on what I should look for in RFC3265, I can't find that there is any mention of SDP's in it ? BR/pj ___ 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] session refresh
Thanks ! 😊 -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Philipp Schöning Sent: den 24 september 2019 12:03 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] session refresh This was most likely a typo, RFC 3264 describes SDP offer/answer model. Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor Sverige AB) mailto:per-johan.sundb...@telenor.se>>: > Thank you, really helpful, but I need help on what I should look for > in RFC3265, I can't find that there is any mention of SDP's in it ? > BR/pj > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu<mailto:Sip-implementors@lists.cs.columbia.edu> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Sensitivity: Internal ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] session refresh
This was most likely a typo, RFC 3264 describes SDP offer/answer model. Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor Sverige AB) : > Thank you, really helpful, but I need help on what I should look for in > RFC3265, I can't find that there is any mention of SDP's in it ? > BR/pj > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] session refresh
Thank you, really helpful, but I need help on what I should look for in RFC3265, I can't find that there is any mention of SDP's in it ? BR/pj Sensitivity: Internal -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Paul Kyzivat Sent: den 24 september 2019 00:27 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] session refresh On 9/23/19 5:00 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > Hi ! > Can anybody help me find relevant RFC/other info on how UAS should handle > re-INVITE that is intended as a session refresh and not for modifying the > session ? A pure session refresh is something that can only be recognized in retrospect, not in advance. Since that is the caller's desire, he is off to a good start by offering B1 again in (5). That indicates doesn't want to change anything. But there is no guarantee that the caller will want to keep things as they are. (Though the probability is high.) In this case the caller MAY send A1 in (6), and that would make clear that it too prefers a "pure" session request. OTOH, the caller MAY send any SDP in (6) that complies with O/A rules as specified in RFC3265. I suggest you review RFC6337, notably section 5. It also cross references parts of other RFCs that motivate what it says. Thanks, Paul > SDP B1 in (3) is identical with SDP B1 in (5) > > > > CallerCallee > | | > | | >|(1) INVITE with SDP A1 | > |>| > | | > | | > |(2) Trying | > |<| > | | > | | > |(3) 200 OK with SDP B1 | | > |<| > | | > | | > |(4) ACK | > |>| > | | > | | > |(5) (re)INVITE with SDP B1 | > |<| > | | > | | > |(6) 200 OK with SDP | > |>| > > > Thanks ! > BR/pj > > > > Sensitivity: Internal > ___ > 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] session refresh
Thank you ! From: Kashif Husain Sent: den 24 september 2019 00:04 To: Sundbaum Per-Johan (Telenor Sverige AB) Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] session refresh And we can also respond with 200OK as mentioned in rfc3261 with no change in our sdp. "If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user)." On Tue, 24 Sep 2019, 03:17 Kashif Husain, mailto:kashifhusai...@gmail.com>> wrote: You can check for SDP version of re-Invite, if its same as previous one then its usually intended for session refresh. Thanks, -kashif On Tue, 24 Sep 2019, 02:30 Sundbaum Per-Johan (Telenor Sverige AB), mailto:per-johan.sundb...@telenor.se>> wrote: Hi ! Can anybody help me find relevant RFC/other info on how UAS should handle re-INVITE that is intended as a session refresh and not for modifying the session ? SDP B1 in (3) is identical with SDP B1 in (5) CallerCallee | | | | |(1) INVITE with SDP A1 | |>| | | | | |(2) Trying | |<| | | | | |(3) 200 OK with SDP B1 | | |<| | | | | |(4) ACK | |>| | | | | |(5) (re)INVITE with SDP B1 | |<| | | | | |(6) 200 OK with SDP | |>| Thanks ! BR/pj Sensitivity: Internal ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu<mailto:Sip-implementors@lists.cs.columbia.edu> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Sensitivity: Internal ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] session refresh
On 9/23/19 5:00 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: Hi ! Can anybody help me find relevant RFC/other info on how UAS should handle re-INVITE that is intended as a session refresh and not for modifying the session ? A pure session refresh is something that can only be recognized in retrospect, not in advance. Since that is the caller's desire, he is off to a good start by offering B1 again in (5). That indicates doesn't want to change anything. But there is no guarantee that the caller will want to keep things as they are. (Though the probability is high.) In this case the caller MAY send A1 in (6), and that would make clear that it too prefers a "pure" session request. OTOH, the caller MAY send any SDP in (6) that complies with O/A rules as specified in RFC3265. I suggest you review RFC6337, notably section 5. It also cross references parts of other RFCs that motivate what it says. Thanks, Paul SDP B1 in (3) is identical with SDP B1 in (5) CallerCallee | | | | |(1) INVITE with SDP A1 | |>| | | | | |(2) Trying | |<| | | | | |(3) 200 OK with SDP B1 | | |<| | | | | |(4) ACK | |>| | | | | |(5) (re)INVITE with SDP B1 | |<| | | | | |(6) 200 OK with SDP | |>| Thanks ! BR/pj Sensitivity: Internal ___ 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] session refresh
And we can also respond with 200OK as mentioned in rfc3261 with no change in our sdp. "If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user)." On Tue, 24 Sep 2019, 03:17 Kashif Husain, wrote: > You can check for SDP version of re-Invite, if its same as previous one > then its usually intended for session refresh. > > Thanks, > -kashif > > On Tue, 24 Sep 2019, 02:30 Sundbaum Per-Johan (Telenor Sverige AB), < > per-johan.sundb...@telenor.se> wrote: > >> Hi ! >> Can anybody help me find relevant RFC/other info on how UAS should handle >> re-INVITE that is intended as a session refresh and not for modifying the >> session ? >> >> SDP B1 in (3) is identical with SDP B1 in (5) >> >> >> >> CallerCallee >>| | >>| | >> |(1) INVITE with SDP A1 | >>|>| >>| | >>| | >>|(2) Trying | >>|<| >>| | >>| | >>|(3) 200 OK with SDP B1 | | >>|<| >>| | >>| | >>|(4) ACK | >>|>| >>| | >>| | >>|(5) (re)INVITE with SDP B1 | >>|<| >>| | >>| | >>|(6) 200 OK with SDP | >>|>| >> >> >> Thanks ! >> BR/pj >> >> >> >> Sensitivity: Internal >> ___ >> 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] session refresh
You can check for SDP version of re-Invite, if its same as previous one then its usually intended for session refresh. Thanks, -kashif On Tue, 24 Sep 2019, 02:30 Sundbaum Per-Johan (Telenor Sverige AB), < per-johan.sundb...@telenor.se> wrote: > Hi ! > Can anybody help me find relevant RFC/other info on how UAS should handle > re-INVITE that is intended as a session refresh and not for modifying the > session ? > > SDP B1 in (3) is identical with SDP B1 in (5) > > > > CallerCallee >| | >| | > |(1) INVITE with SDP A1 | >|>| >| | >| | >|(2) Trying | >|<| >| | >| | >|(3) 200 OK with SDP B1 | | >|<| >| | >| | >|(4) ACK | >|>| >| | >| | >|(5) (re)INVITE with SDP B1 | >|<| >| | >| | >|(6) 200 OK with SDP | >|>| > > > Thanks ! > BR/pj > > > > Sensitivity: Internal > ___ > 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] session refresh
RFC 4028 describes Session Timers in SIP. RFC 3264, 4317, 4566, 6337 describe SDP as well as SDP offer/answer model. RFC 6141 describes Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP). Hope this helps ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] session refresh
Hi ! Can anybody help me find relevant RFC/other info on how UAS should handle re-INVITE that is intended as a session refresh and not for modifying the session ? SDP B1 in (3) is identical with SDP B1 in (5) CallerCallee | | | | |(1) INVITE with SDP A1 | |>| | | | | |(2) Trying | |<| | | | | |(3) 200 OK with SDP B1 | | |<| | | | | |(4) ACK | |>| | | | | |(5) (re)INVITE with SDP B1 | |<| | | | | |(6) 200 OK with SDP | |>| Thanks ! BR/pj Sensitivity: Internal ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SESSION REFRESH: Can SE value be increased by UAS?
Harsha. R wrote: > Hi, > Consider the following scenario with regard to session-refresh > > INVITE[Min SE:900, (SE:900,refresher=uas),k:timer] > UAC->UAS > > 183 SP,PRACK(183),200OK PRACK,180 Ringing, PRACK(180),200 OK PRACK follow > > 200 OK[(SE:1800,refresher=uas), k:timer] > UAC<-UAS > > Because the refresher is UAS, can UAS increase the value of > Session-Expires value in 200 OK to the INVITE? IMO No. > My understanding of RFC 4028 is as follows. > > 1. In any negotiation of the session-refresh interval, MinSE is the > lower bound and SE is the upper bound. > 2. UAS MUST NOT increase the value of SE, however it can decrease it. > > The above points are also clearly documented in the RFC 4028, Section > 9 and I quote > > " If the UAS wishes to accept the request, it copies the value of the >Session-Expires header field from the request into the 2xx response. >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." > > > Now my question is, since UAC has clearly set the MinSE(900) and > SE(900) values in the Session-Refresh request and chosen UAS as the > refresher in the process, is UAS allowed the latitude to INCREASE the > value of Session Expires header to 1800 in the response to > Session-Refresh request? The use case is bizarre. The UAC is doing something legal but stupid. The UAS is doing something illegal. The UAC ought not to be *deciding* the UAS will be the refresher. Doing so will cause the call to fail if the UAS isn't willing to do so. The UAC has also constrained the refresh interval to a single value, which, while not illegal, is also likely to result in interop problems. The UAS should: 1) note that it has been *told* that it must be the refresher 2) note that the the refresh interval is constrained to 900. It should then decide if it can live with those limits. If not it should reject the call. It isn't permitted to raise the limit above 900. Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SESSION REFRESH: Can SE value be increased byUAS?
I think you have answered your own question very well with excellent references (it nicely saves everyone else's time!). :-) (UAS is not allowed to increase the SE) Regards, Attila -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harsha. R Sent: 16 January 2008 14:41 To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] SESSION REFRESH: Can SE value be increased byUAS? Hi, Consider the following scenario with regard to session-refresh INVITE[Min SE:900, (SE:900,refresher=uas),k:timer] UAC- >UAS 183 SP,PRACK(183),200OK PRACK,180 Ringing, PRACK(180),200 OK PRACK follow 200 OK[(SE:1800,refresher=uas), k:timer] UAC< -UAS Because the refresher is UAS, can UAS increase the value of Session-Expires value in 200 OK to the INVITE? My understanding of RFC 4028 is as follows. 1. In any negotiation of the session-refresh interval, MinSE is the lower bound and SE is the upper bound. 2. UAS MUST NOT increase the value of SE, however it can decrease it. The above points are also clearly documented in the RFC 4028, Section 9 and I quote " If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response. 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." Now my question is, since UAC has clearly set the MinSE(900) and SE(900) values in the Session-Refresh request and chosen UAS as the refresher in the process, is UAS allowed the latitude to INCREASE the value of Session Expires header to 1800 in the response to Session-Refresh request? -- Regards Harsha ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SESSION REFRESH: Can SE value be increased byUAS?
> Now my question is, since UAC has clearly set the > MinSE(900) andSE(900) values in the Session-Refresh > request and chosen UAS as the refresher in the process, > is UAS allowed the latitude to INCREASE the value of > Session Expires header to 1800 in the response > to Session-Refresh request? No. If Session-Expires value is below the UAS' minimum and UAC indicated timer support, the 422 with Min-SE is the appropriate response. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
[Sip-implementors] SESSION REFRESH: Can SE value be increased by UAS?
Hi, Consider the following scenario with regard to session-refresh INVITE[Min SE:900, (SE:900,refresher=uas),k:timer] UAC->UAS 183 SP,PRACK(183),200OK PRACK,180 Ringing, PRACK(180),200 OK PRACK follow 200 OK[(SE:1800,refresher=uas), k:timer] UAC<-UAS Because the refresher is UAS, can UAS increase the value of Session-Expires value in 200 OK to the INVITE? My understanding of RFC 4028 is as follows. 1. In any negotiation of the session-refresh interval, MinSE is the lower bound and SE is the upper bound. 2. UAS MUST NOT increase the value of SE, however it can decrease it. The above points are also clearly documented in the RFC 4028, Section 9 and I quote " If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response. 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." Now my question is, since UAC has clearly set the MinSE(900) and SE(900) values in the Session-Refresh request and chosen UAS as the refresher in the process, is UAS allowed the latitude to INCREASE the value of Session Expires header to 1800 in the response to Session-Refresh request? -- Regards Harsha ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
