Subject: [MMUSIC] 4566bis: local address in o=

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

Hi,

The text says:

<unicast-address> is an address of the machine from which the

                   session was created. For an address type of IP4, this is either a
                   fully qualified domain name of the machine or the dotted-decimal
                   representation of an IP version 4 address of the machine. For an
                   address type of IP6, this is either a fully qualified domain name
                   of the machine or the compressed textual representation of an IP
                   version 6 address of the machine. For both IP4 and IP6, the fully
                   qualified domain name is the form that SHOULD be given unless this
                   is unavailable, in which case a globally unique address MAY be
                   substituted. Unless an SDP extension for NAT traversal is used
                   (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST
                   NOT be used in any context where the SDP description might leave
                   the scope in which the address is meaningful (for example, a local
                   address MUST NOT be included in an application-level referral that
                   might leave the scope).

First, I guess it could be clarified that the “address of the machine” does not have to be the address used for the media (found in the c= line).

Second, I am not sure I understand how the support of ICE allows the usage of a local address. The combination of o= line parts are supposed to create a unique identifier, so what does ICE have to do with that?

Regards,

Christer

---

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

I think the intent here is to generate something similar to GUID which will
uniquely identify the SDP description, but this is severely outdated for
cases like ICE or privacy.

I think this needs to be updated to use sufficiently large random strings
instead of IP addresses, hostnames and  user IDs, when local address or
host name is not available or should not be exposed due to privacy reasons.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 6:33 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:24:53 +0000

Hi,

>I think the intent here is to generate something similar to GUID which will uniquely identify the SDP description,

I understand that, but I don’t see what ICE has to do with it.

> but this is severely outdated for cases like ICE or privacy. How is using a local address going to make the SDP unique just because I use ICE?
>
> I think this needs to be updated to use sufficiently large random strings instead of IP addresses, hostnames and
> user IDs, when local address or host name is not available or should not be exposed due to privacy reasons.

With SIP and offer/answer, is there even a need to uniquely identity the SDP description? The SDP will always be associated with a uniquely identified SIP session.

Regards,

Christer

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

The text says:

                   might leave the scope).

Regards,

Christer

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

---

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

Hi,

I seems like I placed a question in the wrong place.

It should be:

“I understand that, but I don’t see what ICE has to do with it. How is using a local address going to make the SDP unique just because I use ICE?”

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 12 December 2017 22:25
To: Roman Shpount <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] 4566bis: local address in o=

Hi,

Regards,

Christer

The text says:

                   might leave the scope).

Regards,

Christer

---

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

Christer,

The issue is, once again, third party call control and unexpected SDP offer
collisions between two SIP sessions. Because of this, if offer goes from
one SIP session to another due to B2BUA and third party call control, it is
important that o= line accidentally did not end up being the same between
two sessions. If o= line is the same, some clients do not parse or compare
SDP, assuming this is the same SDP description. Because of this, it is
important for o= line to be globally unique. One option is to use unique
system identifier (IP or host name), session identifier and version in the
session. Another option is to use something random which is long enough to
be unique.

When offer is generated when ICE is used, client might not know the
globally unique IP address when offer is generated. Client can use local
NATed address, but this often results in collisions. The actual advise for
this case (use local IP) is actually counter productive, since using local
IP is more likely to result in collisions then using something random. This
probably needs to be corrected.

Regards,

_____________
Roman Shpount

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

> “I understand that, but I don’t see what ICE has to do with it. How is
> using a local address going to make the SDP unique just because I use ICE?”
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 12 December 2017 22:25
> *To:* Roman Shpount <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] 4566bis: local address in o=
>
>
>
> Hi,
>
>
>
> >I think the intent here is to generate something similar to GUID which
> will uniquely identify the SDP description,
>
>
>
> > but this is severely outdated for cases like ICE or privacy. How is
> using a local address going to make the SDP unique just because I use ICE?
>
> >
>
> > I think this needs to be updated to use sufficiently large random
> strings instead of IP addresses, hostnames and
>
> With SIP and offer/answer, is there even a need to uniquely identity the
> SDP description? The SDP will always be associated with a uniquely
> identified SIP session.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>

---

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

Hi,

>The issue is, once again, third party call control and unexpected SDP offer collisions between two SIP sessions. Because of this, if offer goes from one SIP >session to another due to B2BUA and third party call control, it is important that o= line accidentally did not end up being the same between two sessions. If >o= line is the same, some clients do not parse or compare SDP, assuming this is the same SDP description. Because of this, it is important for o= line to be >globally unique. One option is to use unique system identifier (IP or host name), session identifier and version in the session. Another option is to use >something random which is long enough to be unique.

Fair enough.

>When offer is generated when ICE is used, client might not know the globally unique IP address when offer is generated. Client can use local NATed >address, but this often results in collisions. The actual advise for this case (use local IP) is actually counter productive, since using local IP is more likely to >result in collisions then using something random. This probably needs to be corrected.

Also, the address is supposed to be “the address of the machine from which the session was created”. That address is whatever is the same, no matter if you have NATs or not. Note that the text does not mandate the address that you are going to use for media etc – just *AN* address of the machine.

Regards,

Christer

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

It should be:

Regards,

Christer

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 12 December 2017 22:25
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] 4566bis: local address in o=

Hi,

Regards,

Christer

The text says:

                   might leave the scope).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Dec 2017 16:48:50 -0500

On 12/12/17 3:38 PM, Roman Shpount wrote:
> Christer,
> 
> The issue is, once again, third party call control and unexpected SDP 
> offer collisions between two SIP sessions. Because of this, if offer 
> goes from one SIP session to another due to B2BUA and third party call 
> control, it is important that o= line accidentally did not end up being 
> the same between two sessions. If o= line is the same, some clients do 
> not parse or compare SDP, assuming this is the same SDP description. 
> Because of this, it is important for o= line to be globally unique. One 
> option is to use unique system identifier (IP or host name), session 
> identifier and version in the session. Another option is to use 
> something random which is long enough to be unique.

As things are currently specified, it isn't valid for the session to 
change for the duration of the sip dialog. A 3PCC B2BUA is responsible 
for ensuring this remains the case during a transfer. How it does so is 
its business, but in the end will require rewriting SDP.

However, I realize that doesn't often (ever?) happen. Perhaps there 
ought to be an effort to change things to acknowledge that the session 
can change, and specify what is to happen when it does.

	Thanks,
	Paul

> NATed address, but this often results in collisions. The actual advise 
> for this case (use local IP) is actually counter productive, since using 
> local IP is more likely to result in collisions then using something 
> random. This probably needs to be corrected.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Tue, Dec 12, 2017 at 3:28 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi,____
> 
>     __ __
> 
>     I seems like I placed a question in the wrong place.____
> 
>     __ __
> 
>     It should be:____
> 
>     __ __
> 
>     “I understand that, but I don’t see what ICE has to do with it. How
>     is using a local address going to make the SDP unique just because I
>     use ICE?”____
> 
>     __ __
> 
>     Regards,____
> 
>     __ __
> 
>     Christer____
> 
>     __ __
> 
>     __ __
> 
>     *From:*mmusic [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Christer Holmberg
>     *To:* Roman Shpount <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [MMUSIC] 4566bis: local address in o=____
> 
>     __ __
> 
>     Hi,____
> 
>     __ __
> 
>      >I think the intent here is to generate something similar to GUID
>     which will uniquely identify the SDP description,____
> 
>     __ __
> 
>     I understand that, but I don’t see what ICE has to do with it.____
> 
>     __ __
> 
>      > but this is severely outdated for cases like ICE or privacy. How
>     is using a local address going to make the SDP unique just because I
>     use ICE?____
> 
>      >__ __
> 
>     strings instead of IP addresses, hostnames and ____
> 
>     >  user IDs, when local address or host name is not available or
>     should not be exposed due to privacy reasons.____
> 
>     __ __
> 
>     With SIP and offer/answer, is there even a need to uniquely identity
>     the SDP description? The SDP will always be associated with a
>     uniquely identified SIP session.____
> 
>     __ __
> 
>     Regards,____
> 
>     __ __
> 
>     Christer____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Hi,____
> 
>         __ __
> 
>         The text says:____
> 
>         __ __
> 
>         <unicast-address> is an address of the machine from which the____
> 
>                             session was created. For an address type of
>         IP4, this is either a____
> 
>                             fully qualified domain name of the machine
>         or the dotted-decimal____
> 
>                             representation of an IP version 4 address of
>         the machine. For an____
> 
>                             address type of IP6, this is either a fully
>         qualified domain name____
> 
>                             of the machine or the compressed textual
>         representation of an IP____
> 
>                             version 6 address of the machine. For both
>         IP4 and IP6, the fully____
> 
>                             qualified domain name is the form that
>         SHOULD be given unless this____
> 
>                             is unavailable, in which case a globally
>         unique address MAY be____
> 
>                             substituted. Unless an SDP extension for NAT
>         traversal is used____
> 
>                             (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a
>         local IP address MUST____
> 
>                             NOT be used in any context where the SDP
>         description might leave____
> 
>                             the scope in which the address is meaningful
>         (for example, a local____
> 
>                             address MUST NOT be included in an
>         application-level referral that____
> 
>                             might leave the scope).____
> 
>         First, I guess it could be clarified that the “address of the
>         machine” does not have to be the address used for the media
>         (found in the c= line).____
> 
>         __ __
> 
>         Second, I am not sure I understand how the support of ICE allows
>         the usage of a local address. The combination of o= line parts
>         are supposed to create a unique identifier, so what does ICE
>         have to do with that?____
> 
>         __ __
> 
>         Regards,____
> 
>         __ __
> 
>         Christer____
> 
>         __ __
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>____
> 
>     __ __
> 
> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Dec 2017 08:48:46 +0000

Hi,

>can change, and specify what is to happen when it does.

This of course depends on what we mean by ³session². Even if the SIP
session doesn¹t change, does it mean the SDP session can¹t change?

Regards,

Christer

>><mailto:[email-masked]>>
>> wrote:
>> 
>>     Hi,____
>> 
>>     __ __
>> 
>>     ³I understand that, but I don¹t see what ICE has to do with it. How
>>     use ICE?²____
>>     I understand that, but I don¹t see what ICE has to do with it.____
>> 
>>     __ __
>> 
>>         First, I guess it could be clarified that the ³address of the
>>         machine² does not have to be the address used for the media

---

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

> On 12 Dec 2017, at 20:24, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>  

Remember this comes from the Mbone days with multicast session directories. For that type of use, uniquely identifying SDP descriptions is important. The Mbone is surely dead, but declarative SDP isn’t necessarily, so the ability to uniquely identify the SDP is maybe still needed.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Dec 2017 10:08:10 +0000

Hi,

Hi,

> Remember this comes from the Mbone days with multicast session directories. For that type of use, uniquely identifying SDP descriptions is important. The Mbone is surely dead, but declarative SDP i…

Sure. But, then the text could mandate uniqueness, unless there is some other mechanism to ensure it.

Anyway, I have no issue with mandating uniqueness. My issue is more the text on addresses itself.

Regards,

Christer

---

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

> session doesn¹t change, does it mean the SDP session can¹t change?

I'd have to reread all the relevant text to be certain, but I'm pretty 
sure the current text at least implies that a given dialog is tied to a 
single SDP session. Certainly there is nothing that explains what is to 
be done if the SDP session changes.

IMO this is an open issue that has been studiously ignored forever.

Question is whether there is any interest in confronting it. But this 
isn't an issue for 4566bis.

	Thanks,
	Paul

---

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

Christer Holmberg <[email-masked]> writes:
> This of course depends on what we mean by 'session'. Even if the SIP
> session doesn't change, does it mean the SDP session can't change?

s/SIP session/SIP dialog/

The RFCs presume that a SIP dialog will be associated with exactly one
SDP session, and so if a UA does 3PCC gymnastics, the UA has to adjust
the SDP that it passes through to match the requirements for "a
successor SDP for a session".  (I once hacked through this in detail --
see what that looks like in RFC 7088.  It's not pretty.)

The odds are that most devices don't enforce these requirements
strictly.  But clearly, some do -- I've seen complaints about one device
that terminated a dialog if it received SDP with the wrong sess-id.
Certainly, there are devices that assume that if the o= line doesn't
change, the rest of the SDP must be the same as before.

Dale

---

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

> change, the rest of the SDP must be the same as before.

That is encouraged by the text that defines the semantics.

As a programmer I am never so trusting. I always process the SDP as if 
it were changed, or else verify it is unchanged. (E.g. save and check a 
hash of the body.) But I guess some implementors are more trusting.