Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
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" 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
Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
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
Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
There is no response for a response. So no 481 will be there. Rohit Jain Sent from my iPhone > On 31-Jul-2017, at 9:31 PM, Prakash K wrote: > > How response will be sent for response ? > > UA received 200 OK for INVITE which is sent out ,* but 200 OK received is > with different call-id (wont match the context)* > >> On 31 July 2017 at 21:07, Asim Sulaiman wrote: >> >> Dear Prakash, >> >> I guess you will get 481 transaction does not exist. >> >> >> Regards, >> Asim Sulaiman >> >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu >> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of >> Prakash >> K >> Sent: Monday, July 31, 2017 7:27 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] Processing of Standalone 200 OK response for >> INVITE ["200OK received by UA with different Call-id which is not in >> context"] >> >> 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? >> >> >> -- >> Thanks >> Prakash K >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> >> >> >> Disclaimer : >> This e-mail message may contain confidential, proprietary or legally >> privileged information. It should not be used by anyone who is not the >> original intended recipient. If you have erroneously received this message, >> please delete it immediately and notify the sender. The recipient >> acknowledges that EMIRCOM, as the case may be, are unable to exercise >> control or ensure or guarantee the integrity of/over the contents of the >> information contained in e-mail transmissions and further acknowledges that >> any views expressed in this message are those of the individual sender and >> no binding nature of the message shall be implied or assumed unless the >> sender does so expressly with due authority of EMIRCOM. Before opening any >> attachments please check them for viruses and defects. >> >> >> >> >> Disclaimer : >> This e-mail message may contain confidential, proprietary or legally >> privileged information. It should not be used by anyone who is not the >> original intended recipient. If you have erroneously received this message, >> please delete it immediately and notify the sender. The recipient >> acknowledges that EMIRCOM, as the case may be, are unable to exercise >> control or ensure or guarantee the integrity of/over the contents of the >> information contained in e-mail transmissions and further acknowledges that >> any views expressed in this message are those of the individual sender and >> no binding nature of the message shall be implied or assumed unless the >> sender does so expressly with due authority of EMIRCOM. Before opening any >> attachments please check them for viruses and defects. >> >> > > > -- > Thanks > Prakash K > ___ > 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] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
How response will be sent for response ? UA received 200 OK for INVITE which is sent out ,* but 200 OK received is with different call-id (wont match the context)* On 31 July 2017 at 21:07, Asim Sulaiman wrote: > Dear Prakash, > > I guess you will get 481 transaction does not exist. > > > Regards, > Asim Sulaiman > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Prakash > K > Sent: Monday, July 31, 2017 7:27 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Processing of Standalone 200 OK response for > INVITE ["200OK received by UA with different Call-id which is not in > context"] > > 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? > > > -- > Thanks > Prakash K > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously received this message, > please delete it immediately and notify the sender. The recipient > acknowledges that EMIRCOM, as the case may be, are unable to exercise > control or ensure or guarantee the integrity of/over the contents of the > information contained in e-mail transmissions and further acknowledges that > any views expressed in this message are those of the individual sender and > no binding nature of the message shall be implied or assumed unless the > sender does so expressly with due authority of EMIRCOM. Before opening any > attachments please check them for viruses and defects. > > > > > Disclaimer : > This e-mail message may contain confidential, proprietary or legally > privileged information. It should not be used by anyone who is not the > original intended recipient. If you have erroneously received this message, > please delete it immediately and notify the sender. The recipient > acknowledges that EMIRCOM, as the case may be, are unable to exercise > control or ensure or guarantee the integrity of/over the contents of the > information contained in e-mail transmissions and further acknowledges that > any views expressed in this message are those of the individual sender and > no binding nature of the message shall be implied or assumed unless the > sender does so expressly with due authority of EMIRCOM. Before opening any > attachments please check them for viruses and defects. > > -- Thanks Prakash K ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
Dear Prakash, I guess you will get 481 transaction does not exist. Regards, Asim Sulaiman -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Prakash K Sent: Monday, July 31, 2017 7:27 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"] 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? -- Thanks Prakash K ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Disclaimer : This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that EMIRCOM, as the case may be, are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of EMIRCOM. Before opening any attachments please check them for viruses and defects. Disclaimer : This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that EMIRCOM, as the case may be, are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of EMIRCOM. Before opening any attachments please check them for viruses and defects. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]
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? -- Thanks Prakash K ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
