On 7/31/17 11:49 PM, Prakash K wrote:
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 ?
This is an interesting case. 3261 doesn't provide a lot of explicit
guidance - the proper action needs to be teased out of the text.
My first reaction was that you should just drop this message. But I
couldn't find a good justification for that.
My next thought was that if it qualifies as a valid response to the
*transaction* then the transaction should be run to completion.
Following the revised state machine in rfc6026 that means moving to the
Accepted state (if not already in that state), and passing the 2xx to
the TU for further processing. Then the TU would discover that this
response is messed up because it doesn't match an existing dialog, and
also doesn't match a pending dialog (same from-tag and callid). As a
result, it probably shouldn't send an ACK.
But this troubles me because it moves the state machine to the Accepted
state. Thus is prevents subsequently received 1xx,3xx-6xx responses from
being properly handled.
I think just dropping this response would lead to a better result, but I
can't quite see how to justify that action from 3261 and 6026.
I'd like to hear from others who are knowledgeable about such things.
Thanks,
Paul
On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" <pkyzi...@alum.mit.edu
<mailto: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
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<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
