Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch parameters

From: [email-masked] (Dale R. Worley)
Date: Sun, 24 Jan 2016 20:09:10 -0500

At the risk of opening a can of worms:

draft-ietf-sipcore-dns-dual-stack resembles RFC 3263 in that it
describes how to send a SIP request to a URI.  They provide a process
for resolving the URI into one or more network connection points
(address, port, and transport protocol), which the sender attempts to
contact in sequence until it successfully contacts the destination.

RFC 3263 states that the transmission to each address/port must have a
different Via branch parameter:

   If a failure occurs, the client SHOULD create a new request, which is
   identical to the previous, but has a different value of the Via
   branch ID than the previous (and therefore constitutes a new SIP
   transaction).  That request is sent to the next element in the list
   as specified by RFC 2782.

The nasty consequence of this is that if the destination receives one
request but its response (e.g., a 100 response) does not get back to the
sender in time, the sender can send another request to a different
address/port/transport that arrives at the same destination, but is
marked as being a different SIP transaction by the new branch parameter
value.  And so the destination processes this request as a different
branch of the SIP request.

I've seen this cause trouble in practice:  If proxy A routes to proxy B
using the URI <sip:example.com>, proxy A can attempt to contact proxy B
using UDP.  If it does not receive a response quickly, it can then
attempt to contact proxy B using TCP.  If there has been network
congestion, both the UDP datagram and the TCP SYN can arrive at proxy B
at the same time, and proxy B has no way to know that they are
"equivalent" and should be processed together.  Instead, proxy B will
forward one of them to the destination phone.  It will then forward the
other one to the destination phone, the phone rejects it with 482 (since
it's already ringing for another branch of this call), proxy B will then
sequentially-fork it to the phone's voice mail.  This leaves the
destination phone ringing and the caller's phone talking to the
destination user's voicemail.

A better user experience would be obtained if all copies of the request
were sent with the same branch parameter, so that the destination will
know to ignore all but the first copy that it received.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 25 Jan 2016 08:13:04 +0100

> On 25 Jan 2016, at 02:09, Dale R. Worley <[email-masked]> wrote:
> 

> know to ignore all but the first copy that it received.

I am not sure this is related to the draft, but it does indicate that
RFC 3263 may need a generic overhaul.

/O

---

From: Brett Tate <[email-masked]>
Date: Tue, 26 Jan 2016 11:14:23 -0500

Hi,

> A better user experience would be obtained if all copies of
> the request were sent with the same branch parameter, so that
> the destination will know to ignore all but the first copy
> that it received.

Although merged request handling can potentially be improved within SIP,
I'm not sure that the proposed improvement is better than current
behavior.  However, this draft will definitely cause more merged request
situations (and delays before advancing to reachable server).  I'm also
not sure if the proposed improvement actually addresses the real issue.
Are you experiencing a transaction correlation issue or just a lack of 1xx
to compliantly allow you to send CANCEL?

Changing the branch allows the sender to know which destination actually
worked.  Without that knowledge, it would not know the destination and
port for sending ACK-for-non-2xx and/or CANCEL (unless added something
else to the Via).

The requests can take different paths before merging.  Ignoring requests
from the different path can cause the path to appear non responsive
(although intermediary can send 100 response to reduce some of the side
effects).

Thanks,
Brett

---

From: Brett Tate <[email-masked]>
Date: Tue, 26 Jan 2016 12:34:26 -0500

Hi,

Sorry about resend.  After reading the raised issue again, you can ignore
my question since I now understand the service interaction issue that you
were raising.

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, January 26, 2016 11:14 AM
> To: 'Dale R. Worley'; [email-masked]'
> Subject: RE: [sipcore] draft-ietf-sipcore-dns-dual-stack: branch
parameters
>
> Hi,
>
> > A better user experience would be obtained if all copies of the
> > request were sent with the same branch parameter, so that the
> > destination will know to ignore all but the first copy that it
> > received.
>
I'm
> not sure that the proposed improvement is better than current behavior.
> However, this draft will definitely cause more merged request situations
(and
> delays before advancing to reachable server).  I'm also not sure if the
> proposed improvement actually addresses the real issue.  Are you
experiencing
> a transaction correlation issue or just a lack of 1xx to compliantly
allow
> you to send CANCEL?
port
> for sending ACK-for-non-2xx and/or CANCEL (unless added something else
to the
> Via).
from
> the different path can cause the path to appear non responsive (although
> intermediary can send 100 response to reduce some of the side effects).
>
> Thanks,
> Brett

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Jan 2016 20:50:19 -0500

Brett Tate <[email-masked]> writes:
> worked.

Yes, that's true.  I've been assuming without thinking about it that if
a 100 response arrives, the recipient can tell from the source
address/port of the 100 what destination/address port was used for the
request that is being responded to.  But of course, that's not true.

And that is the fatal flaw in my proposal, unless "added something else
to the Via", as you say.

Dale