Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Apr 2019 09:23:02 +0000

Hi,

I'd like to ask the chairs and AD on some guidance on how to move forward with this. There seems to be interest in the issue.

As I have indicated, I *personally* think the real problem is duplication of data, so simply compressing it does not really solve the problem longterm, and that is the input I have received from others too.

We for sure need to take Outbound (read: reg-id and instance-id) into consideration.

Regards,

Christer

On 29/03/2019, 9.45, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Dale,
    
    >So any scheme for abridging registration events is likely to have to
    >deal with uniquess in the <uri> and 'id' strings.
    
    My assumption is that the <uri> and 'id' are unique for each contact.    
    
    >    A better way to judge this is to look at a *real* registration event for
    >    a situation like this -- say, three UAs registered for the same three
    >    AORs.  Does anyone have any examples to share?
    
    The example I gave was reflecting a real deployment scenario.
    
    Regards,
    
    Christer

    On 29/03/2019, 3.55, "Dale R. Worley" <[email-masked]> wrote:
    
        Roman Shpount <[email-masked]> writes:
        > Should not each registration entry have a different instance-id/reg-id
        > (defined in https://tools.ietf.org/html/rfc5626) in unknown-param
        > attributes?
        
        Looking at the example more carefully.  The typical <registration> start
        tag and the typical <contact> element look like this:
        
        <tns:registration id="1234567890" aor="sip:mailto:[email-masked]">
            <tns:contact event="registered" id="2345678901" duration-registered="4294967295"
        	 cseq="4294967295" retry-after="4294967295" q="0" state="active"
        	 callid="String" expires="4294967295">
              <tns:uri>sip:+15556667777@[2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
        
        As I read RFC 3680, the id attribute of <registration> and the id
        attribute of <contact> have to be unique within the <reginfo>.
        
        The actual name of the AOR displayed to the user on the device is likely
        to be customized, but I was probably wrong regarding the <display-name>
        element here -- it's taken from the Contact header in the REGISTER
        request, and most likely is empty.
        
        The sip.instance in the Contact will show up as an <unknown-param>
        element, but it should be the same for all <contact> elements for
        registrations from the same UA.
        
        The <uri> element -- the contact URI -- is likely to contain both some
        part of the AOR and the IP address of the UA, and so they're likely to
        be different for every <contact> element.
        
        So any scheme for abridging registration events is likely to have to
        deal with uniquess in the <uri> and 'id' strings.
        
        A better way to judge this is to look at a *real* registration event for
        a situation like this -- say, three UAs registered for the same three
        AORs.  Does anyone have any examples to share?
        
        Dale

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Apr 2019 11:33:40 -0400

I think RFC 3680 is due for payload schema update.

One thing that always bothered me about RFC 3680 was that it does not
expose RFC 3327 Path information.

Regards,
_____________
Roman Shpount

On Tue, Apr 2, 2019 at 5:23 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I'd like to ask the chairs and AD on some guidance on how to move forward
> with this. There seems to be interest in the issue.
>
> As I have indicated, I *personally* think the real problem is duplication
> of data, so simply compressing it does not really solve the problem
> longterm, and that is the input I have received from others too.
>
> On 29/03/2019, 9.45, "sipcore on behalf of Christer Holmberg" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>     Hi Dale,
>
>         <tns:registration id="1234567890" aor="sip:mailto:+
> [email-masked]">
>               <tns:uri>sip:+15556667777@
> [2001:0db8:85a3:0000:0000:8a2e:0370:aaaa]</tns:uri>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Apr 2019 18:45:33 +0000

Hi,

Just to clarify: if we want to change the schema, I think it should be done as a *new* schema. We should keep the old schema as it is, not to break existing deployments.

So, we would have two schemas (the old one and the new one), and obviously the associated mechanisms to negotiate and indicate support of them.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Tuesday, 2 April 2019 at 18.34
To: Christer Holmberg <[email-masked]>
Cc: Dale Worley <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] reg-event issue with multi-identity/multi-device

One thing that always bothered me about RFC 3680 was that it does not expose RFC 3327 Path information.

Regards,
_____________
Roman Shpount

On Tue, Apr 2, 2019 at 5:23 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

On 29/03/2019, 9.45, "sipcore on behalf of Christer Holmberg" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi Dale,

    Regards,

    Christer

    On 29/03/2019, 3.55, "Dale R. Worley" <[email-masked]<mailto:[email-masked]>> wrote:

        <tns:registration id="1234567890" aor="sip:mailto:[email-masked]<mailto:[email-masked]>">

        Dale

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Apr 2019 15:22:24 -0400

On Tue, Apr 2, 2019 at 2:45 PM Christer Holmberg <
[email-masked]> wrote:

> Just to clarify: if we want to change the schema, I think it should be
> done as a **new** schema. We should keep the old schema as it is, not to
> break existing deployments.
>
>
>
> So, we would have two schemas (the old one and the new one), and obviously
> the associated mechanisms to negotiate and indicate support of them.
>

I agree, but adding references within registration information imply new
schema and the mechanism to negotiate it. The typical solution would  be to
define a new MIME type for new schema version.

In general, I am not as much concerned with resulting schema size, but I
would like to make relationships between registrations and current use
cases, such as SIP Outbound, more obvious. For instance, if the same device
registers for the same AOR across multiple paths, the schema should reflect
this. In any case, I think RFC 3680 event schema is due for an update to
reflect current use cases, including one which result in high data
repetition.

Regards,
_____________
Roman Shpount

---

From: Brian Rosen <[email-masked]>
Date: Tue, 2 Apr 2019 16:05:57 -0400

Write a draft!

We’re not very busy.

Brian

> On Apr 2, 2019, at 5:23 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 03 Apr 2019 22:01:46 -0400

> The example I gave was reflecting a real deployment scenario.

I tend to be dubious about something that "reflects" something else.
I'd much rather see a real example with whatever masking is necessary --
and an explanation of exactly what masking has been applied.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Apr 2019 06:19:39 +0000

Hi,

I'm happy to put something together regarding the duplication issue.

I'm also happy to cover Outbound, but at the moment I don't have a suggestion on how/what/if modifications are needed.

Regards,

Christer

On 02/04/2019, 23.06, "Brian Rosen" <[email-masked]> wrote:

    Write a draft!
    
    We’re not very busy.
    
    Brian