Subject: [sipcore] Organizing the sip-push work

From: [email-masked] (Dale R. Worley)
Date: Sun, 25 Mar 2018 17:01:45 -0400

Casting up accounts from the recent discussions, it seems to me that the
various mechanisms can be divided into no less than *five* tranches, as
diagrammed below.

I recommend that we carry forward tranches 1 and 2 in
draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft,
oriented toward "supporting SIP Outbound with SIP Push".

I particularly desire to incorporate tranche 2 (the "pn-aor" parameter,
and allowing certain alternative behaviors by implementing proxies) into
the current draft, because:
1) It is a small extension of -08, where the UAs add one further URI
parameter.
2) It is upward-compatible from implementations of -08.
3) It allows implementation by "far" proxies, including edge proxies,
and supports UAs acquiring different addresses when they awaken.
4) The support for "far" proxies establishes an architectural
requirement that the pn-* parameters must be URI parameters (which would
otherwise be a poor architectural choice).

tranche 1	as in draft-ietf-sipcore-sip-push-08
		implemented by: implementing proxies, UAs supporting SIP Push
		enables: current implementations, "near" proxies,
			no requirement for non-std. communication with registrar
   |
   | upward compatible with
   |
   v
tranche 2	plus: pn-aor parameter
		implemented by: UAs supporting SIP Push, optionally by
			implementing proxies
		enables: "far" proxies, implementation by edge proxies,
			changing UA addresses (NAT traversal)
   |
   | upward compatible with
   |
   v
tranche 3	plus: pn-reg-id parameter
		implemented by: UAs supporting SIP Push with SIP Outbound,
			implementing proxies supporting SIP Outbound
		enables: SIP Push combined with SIP Outbound
   |
   | upward compatible with
   |
   v
tranche 4	plus: 'reg' event package extension 'path' element to report
			the Path header
		implemented by: registrars, optionally by proxies
		enables: SIP Push combined with SIP Outbound without having
			to watch for re-REGISTER or re-dispatch to the AOR

   |
   | independently upward compatible from tranche 1
   |
   v
tranche 5	plus: 'reg' event package extension 'last-reg' which is the
			number of seconds since the contact was last updated
		implemented by: registrars, optionally by proxies
		enables: implementing proxies do not need to send PN if
			the UA has recently reregistered

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Mar 2018 07:56:39 +0000

Hi,

I don¹t think that tranche 2 is a ³small extension of -08², since I think
it requires more than just defining a pn-aor parameter.

So, as it is an extension, my suggestion is to define it in a separate
draft. If you DO think it is a small extension, such draft should be short
and easy to put together :).

Regards,

Christer

On 26/03/18 00:01, "sipcore on behalf of Dale R. Worley"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Mar 2018 08:57:22 -0400

This is getting complicated fast.

Are there actual use cases for tranches 2-5?  I understand the actual use case for what Christer’s draft does.  I kind of get the need for interaction between PUSH and Outbound, although it’s not clear to me that there is an existing or planned implementation that needs it. More of a theoretic problem.

Let’s look more closely at Tranch 2: why does this case exist?  Why is the proxy changing it’s address and not re-registering?   Are you aware of implementations that do this, need PUSH and wouldn’t work with the existing text?  

Chairs would like this draft to finish shortly.  There seems to be a disconnect between you and the guy writing the text on how necessary and complicated it is to support “far” proxies.  We’re okay with a follow up draft dealing with interactions between PUSH and Outbound, but what do we really need to do to get this draft out the door and useful to implementors?

Brian

> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Mar 2018 14:00:42 -0400

Brian,

We had an existing implementation which have combined Push and Outbound for
a fairly large number of mobile end points. Since most of the mobile
clients are behind NAT and require SIPS, SIP Outbound and Push are commonly
deployed together. Our deployment was not based on the current SIP Push
draft, but it was not theoretical. This being said, I agree with Christer
that defining how SIP Outbound works with Push belongs to a new draft.

Regards,

_____________
Roman Shpount

On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen <[email-masked]> wrote:

> Are there actual use cases for tranches 2-5?  I understand the actual use
> case for what Christer’s draft does.  I kind of get the need for
> interaction between PUSH and Outbound, although it’s not clear to me that
> there is an existing or planned implementation that needs it. More of a
> theoretic problem.
>
> Let’s look more closely at Tranch 2: why does this case exist?  Why is the
> proxy changing it’s address and not re-registering?   Are you aware of
> implementations that do this, need PUSH and wouldn’t work with the existing
> text?
>
> Chairs would like this draft to finish shortly.  There seems to be a
> disconnect between you and the guy writing the text on how necessary and
> complicated it is to support “far” proxies.  We’re okay with a follow up
> draft dealing with interactions between PUSH and Outbound, but what do we
> really need to do to get this draft out the door and useful to implementors?
>
> Brian
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Mar 2018 14:13:05 -0400

Okay, that’s helpful - the new draft would address a real deployment (albeit you did something pre-standards).  

But you don’t know of anything that would match what Dale called “Tranche 2”, requiring the pn-aor and what Christer thinks is a bunch of text changes?

Brian

> On Mar 26, 2018, at 2:00 PM, Roman Shpount <[email-masked]> wrote:
> 
> Brian,
> 
> We had an existing implementation which have combined Push and Outbound for a fairly large number of mobile end points. Since most of the mobile clients are behind NAT and require SIPS, SIP Outbound and Push are commonly deployed together. Our deployment was not based on the current SIP Push draft, but it was not theoretical. This being said, I agree with Christer that defining how SIP Outbound works with Push belongs to a new draft.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 25, 2018, at 5:01 PM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Mar 2018 14:17:16 -0400

Brian,

I have mentioned this before to Dale -- I do not know of the use case for
Dale's " Tranche 2"

Regards,
_____________
Roman Shpount

On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen <[email-masked]> wrote:

> Okay, that’s helpful - the new draft would address a real deployment
> (albeit you did something pre-standards).
>
> But you don’t know of anything that would match what Dale called “Tranche
> 2”, requiring the pn-aor and what Christer thinks is a bunch of text
> changes?
>
> Brian
>
> We had an existing implementation which have combined Push and Outbound
> for a fairly large number of mobile end points. Since most of the mobile
>> Let’s look more closely at Tranch 2: why does this case exist?  Why is
>> the proxy changing it’s address and not re-registering?   Are you aware of

---

From: Mickey Arnold <[email-masked]>
Date: Tue, 27 Mar 2018 10:18:31 +0000

Brian,

Just to add my thoughts on this.

I can see a conceptual benefit to having some sort of mechanism for being able to distribute push Proxys across a network which I believe is what Dale is aiming to address in “Tranche 2” using “Far Proxys”.

However, like Roman and Christer I don’t see a use case for this that can’t be addressed using the current draft. I also think it will be quite complex to specify and that it should not be included in the base draft.

Thanks, Mickey

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 26 March 2018 19:17
To: Brian Rosen <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Organizing the sip-push work

Brian,

I have mentioned this before to Dale -- I do not know of the use case for Dale's " Tranche 2"

Regards,
_____________
Roman Shpount

On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
Okay, that’s helpful - the new draft would address a real deployment (albeit you did something pre-standards).

Brian

On Mar 26, 2018, at 2:00 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Regards,

_____________
Roman Shpount

On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
This is getting complicated fast.

Brian

> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Mar 2018 09:26:56 -0400

Thanks Mickey.

Does anyone have an actual use case for “Tranche 2”?  If not, I’m inclined to recommend that Christer proceed without it.

I think there is more than sufficient interest in the interaction of PUSH and Outbound, and we’ll make sure that is addressed in another draft.  I’d like to get this draft moving through approval processes soon.  If someone (Dale) wanted to contribute text to that draft for Tranche 2, we would of course consider it.

Brian

> On Mar 27, 2018, at 6:18 AM, Mickey Arnold <[email-masked]> wrote:
> 
> Brian,
>  
> On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 26, 2018, at 2:00 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Brian,
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 09:31:18 +0000

Hi,

Every operator that I have been in contact with regarding this have indicated that the currently defined mechanism works for them.

So, again, I’d be happy to discuss and participate in the work on extensions (I have already done some sketching for an Outbound extension), but I also think they should be defined in separate drafts, as they would require quite a bit of text and discussions.

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Brian Rosen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 27 March 2018 at 16:26
To: Mickey Arnold <[email-masked]<mailto:[email-masked]>>
Cc: Dale Worley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Organizing the sip-push work

Thanks Mickey.

Brian

On Mar 27, 2018, at 6:18 AM, Mickey Arnold <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

Thanks, Mickey

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 26 March 2018 19:17
To: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: Dale R. Worley <[email-masked]<mailto:[email-masked]>>; SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Organizing the sip-push work

Brian,

Regards,
_____________
Roman Shpount

Brian

Brian,

Regards,

_____________
Roman Shpount

Brian