MIME-Version: 1.0
In-Reply-To: <CAMRcRGTPb1UFq9vhR2Ar2tp559UEWeJV2LT09D-Dqu4Q3W-Tbw@mail.gmail.com>
References: <CAMRcRGTPb1UFq9vhR2Ar2tp559UEWeJV2LT09D-Dqu4Q3W-Tbw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 13 Mar 2017 14:54:01 -0400
Message-ID: <CAD5OKxsz=6hmt6FK57T6idLohn+7aODK92M=0mSfFB5D4uASDQ@mail.gmail.com>
To: Suhas Nandakumar <suhasietf@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c03aefa146a53054aa13c4a
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/twVTzw9Agn4A8YQtYT8xsHOS0Uk>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE-SIP-SDP and RFC6544
Precedence: list

--94eb2c03aefa146a53054aa13c4a
Content-Type: text/plain; charset=UTF-8

It would probably be a good idea to have RFC6544bis. We can also use this
draft to define TLS ICE candidates.

One question I wanted to ask is do we need to maintain the same scope to
ICE TCP candidates? Do we really need simultaneous open TCP candidates? Are
there any plans of using TCP candidates to directly connection two end
points behind NAT or is it only going to be used in scenarios where one of
the end points is on the public IP? I think based on current usage patterns
RFC 6544 can be greatly simplified.

Regards,

_____________
Roman Shpount

On Mon, Mar 13, 2017 at 4:53 AM, Suhas Nandakumar <suhasietf@gmail.com>
wrote:

> Adam raised a valid point on the scope of RFC6544 in the context of
> ice-sip-sdp.
>
> We the authors did consider couple of options and would like the WG's
> inputs to decide the next steps
>
> 1. Merge in RFC6544 into ice-sip-sdp and ice-bis
>    This includes bringing in appropriate text from rfc6544 into ice-bis
> for ice processing detail and ice-sip-sdp for candidate encoding +
> offer/answer specifics
>
> 2. RFC6544bis
>    Do a bis version of RFC6544 and make it refer to ICE-BIS and
> ICE-SIP-SDP wherever appropriate.
>
> 3. Any other option ?
>
> We prefer option 2 given the magnitude of RFC6544 merge plan , but are
> open to suggestions from either or a new option altogether
>
> please advise.
>
>
> Cheers
> Suhas
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--94eb2c03aefa146a53054aa13c4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It would probably be a good idea to have=C2=A0<span style=
=3D"color:rgb(0,0,0);font-size:12.8px">RFC6544bis. We can also use this dra=
ft to define TLS ICE candidates.</span><div><span style=3D"color:rgb(0,0,0)=
;font-size:12.8px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12.8px">One question I wanted to ask is do we need to mainta=
in the same scope to ICE TCP candidates? Do we really need simultaneous=C2=
=A0open TCP candidates? Are there any plans of using TCP candidates to dire=
ctly connection two end points behind NAT or is it only going to be used in=
 scenarios where one of the end points is on the public IP? I think based o=
n current usage patterns RFC 6544 can be greatly simplified.</span></font><=
/div><div><font color=3D"#000000"><span style=3D"font-size:12.8px"><br></sp=
an></font></div><div><font color=3D"#000000"><span style=3D"font-size:12.8p=
x">Regards,</span></font></div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmail_signat=
ure">_____________<br>Roman Shpount</div></div>
<br><div class=3D"gmail_quote">On Mon, Mar 13, 2017 at 4:53 AM, Suhas Nanda=
kumar <span dir=3D"ltr">&lt;<a href=3D"mailto:suhasietf@gmail.com" target=
=3D"_blank">suhasietf@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Adam raised a valid point on the scope =
of RFC6544 in the context of ice-sip-sdp.</div><div><br></div><div>We the a=
uthors did consider couple of options and would like the WG&#39;s inputs to=
 decide the next steps</div><div><br></div><div>1. Merge in RFC6544 into ic=
e-sip-sdp and ice-bis</div><div>=C2=A0 =C2=A0This includes bringing in appr=
opriate text from rfc6544 into ice-bis for ice processing detail and ice-si=
p-sdp for candidate encoding + offer/answer specifics</div><div><br></div><=
div>2. RFC6544bis</div><div>=C2=A0 =C2=A0Do a bis version of RFC6544 and ma=
ke it refer to ICE-BIS and ICE-SIP-SDP wherever appropriate.</div><div><br>=
</div><div>3. Any other option ?</div><div><br></div><div>We prefer option =
2 given the magnitude of RFC6544 merge plan , but are open to suggestions f=
rom either or a new option altogether</div><div><br></div><div>please advis=
e.</div><div><br></div><div><br></div><div>Cheers</div><span class=3D"HOEnZ=
b"><font color=3D"#888888"><div>Suhas</div><div><br></div></font></span></d=
iv>
<br>______________________________<wbr>_________________<br>
mmusic mailing list<br>
<a href=3D"mailto:mmusic@ietf.org">mmusic@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mmusic" rel=3D"noreferrer"=
 target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/mmusic</a><br=
>
<br></blockquote></div><br></div>

--94eb2c03aefa146a53054aa13c4a--