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

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Mar 2019 12:31:27 +0000

Hi,
        
        3GPP defines ”multi identity” and ”multi devices” concepts, which means that:
        
        1) A user can have multiple phone numbers; and
        2) A user can have multiple devices, each of which can be reached with any of those phone numbers
        
        Assume a user has:
        
        1) 2 phone numbers, each with a SIP URI and a tel URI representation ("phone_number1/SIP", "phone_number1/TEL", "phone_number2/SIP" and "phone_number2/TEL")
        2) Different devices, each with a different contact IP address ("IP-Address1", "IP-Address2" and "IP-Address3")
        
        A simplified reg-event notification would look like this:
        
        <registration aor=sip:phone_number1/SIP id="1" state="active">
         	<contact> <uri>IP-Address1</uri></contact>
         	<contact> <uri>IP-Address2</uri></contact>
         	<contact> <uri>IP-Address3</uri></contact>
        <registration aor=tel:phone_number1/TEL id="2" state="active">
         	<contact> <uri>IP-Address1</uri></contact>
         	<contact> <uri>IP-Address2</uri></contact>
         	<contact> <uri>IP-Address3</uri></contact>
        <registration aor=sip:phone_number2/SIP id="1" state="active">
         	<contact> <uri>IP-Address1</uri></contact>
         	<contact> <uri>IP-Address2</uri></contact>
         	<contact> <uri>IP-Address3</uri></contact>
        <registration aor=tel:phone_number2/TEL id="2" state="active">
         	<contact> <uri>IP-Address1</uri></contact>
         	<contact> <uri>IP-Address2</uri></contact>
         	<contact> <uri>IP-Address3</uri></contact>
        
        As you can see, the contact information is duplicated many times.
        
        Using an example based on the XML schema in RFC 3680 shows that the payload can get very big (I am using empty lines for readability):
        
        <?xml version="1.0" encoding="UTF-8"?>
        <!--Sample XML file generated by XMLSpy v2008 (http://www.altova.com)-->
        <tns:reginfo state="full" version="0" xsi:schemaLocation="urn:ietf:params:xml:ns:reginfo Untitled1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="urn:ietf:params:xml:ns:reginfo">
        
        <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>
            <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:bbbb]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
            <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:cccc]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
        </tns:registration>
         
        <tns:registration id="1234567890" aor="tel:+15556667777">
            <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>
            <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:bbbb]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
            <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:cccc]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
        </tns:registration>
        
        <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>
            <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:bbbb]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
            <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:cccc]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
        </tns:registration>
        
        <tns:registration id="1234567890" aor="tel:+15556667777">
            <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>
            <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:bbbb]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
            <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:cccc]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
            </tns:contact>
        </tns:registration>
        </tns:reginfo>
        
        If the number of phone numbers and/or devices increase, the payload size will grow rather rapidly.
        
        One can of course e.g., use message compression to reduce the size of the payload, but in my opinion the real problem is the fact that information is duplicated.
        
        When discussing this with some colleagues, one idea that came up was to use references: separate the 'contact elements' from the 'registration elements', and then simply reference the 'contact elements' from within the 'registration elements'.
        
        A simplified example would look something like (note the new anchor and target attributes):
        
        <contact> <uri>IP-Address1 anchor="1"</uri></contact>
        <contact> <uri>IP-Address2 anchor="2"</uri></contact>
        <contact> <uri>IP-Address3 anchor="3"</uri></contact>
        <registration aor=sip:phone_number1/SIP id="1" state="active"> 
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        <registration aor=tel:phone_number1/TEL id="2" state="active">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        <registration aor=sip:phone_number2/SIP id="1" state="active">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        <registration aor=tel:phone_number2/TEL id="2" state="active">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        
        If you apply this on the example based on the XML schema in RFC 3680 you will see a significant reduction in size:
        
        <?xml version="1.0" encoding="UTF-8"?>
        <!--Sample XML file generated by XMLSpy v2008 (http://www.altova.com)-->
        <tns:reginfo state="full" version="0" xsi:schemaLocation="urn:ietf:params:xml:ns:reginfo Untitled1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="urn:ietf:params:xml:ns:reginfo">
        
        <tns:contact event="registered" anchor="1" 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>
        <tns:contact event="registered" anchor="2" 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:bbbb]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
        </tns:contact>
        <tns:contact event="registered" anchor="3" 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:cccc]</tns:uri>
              <tns:display-name xml:lang="en-us">String</tns:display-name>
              <tns:unknown-param name="String">String</tns:unknown-param>
        </tns:contact>
        
        <tns:registration id="1234567890" aor="sip:mailto:[email-masked]">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        </tns:registration> 
        <tns:registration id="1234567890" aor="tel:+15556667777">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        </tns:registration>
        <tns:registration id="1234567890" aor="sip:mailto:[email-masked]">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        </tns:registration>
        <tns:registration id="1234567890" aor="tel:+15556667777">
        	<contact-ref target="1" />
        	<contact-ref target="2" />
        	<contact-ref target="3" />
        </tns:registration>
        </tns:reginfo>

       As far as standardization is concerned, I guess this could be done as an RFC 3680 update, by either defining an additional reg-event package with a new XML schema, OR defining an additional XML schema for the existing reg-event package (if that is allowed). In either case, the UA obviously need to be able to indicate support of the new schema.

        Comments?
        
        Regards,
        
        Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2019 12:34:27 -0400

Hi Christer,

I understand the problem. But I think we need to assess whether the 
problem is severe enough to justify the effort of deploying a solution. 
In any case I guess a solution would have to include backward 
compatibility, so it would only be applied if both client and server 
support it as an extension.

The solution you outline is straightforward. But if doing something it 
might be better to just do general compression. I think there are 
already MIME types for carrying compressed data. I don't know whether 
they are suitable here, but if so it might mean off-the-shelf code is 
available.

	Thanks,
	Paul

On 3/27/19 8:31 AM, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Mar 2019 21:07:20 +0000

Hi,
    
>    problem is severe enough to justify the effort of deploying a solution. 

It is causing problems, and people have been asked to find a solution. 

>    support it as an extension.
  
Sure. 

>    they are suitable here, but if so it might mean off-the-shelf code is 
  
Even if you compress, the receiver will still have to de-compress, parse and process everything etc, so it was not seen as a good solution.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2019 18:55:23 -0400

> Even if you compress, the receiver will still have to de-compress, parse and process everything etc, so it was not seen as a good solution.

The receiver has to change their decoding of the xml response, while 
still retaining the old processing in case the server doesn't support 
this new feature.

With compression it may be no more than making a library call to 
decompress the response and then process normally. So it *could* be easier.

I'm not trying to make the case that it *is* easier - only that I think 
the pros and cons need to be discussed more fully. I have no problem 
with establishing a work item around this issue.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 Mar 2019 21:46:04 -0400

Certainly the complaint that the content can become large is valid, as
its size is roughly the product of the number of devices and the number
of AORs.

But using contact references is only going to help when "all the stars
line up".  One of the example contact-registrations is:

And this is repeated verbatim for each of the 4 AORs.

But if, on each device, the user has a different display-name for each
of the AORs that can reach the device, then all 12 of the <contact>
elements have different <display-name> elements.  So you would need a
mechanism that allows more flexibility than just repeating exactly the
same <contact> element in multiple places.

Compare:  The use of "Accept-Encoding: gzip" and "Content-Encoding:
gzip" is already permitted and standardized.  We already have a
feature-negotiation process for it.  It's true that processing pure
contact-references is faster than un-gzipping and then processing the
full reginfo.  But if your major concern is data length (bandwidth),
gzip is *much* more efficient -- in the example, using
contact-references reduces the text to 2024 characters, but gzipping the
full reginfo gives only 394 octets.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Mar 2019 07:36:45 +0000

Hi,

    > decompress the response and then process normally. So it *could* be easier.

    If it was only about a large amount of data in general, I agree compression would be a good solution.

    But, the problem is a large amount of *duplicated* data, and the problem will only get worse the more phone numbers, devices and/or contacts you add. It is bad design and it does not scale.
  
    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Mar 2019 07:50:00 +0000

Hi,

>    its size is roughly the product of the number of devices and the number
  
Correct.
  
>    same <contact> element in multiple places.
  
That is true in theory.

But, at least based on me experience, that is not a real-deployment problem.

>    full reginfo gives only 394 octets.

Message size is only one problem.
  
Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 28 Mar 2019 17:45:12 -0400

> But, at least based on me experience, that is not a real-deployment

Should not each registration entry have a different instance-id/reg-id
(defined in https://tools.ietf.org/html/rfc5626) in unknown-param
attributes?

We see RFC 5626 and those parameters quite commonly implemented. Should the
proposed solution work when RFC 5262 implemented and these parameters are
used?

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Mar 2019 21:55:23 -0400

> (defined in https://tools.ietf.org/html/rfc5626) in unknown-param

Looking at the example more carefully.  The typical <registration> start
tag and the typical <contact> element look like this:

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 29 Mar 2019 00:52:30 -0400

> registrations from the same UA.
According to RFC5626, UA should maintain two different registrations with
the same sip.instance parameter and different reg-id parameters, which will
also show up in <unknown-param>. Also, if the same UA registers for
multiple different AOR, sip.instance will be the same across all of those
registrations, but reg-id parameter will be different. So, essentially, you
will need to deal with different reg-id in <unknown-param> across all of
those registrations.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Mar 2019 07:39:10 +0000

Hi,

> According to RFC5626, UA should maintain two different registrations with the same sip.instance parameter and 
> different reg-id parameters, which will also show up in <unknown-param>. Also, if the same UA registers for multiple 
> different AOR, sip.instance will be the same across all of those registrations, but reg-id parameter will be different. 
> So, essentially, you will need to deal with different reg-id in <unknown-param> across all of those registrations.

So, that means you would need separate contact elements for each reg-id. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Mar 2019 07:45:11 +0000

Hi Dale,

>deal with uniquess in the <uri> and 'id' strings.

My assumption is that the <uri> and 'id' are unique for each contact.    

>    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:

    

    

    
    
    Dale