Subject: [MMUSIC] 4566bis: sending user ID in o=

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Dec 2017 10:52:03 +0000

Hi,

As I have not followed all discussions on 4566bis, so please let me know if the following has been discussed.

Regarding the “o=“ parameter, the text says:

<username>  is the user's login on the originating host, or it is "-"
            if the originating host does not support the concept of user IDs.
            The <username> MUST NOT contain spaces.

Even if the originating host supports “the concept of user IDs” (whatever that means), it may not want to send it for privacy reasons.

Couldn’t we instead say SHOULD send “-“, but MUST be able to receive whatever (for backward compatibility)?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Dec 2017 14:19:33 -0500

Hi Christer,

I do not see any reason why user should be prohibited from sending their
user ID, if they do no care about privacy.

I would rephrase this as:

<username> is the user's login on the originating host. If the origination
host does not support the concept of user IDs or if there are any concerns
of end user privacy, "-" SHOULD be used as the <username> value. The
<username> must not contain spaces.

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Dec 2017 20:22:26 +0000

Hi Roman,

What user ID is the text talking about? The user ID of my computer? The user ID of my VoIP application? Any user ID?

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 12 December 2017 21:20
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=

Hi Christer,

I do not see any reason why user should be prohibited from sending their user ID, if they do no care about privacy.

<username> is the user's login on the originating host. If the origination host does not support the concept of user IDs or if there are any concerns of end user privacy, "-" SHOULD be used as the <username> value. The <username> must not contain spaces.

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Dec 2017 15:29:56 -0500

Hi Christer,

I think the original intent was the logged in user in the computer system.
I remember RAT (Real Audio Tool) looking at the logged in user on UNIX and
putting "user" on Windows.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi Roman,
>
>
>
> What user ID is the text talking about? The user ID of my computer? The
> user ID of my VoIP application? Any user ID?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* 12 December 2017 21:20
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] 4566bis: sending user ID in o=
>
>
>
> Hi Christer,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Dec 2017 20:38:46 +0000

Hi,

>I think the original intent was the logged in user in the computer system. I >remember RAT (Real Audio Tool) looking at the logged in user on UNIX and >putting "user" on Windows.

Well, is ANYONE putting a user name there today? I have only seen “-“.

And, again, with SIP you are going to have all user-related information in the SIP signalling.

Regards,

Christer

On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 12 December 2017 21:20
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=

Hi Christer,

_____________
Roman Shpount

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Dec 2017 16:18:00 -0500

Hi,

Just looking at my proxy logs, I see a few examples (I have obfuscated IP
addresses):

Sonus: o=Sonus_UAC 859850 235378 IN IP4 999.999.999.999
BlueJeans: o=BlueJeans 3722043602 3722043602 IN IP4 999.999.999.999
Asterisk (Actually gets Unix user): o=root 1311534312 1311534312 IN IP4
999.999.999.999
Firefox: o=mozilla...THIS_IS_SDPARTA-57.0.2 2394261013661016088 0 IN IP4
0.0.0.0
Cisco: o=MSSMGC 90576391 0 IN IP4 999.999.999.999
Skype SIP gateway: o=3726170464 1513055056 1513055056 IN IP4 999.999.999.999

So, I would say putting user or product name in o= line is pretty common.

Putting product and version can also be useful if call goes through B2BUA
which hides SIP signaling, but SDP o= and s= can still be used to identify
the original client software make and version.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:38 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> >I think the original intent was the logged in user in the computer
> system. I >remember RAT (Real Audio Tool) looking at the logged in user
> on UNIX and >putting "user" on Windows.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Dec 2017 22:20:56 +0000

I don’t think a product name is a user ID, is it? :)

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 12 December 2017 23:18
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=

Hi,

Just looking at my proxy logs, I see a few examples (I have obfuscated IP addresses):

Sonus: o=Sonus_UAC 859850 235378 IN IP4 999.999.999.999
BlueJeans: o=BlueJeans 3722043602 3722043602 IN IP4 999.999.999.999
Asterisk (Actually gets Unix user): o=root 1311534312 1311534312 IN IP4 999.999.999.999
Firefox: o=mozilla...THIS_IS_SDPARTA-57.0.2 2394261013661016088 0 IN IP4 0.0.0.0
Cisco: o=MSSMGC 90576391 0 IN IP4 999.999.999.999
Skype SIP gateway: o=3726170464 1513055056 1513055056 IN IP4 999.999.999.999

Putting product and version can also be useful if call goes through B2BUA which hides SIP signaling, but SDP o= and s= can still be used to identify the original client software make and version.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:38 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Hi Christer,

_____________
Roman Shpount

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Dec 2017 17:31:12 -0500

Probably not the clearest name even for this spec. Should be user agent ID
or something similar.

Regards,
_____________
Roman Shpount

On Tue, Dec 12, 2017 at 5:20 PM, Christer Holmberg <
[email-masked]> wrote:

> *Sent:* 12 December 2017 23:18
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Dec 2017 23:24:54 -0500

Christer Holmberg <[email-masked]> writes:
> What user ID is the text talking about? The user ID of my computer?
> The user ID of my VoIP application? Any user ID?

Reading RFC 4566 section 5.2, I suspect the original thinking was "if we
combine the host's address, the time (at 1 sec resolution), and the user
name, that will surely be unique" -- but that only host address and time
together might risk that two users will fire up the VoIP application
during the same second.

So the answer is more or less, "a user ID is a thing which can only
start one SDP session per second".

What really matters is the global uniqueness constraint.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Dec 2017 06:55:02 +0000

Hi,

>start one SDP session per second".

Šwhich means one should not use a product name.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Dec 2017 02:11:37 -0500

Hi,

>start one SDP session per second".

which means one should not use a product name.

Which is true only if NTP is used for <sess-id>. If you use some other way
to generate sess-id for the given address, then it can be any string with
no spaces.

The only real requirements are that combination of <username> <sess-id>
<nettype> <addrtype> <unicast-address> is unique and that <sess-version>
monotonicaly increases. The rest are mostly outdated and widely ignored
suggestions.

Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Dec 2017 07:17:42 +0000

Hi,

With so many parameters forming the unique value, I don’t think the risk for collision is very small.

My main issue is the text. Perhaps we should simply say that <username> is a token, and MAY contain user ID, product ID, or whatever else. And, if people don’t want to include a value, they use “-“.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 13 December 2017 at 09:11
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Dale Worley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=

Hi,

Which is true only if NTP is used for <sess-id>. If you use some other way to generate sess-id for the given address, then it can be any string with no spaces.

The only real requirements are that combination of <username> <sess-id> <nettype> <addrtype> <unicast-address> is unique and that <sess-version> monotonicaly increases. The rest are mostly outdated and widely ignored suggestions.

Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Dec 2017 07:18:43 +0000

I think the risk for collision is very small, that is.

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 13 December 2017 at 09:17
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=

Hi,

Regards,

Christer

Hi,

Roman Shpount

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Dec 2017 09:54:10 +0000

Hi,

> On 12 Dec 2017, at 20:29, Roman Shpount <[email-masked]> wrote:
> 
> I think the original intent was the logged in user in the computer system. I remember RAT (Real Audio Tool) looking at the logged in user on UNIX and putting “user" on Windows.

Right - originally all this stuff (vic, RAT, sdr, etc.) was running on Unix workstations, and the username in SDP (and the username part of the RTCP CNAME) was the Unix login name of the user. The Windows ports made us think a little more about this, which is where the “-“ came from. These days, we likely want to say SHOULD use “-“ but allow other values that look like a username for backwards compatibility.

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Dec 2017 10:55:48 -0500

On 12/13/17 2:11 AM, Roman Shpount wrote:
> Hi,
> 
> On Dec 13, 2017 1:55 AM, "Christer Holmberg" 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> Which is true only if NTP is used for <sess-id>. If you use some other 
> way to generate sess-id for the given address, then it can be any string 
> with no spaces.
> 

To be pedantic for a moment: Even if every implementation takes care to 
ensure that each combined value they generate is unique from every 
other, without any agreement on how these are formed there is a risk 
that values from different implementations may conflict.

Stepping back to the real world, I agree that the *likelihood* of such a 
conflict is small.

This risk is eliminated if everyone follows the "suggestion" to use an 
NTP timestamp. Perhaps it is time to elevate this suggestion to SHOULD.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Dec 2017 22:15:10 -0500

> monotonicaly increases. The rest are mostly outdated and widely ignored

Basically, no other requirement is verifiable from outside the UA, and
so isn't enforceable.

Of course, actually satisfying that requirement isn't so easy.  As
Christer points out on another thread, <unicast-address> has low
information content in a world with NATs.  So either <username> or
<sess-id> needs to contain a large number of statistically-random bits.

Dale