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

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" <br@brianrosen.net> wrote:

    Write a draft!

    We’re not very busy.

    Brian

    > On Apr 2, 2019, at 5:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> 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.
    > 
    > 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" <sipcore-bounces@ietf.org on behalf of christer.holmberg@ericsson.com> 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" <worley@ariadne.com> wrote:
    > 
    >        Roman Shpount <roman@telurix.com> 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:+15556667777@ims.mnc001.mcc001.3gppnetworks.org">
    >            <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
    >    sipcore@ietf.org
    >    https://www.ietf.org/mailman/listinfo/sipcore
    > 
    > 