Subject: [sipcore] Call recovery

From: [email-masked] (Dale R. Worley)
Date: Mon, 19 Sep 2016 14:42:36 -0400

I talked to some people at SIPit about "call recovery", that is, how to
resume a call when the interface through which the signaling and media
are passing becomes unusable, but another interface is usable.

(There is also the easier "make before break" case, when the old
interface remains usable during the process of moving the call to the
new interface, but it can be solved by any method that works for the
"break before make" case.)

It seems that the common method for call recovery is to send a re-INVITE
for the dialog giving the address of the new interface as the local
target URI.  The limitation of re-INVITE is that it cannot change the
route set, and so it requires that the first URI of the route set can be
used as a single-hop address from the new interface.  In general, there
is a concern that the first route set URI may be an internal proxy in
the carrier, and if the two interfaces attach to two last-mile carriers,
that proxy may not be accessible from the new interface.  Indeed, its
URI may not be properly interpretable from the new interface.

It seems to me that a better alternative is to send an
INVITE-with-Replaces from the new interface to the remote target URI of
dialog.  This is effectively a consultative transfer to the new
interface and changes the Call-Id.  In order for this to work:

The remote target is either the other endpoint of the call, or the
first SBC in the signaling path.

The remote target must support INVITE-with-Replaces.  However, because
INV/Rep is used to implement consultative transfers, it seems that
essentially all remote targets must support it.

According to the SIPit 31 summary, 72% of endpoints support replaces.
(Presumably the support level for mature products in the market is
higher.)

In any case, the UA should learn during call setup whether the remote
target supports INV/Rep via the "Supported: replaces" header.

The remote target needs to act like a GRUU.  Of necessity, the remote
target reaches a UA that has access to the state of the dialog, but in
addition, it needs to be globally routable.  The executing UA should be
able to determine whether the remote target is a GRUU by looking for the
gr URI parameter.

If the remote target is the other endpoint, the support for GRUU is
weak.  The SIPit 31 summary shows only 28% of the endpoints supporting
GRUU.  OTOH, 67% of proxies provide GRUU support.

More likely, the remote target will be a B2BUA in a carrier network.  In
principle, it should be fairly easy for all first-hop B2BUAs to provide
GRUU target URIs, but it adds another element of network engineering.

Comments?

Dale

---

From: Ranjit Avasarala <[email-masked]>
Date: Tue, 20 Sep 2016 15:52:18 -0500

I think by interfaces being unusable, you mean the interfaces are down? in
that case if there is no response for the requests - after timeout the call
ends. so how do you recover the call?  I think we can max establish the
call again once interfaces are up.

Correct me if I am missing something

Thanks
Ranjit

On Mon, Sep 19, 2016 at 1:42 PM, Dale R. Worley <[email-masked]> wrote:

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

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Sep 2016 04:05:47 +0000

If you want to follow this through, I suggest you look at 3GPP TS 24.237, where the scope is to replace a SIP connection where IP has disappeared, with a CS connection, and other variants. (You may need to reference 3GPP TS 23.237 for some architectural support).

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 19 September 2016 19:43
To: [email-masked]
Subject: [sipcore] Call recovery

I talked to some people at SIPit about "call recovery", that is, how to resume a call when the interface through which the signaling and media are passing becomes unusable, but another interface is usable.

(There is also the easier "make before break" case, when the old interface remains usable during the process of moving the call to the new interface, but it can be solved by any method that works for the "break before make" case.)

It seems that the common method for call recovery is to send a re-INVITE for the dialog giving the address of the new interface as the local target URI.  The limitation of re-INVITE is that it cannot change the route set, and so it requires that the first URI of the route set can be used as a single-hop address from the new interface.  In general, there is a concern that the first route set URI may be an internal proxy in the carrier, and if the two interfaces attach to two last-mile carriers, that proxy may not be accessible from the new interface.  Indeed, its URI may not be properly interpretable from the new interface.

It seems to me that a better alternative is to send an INVITE-with-Replaces from the new interface to the remote target URI of dialog.  This is effectively a consultative transfer to the new interface and changes the Call-Id.  In order for this to work:

The remote target is either the other endpoint of the call, or the first SBC in the signaling path.

The remote target must support INVITE-with-Replaces.  However, because INV/Rep is used to implement consultative transfers, it seems that essentially all remote targets must support it.

In any case, the UA should learn during call setup whether the remote target supports INV/Rep via the "Supported: replaces" header.

The remote target needs to act like a GRUU.  Of necessity, the remote target reaches a UA that has access to the state of the dialog, but in addition, it needs to be globally routable.  The executing UA should be able to determine whether the remote target is a GRUU by looking for the gr URI parameter.

If the remote target is the other endpoint, the support for GRUU is weak.  The SIPit 31 summary shows only 28% of the endpoints supporting GRUU.  OTOH, 67% of proxies provide GRUU support.

More likely, the remote target will be a B2BUA in a carrier network.  In principle, it should be fairly easy for all first-hop B2BUAs to provide GRUU target URIs, but it adds another element of network engineering.

Comments?

Dale

---

From: Brett Tate <[email-masked]>
Date: Wed, 21 Sep 2016 08:18:43 -0400

Hi,

> It seems to me that a better alternative is
> to send an INVITE-with-Replaces from the new
> interface to the remote target URI of dialog.
> This is effectively a consultative transfer to
> the new interface and changes the Call-Id.

<snip>

> Comments?

Repost from sip-implementors... solutions using things like Replaces and
REFER raise the typical concerns with authorization, security, billing, et
cetera.  For instance, see security section of RFC 3891.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Sep 2016 10:43:00 -0400

> call again once interfaces are up.

The situation is where one interface of the UA goes down, but another
interface (e.g., a different radio network) is available.  The goal is
to somehow re-route the call to use the interface that is up, before the
call times out.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Sep 2016 11:18:08 -0400

> cetera.  For instance, see security section of RFC 3891.

I don't see authorization as much of a problem, because you can't apply
an INVITE-with-Replaces to a call without knowing the INVITE carrying
the Call-Id of the call it will affect.

As for billing, the INVITE-with-Replaces, in order to work, has to reach
the remote target of the original call, which in a typical carrier case,
will be some B2BUA inside the carrier of the first leg of the original
call.  So that carrier doesn't lose the call, and can apply whatever
billing policy it wants.

(In an ideal world, that B2BUA would just proxy (without Record-Route)
the INVITE through to the remote target of the next leg, taking itself
out of the call entirely.)

Dale

---

From: Brett Tate <[email-masked]>
Date: Wed, 21 Sep 2016 14:05:22 -0400

Hi,

> > Repost from sip-implementors... solutions using
> > things like Replaces and REFER raise the typical
> > concerns with authorization, security, billing,
> > et cetera.  For instance, see security section of
> > RFC 3891.
>
> I don't see authorization as much of a problem,
> because you can't apply an INVITE-with-Replaces to
> a call without knowing the INVITE carrying the Call-Id
> of the call it will affect.

RFC 3891's security section discusses the non-trivial concept of
legitimate authorization (and security impacts supporting RFC 3891).

> As for billing, the INVITE-with-Replaces, in order
> to work, has to reach the remote target of the
> original call, which in a typical carrier case, will
> be some B2BUA inside the carrier of the first leg of
> the original call.  So that carrier doesn't lose the
> call, and can apply whatever billing policy it wants.

That is the potential concern (although potentially irrelevant to IETF).
Whoever sends and/or honors the INVITE with Replaces might not find the
billing consequences to be acceptable.  Thus they couldn't use the
solution within some deployments/situations.

> (In an ideal world, that B2BUA would just proxy (without
> Record-Route) the INVITE through to the remote target
> of the next leg, taking itself out of the call entirely.)

Although some disagree, the operator/user might find it more ideal to keep
the B2BUA within the path.

The IMS solution appears to mandate adding Record-Route instead of
replacing gruu Contact during call setup.  If this means that the
Application Server will be bypassed within some situations, it might
impact/prevent some types of services provided by the Application Server.