Subject: [sipcore] Why forking calls does not solve transport problems

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Jul 2016 15:18:25 -0400

The question was raised during the Sipcore session of why forking does
not solve dual-stack problems.  I attempted to outline how problems
arise with forking, but I made some mistakes in the details.  This is a
cleaned-up version.

Naively, one thinks that sending a duplicate of a request to an
alternative target should not cause a problem, because the ultimate
destination UA can arbitrate between multiple requests, rejecting all
but the first with 482.

I used to think that myself.

But I ran into a customer whose SIP system failed in ways that point out
problems.  They had two offices.  Each was served by a proxy/registrar
that handled the phones in that office.  The two proxies routed calls to
phones in the other office via the other office's proxy.  Each proxy was
paired with a voicemail server that took voicemail for its office's
phones.

Voicemail was handed in the usual way:  A call was serially forked first
to the registered contacts for the AOR, and if those timed out, the call
was forked to the voicemail server.

The ultimate cause of the problem was that each proxy forwarded to the
other using the proxy's DNS name, but without a transport specification.
In effect, forwarded calls could be serially forked, first by UDP
transmission, then by TCP transmission.  (Or perhaps it was the other
order.)  This isn't *real* forking, since the sending proxy doesn't
record alternative targets (network addresses) for one destination URI
as forks, but the destination can receive two copies of one INVITE, with
different branch values (see RFC 3263 section 4.3), so they look like
different forks to the recipient.

Occasionally, the network between the two proxies was slow, and when a
proxy sent an INVITE to the other, the other proxy didn't respond
quickly enough, and so the proxy sent another "fork" of the INVITE to
the other proxy using the other transport.

At this point, one "fork" runs from proxy 1 to proxy 2 and then to the
phone, where it rings.  The second "fork" runs from proxy 1 to proxy 2
-- which handles it as specified -- sending the second INVITE to the
phone.

The phone rejects the second INVITE with 482.  This causes the second
proxy to step the second "fork" to the second destination, viz., the
voicemail server.

The voicemail server answers immediately, sending a 200 response.  That
propagates back to proxy 1, which considers the call established.  But
since proxy 1 does not see forking, it does not cancel the first INVITE
it sent.  So the phone continues to ring until the user picks up the
call.  But the caller is talking to the voicemail system.

In the case of our customer, the solution was to change the URIs that
each used for the other proxy to specify a transport parameter and
eliminate the implicit forking.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Jul 2016 15:53:44 -0400

This sounds correct (and underlines the existing problem with forking).

One of the solutions that we deployed for dual network scenario was to send
multiple INVITE or REGISTRATION requests over all available networks.
Identical VIA branch value was used for all of those messages to indicate
they are part of the same transaction. The way the system was designed all
of these messages would be terminated by the same B2BUA/Registrations agent
which was selected based on the VIA branch hash value. This
B2BUA/Registration agent was specifically designed to aggregate messages
received over multiple transports into a single transaction which prevented
problems like the one described above. I know this is not a generic
solution which can be applied everywhere but it worked quite well with
variety of fixed and mobile networks across multiple countries for a fairly
large user base.

Regards,
_____________
Roman Shpount

On Wed, Jul 20, 2016 at 3:18 PM, Dale R. Worley <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>