Subject: Re: [sipcore] SIP-push -- Where is the "proxy"?

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Mar 2018 22:22:29 -0500

Christer Holmberg <[email-masked]> writes:
> The assumption is that the proxy is able to retrieve the needed
> registration information, either by being in the path of the REGISTER
> (which is the case in all scenarios I am aware of), or retrieving the
> information using some other mechanism.

It seems to me that the difficult case is not when the proxy retrieves
the registration information, but that the proxy must know when the
re-REGISTER has been sent.

On one hand, as you say, the proxy can be in the path of the REGISTER.
That requires that the proxy be "near" the registrar, so that any
REGISTER for the AOR will necessarily pass through the proxy as well.
But that pretty much requires that the proxy be attached to the
registrar, as otherwise REGISTERs can take routes to the registrar that
miss the proxy.

(I particularly imagine the WiFi/cellular use case that Roman mentions,
which has been a huge market target for over 10 years.  In that case,
the phone can easily re-REGISTER on an entirely different network than
it was previously registered through.)

But if the proxy is "near the edge", it needs a way to wait for the
re-REGISTER that doesn't require it to process the re-REGISTER.  I think
that this can be done by it subscribing to the 'reg' package for the
AOR, but that requires that the R-URI that it sees in the incoming
request to somehow carry the AOR.

OTOH, perhaps we will just limit sip-push implementations to require
that the proxy be very near the registrar, if not entirely integrated
with it.  In that case, the design can be simplified, probably even more
than it is now.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Mar 2018 00:55:22 -0500

Dale,

I suggest you go through RFC 5626 since it addresses most of your
questions. SIP-push should really be an update for RFC 5626 which optimizes
the connection maintenance process when no calls are in process and push
notifications are available. While calls are in process plain RFC 5626
procedures and flow maintenance is used.

Regards,

_____________
Roman Shpount

On Thu, Mar 8, 2018 at 10:22 PM, Dale R. Worley <[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Mar 2018 07:34:17 +0000

Hi,

>with it.  In that case, the design can be simplified, probably even more

I think what we now have is what the industry is requesting at the moment.

Later, if there is a need to have the proxy ³out-of-path² etc, we can
define new parameters etc needed for that in a separate draft.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Mar 2018 22:00:34 -0400

Christer Holmberg <[email-masked]> writes:
> Later, if there is a need to have the proxy 'out-of-path' etc, we can

I can agree with this as a general concept, but I have qualms:  The
current version doesn't seem to specifically enunciate the situation in
which the problem is being solved, so it's hard to judge whether it is
the best solution we can devise for the problem.

That is, I get the feeling that the draft was more devised to document
*a* solution that works for some reasonably large problem area, rather
than consciously ensuring it is the best solution we can devise for a
well-defined problem space.  In particular, though I've got to get
caught up on it, it seems like a number of features of the solution are
directly driven by a perceived distance between the registrar and the
proxy that is implementing sip-push, but at the same time, the handling
of re-REGISTER requires that there be little or no distance between the
registrar and the implementing proxy.

Dale