Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Sep 2018 19:31:59 +0000

Hi,

>>> I don’t think the proxy needs to modify the Contact. The proxy can
>>> provide a local GRUU e.g., using a media feature tag. That is my
>>> idea for providing the “random value” (no matter whether it is a
>>> GRUU or not).
>> 
>> Ok, we can define a new media feature tag that proxy can add to 
>> response which will be used similar to permanent GRUU. The push 
>> enabled UA will use value of this field as a contact for all dialog 
>> creating requests it will send.
>
> Just be careful about calling it a gruu unless it actually has gruu properties.

Well, most likely it won't be possible to use the "GRUU" outside the dialog to reach the UA...

Also, I had some discussions about usage of a local GRUU provided by the proxy, and people had concerns that this would prevent the UA from generating a local GRUU by its own - whatever the use-case for that would be.

A suggestion was to instead use the instance id: the UA would provide the instance id in the REGISTER, and in the initial request for the dialog. The push proxy would then map the instance id of the dialog to the registration/PRID, and be able to request a push notification when it e.g., receives a NOTIFY.  I think that sounds like a good suggestion.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 2 Sep 2018 19:32:41 -0400

> Well, most likely it won't be possible to use the "GRUU" outside the dialog to reach the UA...

Then it is most definitely not a GRUU!

> A suggestion was to instead use the instance id: the UA would provide the instance id in the REGISTER, and in the initial request for the dialog. The push proxy would then map the instance id of th…

This sounds better, modulo security concerns.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Sep 2018 04:24:49 +0000

Hi,

>> Also, I had some discussions about usage of a local GRUU provided by the proxy, and people had concerns that 
>> this would prevent the UA from generating a local GRUU by its own - whatever the use-case for that would be.
>> 
>> A suggestion was to instead use the instance id: the UA would provide the instance id in the REGISTER, and in 
>> the initial request for the dialog. The push proxy would then map the instance id of the dialog to the registration/PRID, 
>> and be able to request a push notification when it e.g., receives a NOTIFY.  I think that sounds like a good suggestion.
>

I guess whatever normal security concerns associated with instance id apply.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Sep 2018 13:57:29 -0400

> I guess whatever normal security concerns associated with instance id

The only issue I see here is privacy, since instance-id can be used for
fingerprinting and allows extraction of information about user, such as
what device this user is currently using. When GRUU is used, in
circumstances where privacy is a concern, instance-id is only be visible to
Registrar. If UA wants to hide its identity, it will use temporary GRUU in
the contact which will not expose instance-id to other parties in the
dialog. In practice, if GRUU is not used, direct user contact address is
already visible and same information can already be extracted. I would
suggest that in this draft, we should put a note that if privacy is a
concern, GRUU support must be installed and and temp GRUU must be used.

Regards,
_____________
Roman Shpount