Subject: Re: [sipcore] Draft new version: SIP Push (-15)

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Oct 2018 07:36:31 +0000

Hi,

I created a pull request with some text about Replaces.

https://github.com/cdh4u/draft-sip-push/pull/26

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Monday 1 October 2018 at 07:53
To: Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Draft new version: SIP Push (-15)

Hi,

There will be proxy based solutions deployed.

Operators need to configure their network so that routing is done correctly.

So, while I’m happy to add some text about the Replaces case, I do agree that we should move on.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 01 October 2018 06:19
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Draft new version: SIP Push (-15)

On Sun, Sep 30, 2018 at 5:44 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
This is not push specific. There are other cases (e.g., related to NAT traversal) where you need to make sure requests traverse a specific proxy.

And the only way to solve all of them is GRUU. Everything else breaks down at some point. For instance INVITE with Replaces is very hard to get to work right without GRUU.

One thing that worked for us when something like this was required (i.e. server for hosted NAT traversal and push) was to use B2BUA for registration instead of proxy. What this means is UA registers with B2BUA, B2BUA modifies registration contact to its own generated URL and registers with normal Register server. When response is received, B2BUA modifies the contact back to client actual contact and adds GRUU (which points to a URI on B2BUA server).  All requests to AOR for this client or requests in or out of the dialog (GRUU) are guaranteed to got though this B2BUA which can then do its NAT/Push magic.

This is how a lot of SBC work. This is what likely is going to be implemented but not what is going to be standardized. For this SBC to work you might need a standard mechanism to pass push notification parameters from the UA to SBC, which this draft already provides. The rest that we are inventing here is an excise to see if complete standard proxy based solution is possible (which is unlikely), but it is unlikely this proxy based solution will ever be used.

So, can we limit the scope to what is needed (passing push parameters in registration) and move on?

Regards,
_____________
Roman Shpount