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
