Hi Paul, Thanks a lot, You have put it in a nice way , I understood the use-case for Forking
But I have the following question *This all assumes that the 2xx matches an INVITE transaction you have pending, and that the from-tag and call-id match what was in the corresponding INVITE.Otherwise this is a stray message or an attack and ought to be ignored.* *So if the 200 OK received having different "Call-ID" *not matching with the Call-ID which is sent in INVITE by UA, it should be ignored. ( even if Cseq/From-tag/branch parameter is same as INVITE which is sent out) ?* What would be the UA behaviour in above case ? On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" <pkyzi...@alum.mit.edu> wrote: > On 7/31/17 11:26 AM, Prakash K wrote: > >> What would be the behavior of UA when 200 OK received which is not >> matching >> the dialog >> >> "200OK received by UA with different Call-id which is not in context" >> >> >> I see the following snippet in RFC 3261 which says UA should create >> dialog. Wont this end up in acknowledging the hacking? >> >> If the dialog identifier in the 2xx response matches the dialog >> identifier of an existing dialog, the dialog MUST be transitioned to >> the "confirmed" state, and the route set for the dialog MUST be >> recomputed based on the 2xx response using the procedures of Section >> 12.2.1.2. *Otherwise, a new dialog in the "confirmed" state MUST be >> constructed using the procedures of Section 12.1.2.* >> >> >> does this mean UA should generate ACK & immediately followed by BYE should >> be triggered? >> > > As is mentioned in the prior paragraph, this is primarily about forking. > If the initial INVITE is forked, then two or more UASs may respond. Each > will choose a unique to-tag, and since the to-tag is part of the dialog-id > each will be associated with a distinct dialog. > > The dialogs for various forks may be discovered via 1xx responses, in > which case the corresponding 2xx may match an existing dialog. OTOH > sometimes a UAS will send a 2xx without first sending a 1xx. In that case > the mentioned situation will occur. > > Also note that this can happen without forking if the single UAS > immediately responds with a 2xx. > > The forking case where you actually get multiple 2xx reponses, > establishing multiple dialogs, is pretty rare. Usually the forking proxy > ceases forking when it sees a 2xx response and attempts to cancel any other > outstanding legs. But it *can* happen and the UAC needs to be prepared to > cope when it does. *What* you do is unspecified. Immediately sending a BYE > is a popular solution because it is easy. But it isn't especially friendly > to the callee. Other possibilities: > > - form a conference call within your UAC, mixing the audio from > the multiple legs > > - play some prerecorded audio explaining why you are hanging up, > then BYE. > > This all assumes that the 2xx matches an INVITE transaction you have > pending, and that the from-tag and call-id match what was in the > corresponding INVITE. Otherwise this is a stray message or an attack and > ought to be ignored. > > Thanks, > Paul > _______________________________________________ > 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
