Robert,
I agree with most of what you say, but have a comment on one point:
On 8/1/17 12:23 PM, Robert Sparks wrote:
Be sure you are aware of (and implementing) the updates to RFC3261. You
really need RFC6026 to answer this question cleanly.
At the top level, this is far enough into "things are violating
protocol" that the specs aren't going to give algorithmic advice.
The closest they will get is that the transaction would pass the 200 to
the transaction user (and then it would sit in the Accepted state until
timer M fires so it can pass any _other_ 200s that show up with the same
transaction identifier up to the TU - See figure 3 and the text above it
in RFC6026).
Consider a case where the original INVITE was parallel forked. One of
the forks behaves in this broken way and is the first to respond. Now
the state machine is in the Accepted state. In that state 1xx and
3xx-6xx responses are (IIUC) ignored. All *may* turn out if one of those
other forks eventually returns a 2xx. Otherwise the call will just time
out. Proper handling of the non-2xx final responses from the other forks
won't occur. And if the 1xx was needed (e.g. for preconditions) then
that won't work either.
Just dropping the broken 2xx would give better results. But I don't find
any text that justifies doing that in this case.
Thanks,
Paul
Now, at the TU level, the 200 that shows up will not match any
outstanding potential dialog (in some code-bases, you'll see these
called proto-dialogs). The specs don't say this explicitly (as far as I
recall anyhow), but the logic would follow something like this: "This
doesn't match any INVITE _I've_ sent - it's an unsolicited response, I'm
dropping it".
You might be tempted to try to ack on the 200, to at least stop the
retransmissions (and maybe stop any media that might be flowing from the
other end). If you do that, you could do whatever you do for any other
unsolicited 200 that just shows up. But in this case, those attempts are
likely to fail, and may make recovering from the mess worse, rather than
better. Assuming you don't have a malicious actor, and what happened was
that some B2BUAish thing changed the call-id in the request, but not the
response, then the ACK you send (remember that 200-ACKs are sent with a
new transaction identifier because they may take a different path than
the INVITES) is likely to also get changed. If you send the ACK with the
dialog identifiers from the INVITE, you _might_ get lucky and get the
same transformation out of the thing in the middle, but given the
different transaction ID, I suspect not. If you send the ACK with the
dialog identifiers from the 200, they're almost certainly going to be
changed before they get to the other side and the ACK won't be
recognized. So letting the TU just drop the 200 is the safest thing to
do in general.
Now, if you're in cohoots with the thing that's breaking the protocol,
you know enough about its behavior to work around its brokenness, but
then you're inventing some other protocol for a specific deployment and
the specs can't help you.
RjS
On 8/1/17 11:03 AM, Paul Kyzivat wrote:
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
_______________________________________________
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
