- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 07 May 2014 12:33:27 +0200
- To: kiran.guduru@samsung.com, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <536A0BF7.9040306@alvestrand.no>
On 05/07/2014 11:46 AM, Kiran Kumar Guduru wrote: > Samsung Enterprise Portal mySingle > > Hi, > > My apologies, I missed one point. > > Please find my comments inline. > > ------- *Original Message* ------- > > *Sender* : Harald Alvestrand<harald@alvestrand.no> > > *Date* : May 07, 2014 17:46 (GMT+09:00) > > *Title* : Re: [Bug 25579] New: State transitions are missing in > RTCPeerConnections state transition diagram. > > On 05/07/2014 09:28 AM, Kiran Kumar Guduru wrote: >> >> Modifying the state by re-applying the last PRANSWER transition as an >> ANSWER will result in ambiguity. >> >> Consider the following error scenario, where UAC and UAS are two >> peers, sender and receiver respectively. >> >> 1.A call is established between UAC and UAS, and both are in STABLE >> state. >> >> 2.Now UAC initiated negotiation with OFFER in a SIP Re-Invite, >> received PRANSWER in 183 session progress. >> >> 3.UAC transits its state to HAVE-LOCAL-OFFER and that of UAS to >> HAVE-REMOTE-OFFER. >> >> 4.UAS sends the PRANSWER and transits to HAVE-LOCAL-PRANSWER and that >> of UAC to HAVE-REMOTE-PRANSWER. (It is fine till this point). >> >> 5.For sending offer in PRACK, if UAC re-applies the PRANSWER as final >> ANSWER then, UAC transits to STABLE state and UAS transits to >> HAVE-REMOTE-OFFER. >> > > This is illogical. UAC would re-apply the PRANSWER as final ANSWER and > then apply its new offer, resulting in being in HAVE-LOCAL-OFFER > state. It can't be in STABLE state while it has an outstanding offer. > (if I've understood the description correctly. I don't know PRACK > details.) > > [KIRAN] The following step is missing > > 5.1. After sending the offer in PRAC, UAC > transits to HAVE-LOCAL-OFFER and that of UAS continues to be > in HAVE-REMOTE-OFFER. (As specified by you) > > Now after this if you check the setp 6, > >> 6.If the UAS want to reject the OFFER in PRACK and roll-back, then it >> will roll-back to previous STABLE state. But the STABLE state of UAC >> is not the expected STABLE state. >> I don't think I read your text properly, possibly because each line contains multiple things. Let me try to rephrase.... 1. The call is in STABLE state, a connection is established. Let's call this "Stable state 0". 2. UAC creates a SIP INVITE, and installs the OFFER inside it. UAC is now in HAVE-LOCAL-OFFER. 3. UAC sends the SIP INVITE to UAS. 4. UAS receives the SIP INVITE, installs the OFFER. It is now in HAVE-REMOTE-OFFER. 5. UAS generates an ANSWER, packages it inside a 183 session progress message, and installs it locally as a PR-ANSWER. It is now in HAVE-LOCAL-PRANSWER state. 6. UAS sends the 183 Session Progress message to UAC. 7. UAC receives the 183 Session Progress message, installs the ANSWER inside of it as a PR-ANSWER, and is now in HAVE-REMOTE-PRANSWER state. (Are we agreed that we have now finished step 4 in the original description?) 8. UAC generates a PRACK request with an OFFER inside of it. 9. UAC installs the generated OFFER on top of the HAVE-REMOTE-PRANSWER state. Turns out my head started hurting at step 8. Which state is the new OFFER described as a change from? "Stable state 0" or the stable state corresponding to what the state would be after HAVE-REMOTE-PRANSWER was applied as a final answer? Now, if we start over from step 8: 8. UAC decides it wants to generate a new OFFER, and therefore installs the ANSWER from 183 as a final ANSWER. It is now in STABLE. Let's call this "Stable state 1". 9. UAC generates a PRACK request with an OFFER inside of it, and installs the OFFer. It is now in HAVE-LOCAL-OFFER. 10. UAC sends PRACK to UAS. 11. UAS gets the PRACK and decides to reject it. It is still in HAVE-LOCAL-PRANSWER state. 12. UAS decides the dialog is over, and installs the PRANSWER as final answer. It is now in "Stable State 1". 13. UAC gets the rejection message, and calls Rollback. It is now in "Stable State 1". This seems self-consistent, but it might not be what people using PRACK expect. What do people using PRACK expect? > [KIRAN] UAC will transits to intermediate STABLE state and that of UAS > will transits to its 1ts STABLE state. > > > What would the expected STABLE state be in a PRACK (non-WebRTC > implementation? > That is - after rejecting the OFFER in PRACK, would the UAS expect the > UAC to be in the state of having accepted the previous offer, or in > the state of not having accepted any offer? > > [KIRAN] In PRACK case, If the SIP user agent is not willing to accept > an offer, if it responds with an error response, than that terminates > that particular SIP Invite / Re-Invite transaction. > > In such case, it will roll-back to the state that is negotiated by > previous Invite- with final ANSWER. > > This case has been outlined (it has not explained in brief) in RFC > 6337, section 2.3 Table-2. > > Offer Rejection > ------------------------------------------------------------------ > 1. INVITE Req. (*) 488 INVITE Response > 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer > OR termination of dialog > 3. INVITE Req. 488 INVITE Response (same as Pattern 1) > 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer > 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer > OR termination of dialog > 6. UPDATE Req. 488 UPDATE Response > > [1] http://tools.ietf.org/html/rfc6337#page-5 > >> And so finally ends up in ambiguous state. >> >> Same might be the case for establishing a new session as well. >> >> ------- *Original Message* ------- >> >> *Sender* : Harald Alvestrand<harald@alvestrand.no> >> >> *Date* : May 07, 2014 13:36 (GMT+09:00) >> >> *Title* : Re: [Bug 25579] New: State transitions are missing in >> RTCPeerConnections state transition diagram. >> >> On 05/06/2014 04:05 PM, bugzilla@jessica.w3.org wrote: >> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25579 >> > >> > Bug ID: 25579 >> > Summary: State transitions are missing in RTCPeerConnections >> > state transition diagram. >> > Product: WebRTC Working Group >> > Version: unspecified >> > Hardware: All >> > OS: All >> > Status: NEW >> > Severity: normal >> > Priority: P2 >> > Component: WebRTC API >> > Assignee: public-webrtc@w3.org >> > Reporter: kiran.guduru@samsung.com >> > CC: public-webrtc@w3.org >> > >> > Created attachment 1472 >> > --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1472&action=edit >> > The attachment gives the updated state transition diagram for >> > RTCPeerConnection. >> > >> > RTCPeerConnection's state transition diagram, specified in spec >> [1], is missing >> > to indicate following state transitions state transitions. >> > >> > 1. have-remote-pranswer to have-local-offer >> > >> > 2. Have-local-pranswer to have-remtoe-offer >> >> Those two transitions are intended to be impossible. If you want to go >> from have-pranswer to have-offer, you need to go via the idle state. >> >> > >> > The same is applicable for statemachine defined in section 3.2 of >> JSEP draft >> > [2]. >> > >> > This state transitions are MUST to support section 5 of RFC 3262 >> [3] prack >> > case. >> > >> > "If the UAC receives a reliable provisional response with an >> answer, it MAY >> > generate an additional offer in the PRACK." >> >> You can achieve the effect by re-applying the last PRANSWER transition >> as an ANSWER. >> >> People who understand PRACK can comment further. >> >> > >> > Please find the attachment for the proposed state transition >> diagram, which >> > includes these state. >> > >> > [1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#state-definitions >> > >> > [2] http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#page-7 >> > >> > [3] http://www.ietf.org/rfc/rfc3262.txt >> > >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >
Received on Wednesday, 7 May 2014 10:34:05 UTC