Subject: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Jul 2019 14:30:42 +0000

Hi,

I realized the following when taking a look at draft-ice-sip-sdp after having worked on draft-ice-pac the last few days:

Section 3.3.4 says:

  “Once the state of each check list is Completed, and if the agent is
   the controlling agent, it nominates a candidate pair [RFC8445] and
   checks for each data stream whether the nominated pair matches the
   default candidate pair.”

This is not necessarily true. An agent can nominate even if one or more check list is Failed, based on whether the agent wants to establish a session without the streams associated with the failed check lists.

So, perhaps something like:

  “Once the state of enough check lists is Completed, and if the agent is
   the controlling agent, it nominates a candidate pair [RFC8445] for each
   Completed check list. In addition, for each Completed check list the agent
   checks whether the nominated pair matches the default candidate pair of
   that check list. If there are one or more check lists without a match, and
  the peer did not…”

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Jul 2019 17:36:00 -0400

Hi Christer,

This makes sense, but I am not sure it is precise enough. What we are
trying to say is that ICE nomination process is done (completed or failed)
for all streams and no new candidate pairs are going to be nominated.

Do you know if there is a simpler way to say this?

Best Regards,
_____________
Roman Shpount

On Wed, Jul 17, 2019 at 10:30 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I realized the following when taking a look at draft-ice-sip-sdp after
> having worked on draft-ice-pac the last few days:
>
>
>
> Section 3.3.4 says:
>
>
>
> This is not necessarily true. An agent can nominate even if one or more
> check list is Failed, based on whether the agent wants to establish a
> session without the streams associated with the failed check lists.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Jul 2019 22:13:56 +0000

Hi,

>This makes sense, but I am not sure it is precise enough. What we are trying to say is that ICE nomination >process is done (completed or failed) for all streams and no new candidate pairs are going to be nominated.

The text talks about when the nomination starts.

Regards,

Christer

On Wed, Jul 17, 2019 at 10:30 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Section 3.3.4 says:

Regards,

Christer

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Jul 2019 18:35:57 -0400

On Wed, Jul 17, 2019 at 6:14 PM Christer Holmberg <
[email-masked]> wrote:

> trying to say is that ICE nomination >process is done (completed or failed)
Starts or ends?

The sentence in 3.3.4 was supposed to mean that when ICE nomination process
completes and if for any stream non-default candidate was nominated and
ice2 option was not set, to send a new offer.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jul 2019 06:15:06 +0000

Hi,

>>>This makes sense, but I am not sure it is precise enough. What we are trying to say is that ICE nomination
>>>process is done (completed or failed) for all streams and no new candidate pairs are going to be nominated.
>>
>The sentence in 3.3.4 was supposed to mean that when ICE nomination process completes and if for any stream non-default
>candidate was nominated and ice2 option was not set, to send a new offer.

It also says that :)

But, the first sentence says:

“Once the state of each check list is Completed, and if the agent is
the controlling agent, it nominates a candidate pair [RFC8445]…”

…which at least to me describes when the nomination starts.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 18 Jul 2019 17:56:04 -0400

On Thu, Jul 18, 2019 at 2:15 AM Christer Holmberg <
[email-masked]> wrote:

> trying to say is that ICE nomination
>
> >>>process is done (completed or failed) for all streams and no new
> candidate pairs are going to be nominated.
>
> >>
>
> >The sentence in 3.3.4 was supposed to mean that when ICE nomination
> process completes and if for any stream non-default
>

This is actually still about the nomination end. Essentially, what is
described here is at the end of the nomination process, for each stream a
candidate pair is nominated (or the stream failed). If ice2 option is not
set, and pair nominated in the end is not the default candidate pair for
this stream, then new offer should be sent to "true up" default candidates.

What this whole language is missing is that for some streams nomination can
fail without failure of the entire session. Stream failure should also
result in a new offer with the failed streams disabled (port set to 0). I
am not sure this is specified anywhere. Another thing which is not
specified anywhere if new offer due to stream failure is only required if
ice2 option is not set or always. I would vote for always to make sure this
m= line can be reused.

Best Regards.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jul 2019 22:18:12 +0000

Hi,

> This is actually still about the nomination end. Essentially, what is described here is at the end of the nomination process,
>for each stream a candidate pair is nominated (or the stream failed). If ice2 option is not set, and pair nominated in the end
>is not the default candidate pair for this stream, then new offer should be sent to "true up" default candidates.
>
>What this whole language is missing is that for some streams nomination can fail without failure of the entire session. Stream failure
>should also result in a new offer with the failed streams disabled (port set to 0). I am not sure this is specified anywhere. Another thing
>which is not specified anywhere if new offer due to stream failure is only required if ice2 option is not set or always. I would vote for
>always to make sure this m= line can be reused.

Not sure what you mean by “nominating process”. My understanding of “nomination” is when the agent picks a Valid Pair and sends a STUN request with the nomination bit set.

But, in any case the “Once the state of each check list is Completed,” statement is wrong.  Of course an implementation might mandate that each check list must be Completed in order to establish the session, but there is no requirement in the ICE standard that each check list has to be Completed in order to do so

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 18 Jul 2019 19:04:28 -0400

On Thu, Jul 18, 2019 at 6:18 PM Christer Holmberg <
[email-masked]> wrote:

> described here is at the end of the nomination process,
> >for each stream a candidate pair is nominated (or the stream failed). If
> ice2 option is not set, and pair nominated in the end
> >What this whole language is missing is that for some streams nomination
> can fail without failure of the entire session. Stream failure
>
> >should also result in a new offer with the failed streams disabled (port
> set to 0). I am not sure this is specified anywhere. Another thing
>
> >which is not specified anywhere if new offer due to stream failure is
> only required if ice2 option is not set or always. I would vote for
>
> Not sure what you mean by “nominating process”. My understanding of
> “nomination” is when the agent picks a Valid Pair and sends a STUN request
> with the nomination bit set.
>
>
>
> But, in any case the “Once the state of each check list is Completed,”
> statement is wrong.  Of course an implementation might mandate that each
> check list must be Completed in order to establish the session, but there
> is no requirement in the ICE standard that each check list has to be
> Completed in order to do so
>
>
>
The language is about end of ICE process, when all candidate lists are in
either Completed or Failed state. Nominated pair at the time the list is in
the Completed state is the final pair used for communications.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jul 2019 09:29:10 +0000

Hi,

>> Not sure what you mean by “nominating process”. My understanding of “nomination” is when the agent picks a 
>> Valid Pair and sends a STUN request with the nomination bit set.
>> 
>> But, in any case the “Once the state of each check list is Completed,” statement is wrong.  Of course an implementation might mandate 
>> that each check list must be Completed in order to establish the session, but there is no requirement in the ICE standard that each check 
>> list has to be Completed in order to do so
>
> The language is about end of ICE process, when all candidate lists are in either Completed or Failed state.
>
> Nominated pair at the time the list is in the Completed state is the final pair used for communications.

Not sure what you mean by "final pair". There might be many valid pairs associated with a check list, and the agent picks which it wants to nominate. That then becomes the "valid pair".

Maybe we could say:

   "Once the state of *A* check list is Completed, and if the agent is
   the controlling agent, it nominates a candidate pair [RFC8445] and
   checks whether the nominated pair matches the
   default candidate pair associated with the check list."

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jul 2019 18:58:55 -0400

Christer,

On Fri, Jul 19, 2019 at 5:29 AM Christer Holmberg <
[email-masked]> wrote:

> >>> for each stream a candidate pair is nominated (or the stream failed).
> If ice2 option is not set, and pair nominated in the end
> >>> is not the default candidate pair for this stream, then new offer
> should be sent to "true up" default candidates.
> >>>
> >>>should also result in a new offer with the failed streams disabled
> (port set to 0). I am not sure this is specified anywhere. Another thing
> “nomination” is when the agent picks a
> statement is wrong.  Of course an implementation might mandate
> >> that each check list must be Completed in order to establish the
> session, but there is no requirement in the ICE standard that each check
> Not sure what you mean by "final pair". There might be many valid pairs
> associated with a check list, and the agent picks which it wants to
> nominate. That then becomes the "valid pair".
>
> Maybe we could say:
>
Once check list is in Completed state (
https://tools.ietf.org/html/rfc8445#section-8.1.1) only one pair should be
in nominated state. This candidate pair becomes the selected pair for that
agent and is used for sending and receiving data for that component of the
data stream. In cases of aggressive nomination, agents selects the
nominated pair with the highest priority. If this selected pair does not
match the default candidate pair, and "ice2" option was not specified, then
controlling agent MUST send a new offer with default candidate set to the
local candidate in the selected pair for the default component, single
candidate per component set to the local candidate of the selected pair,
and single remote-candidate per component set to the remote candidate in
the selected pair. Answer will contain the same. In other words, the new
offer is sent, when only one pair per data stream component is left,
nomination process was already completed, and single candidate pair per
data stream per component is going to be used until the next ICE restart.
This is, essentially, a default candidate "true up".

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2019 05:48:50 +0000

Hi,

…

>Once check list is in Completed state (https://tools.ietf.org/html/rfc8445#section-8.1.1) only one pair should be in
>nominated state. This candidate pair becomes the selected pair for that agent and is used for sending and receiving
>data for that component of the data stream. In cases of aggressive nomination, agents selects the nominated pair with
>the highest priority. If this selected pair does not match the default candidate pair, and "ice2" option was not specified,
>then controlling agent MUST send a new offer with default candidate set to the local candidate in the selected pair for
>the default component, single candidate per component set to the local candidate of the selected pair, and single
>remote-candidate per component set to the remote candidate in the selected pair. Answer will contain the same.
>In other words, the new offer is sent, when only one pair per data stream component is left, nomination process was
>already completed, and single candidate pair per data stream per component is going to be used until the next ICE restart

Correct. I don’t think my comment contradicts the text above.

But, let’s take a step back. There is another issue with the text in draft-ice-sip-sdp, so maybe my issue becomes more clear once that has been addressed.

Again, the text says:

The text indicates that the agent nominates a candidate pairs once a check list is Completed. That is wrong. A check list becomes Completed *after* a candidate pair has been successfully nominated. Do you agree with that?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jul 2019 15:02:43 -0400

Hi Christer,

On Tue, Jul 23, 2019 at 1:48 AM Christer Holmberg <
[email-masked]> wrote:

> The text indicates that the agent nominates a candidate pairs once a check
> list is Completed. That is wrong. A check list becomes Completed **after**
> a candidate pair has been successfully nominated. Do you agree with that?
>
>
>
I would agree that this text can be better. In general, in English two
verbs in present tense in a sentence do not establish the temporal
relationship between the actions. Better text would say something like:

Once the state of each check list is Completed, and if the agent is the
controlling agent, it *should have nominated* a candidate pair [RFC8445]
and checks for each data stream whether the nominated pair matches the
default candidate pair.

There are still a few issues with this:

1. If aggressive nomination is used, multiple candidate pairs can be
nominated for the same component of a given data stream. Considering that
aggressive nomination is deprecated, nothing implementing ice-sip-sdp
should be doing this and only one candidate pair (per component per data
stream) should be nominated. I do not think this is a problem.

2. This language does not take into account that state for some check lists
can be Failed. It is unclear if new offer should always be generated in
this case or only generated if ice2 options is not set. I am not sure what
is the use case for partial ICE failure. I have never dealt with this in
practice. If you feel this needs to be fixed, please propose the language.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2019 21:29:02 +0000

Hi,

>> The text indicates that the agent nominates a candidate pairs once a check list is Completed. That is wrong. 
>> A check list becomes Completed *after* a candidate pair has been successfully nominated. Do you agree with that?
>
> I would agree that this text can be better. In general, in English two verbs in present tense in a sentence do not establish the temporal 
> Once the state of each check list is Completed, and if the agent is the controlling agent, it should have nominated a 
> candidate pair [RFC8445] and checks for each data stream whether the nominated pair matches the default candidate pair.
>
> 1. If aggressive nomination is used, multiple candidate pairs can be nominated for the same component of a 
> given data stream. Considering that aggressive nomination is deprecated, nothing implementing ice-sip-sdp 
> should be doing this and only one candidate pair (per component per data stream) should be nominated. I do not 
> think this is a problem.

Agree.

> 2. This language does not take into account that state for some check lists can be Failed. It is unclear if new offer should 
> always be generated in this case or only generated if ice2 options is not set. I am not sure what is the use case for partial 
> ICE failure. I have never dealt with this in practice. If you feel this needs to be fixed, please propose the language.

"Once the agent has successfully nominated a pair, the state of the check list associated with the pair is set to Completed.
Once the state of each check list is set to either Completed or Failed, for each Completed check list the
agent checks whether the nominated pair matches the default candidate pair. If there are one or more pairs that don't match,..."

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jul 2019 17:41:14 -0400

On Tue, Jul 23, 2019 at 5:29 PM Christer Holmberg <
[email-masked]> wrote:

> "Once the agent has successfully nominated a pair, the state of the check
> list associated with the pair is set to Completed.
> agent checks whether the nominated pair matches the default candidate
> pair. If there are one or more pairs that don't match,..."
>
>
I am still unclear about Failed. I would prefer the last sentence to say:

Once the agent has successfully nominated a pair, the state of the check
list associated with the pair is set to Completed. Once the state of each
check list is set to either Completed or Failed, for each Completed check
list the agent checks whether the nominated pair matches the default
candidate pair. If there are one or more pairs that don't match, or if
there are any Failed check lists, and the peer did not indicate support for
the 'ice2' ice-option, the controlling agent MUST generate a subsequent
offer (Section 3.4.1), in which the connection address, port and transport
protocol in the "c=" and "m=" lines associated with each data stream match
the corresponding local information of the nominated pair for that data
stream. Data streams associated with a Failed check lists MUST be rejected
by setting port in "m=" line to zero.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2019 22:10:55 +0000

Hi,

> Once the agent has successfully nominated a pair, the state of the check list associated with the pair is set to Completed. 
> Once the state of each check list is set to either Completed or Failed, for each >Completed check list the 
> agent checks whether the nominated pair matches the default candidate pair. If there are one or more pairs that don't match, 
> or if there are any Failed check lists, and the peer did not indicate support for the 'ice2' ice-option, the controlling agent MUST 
> generate a subsequent offer (Section 3.4.1), in which the connection address, port and transport protocol in the "c=" and "m=" 
> lines associated with each data stream match the corresponding local information of the nominated pair for that data stream. 
> Data streams associated with a Failed check lists MUST be rejected by setting port in "m=" line to zero.

If there are Failed check lists, shouldn't there be a subsequent update with port set to zero no matter if there is 'ice2' or not?

RFC 8445 says that "The agent MUST take proper actions for removing the failed data stream."

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jul 2019 18:17:54 -0400

On Tue, Jul 23, 2019 at 6:10 PM Christer Holmberg <
[email-masked]> wrote:

> >> "Once the agent has successfully nominated a pair, the state of the
> check list associated with the pair is set to Completed.
> pair. If there are one or more pairs that don't match,
> > or if there are any Failed check lists, and the peer did not indicate
> support for the 'ice2' ice-option, the controlling agent MUST
> > generate a subsequent offer (Section 3.4.1), in which the connection
> address, port and transport protocol in the "c=" and "m="
> > lines associated with each data stream match the corresponding local
> information of the nominated pair for that data stream.
> If there are Failed check lists, shouldn't there be a subsequent update
> with port set to zero no matter if there is 'ice2' or not?
>
You are right and I would assume ice-sip-sdp should spell this out. How
about:

Once the agent has successfully nominated a pair, the state of the check
list associated with the pair is set to Completed. Once the state of each
check list is set to either Completed or Failed, for each Completed check
list the agent checks whether the nominated pair matches the default
candidate pair. If there are one or more pairs that don't match, and the
peer did not indicate support for the 'ice2' ice-option, the controlling
agent MUST generate a subsequent offer (Section 3.4.1), in which the
connection address, port and transport protocol in the "c=" and "m=" lines
associated with each data stream match the corresponding local information
of the nominated pair for that data stream. Furthermore, if there are any
Failed check lists, the controlling agent MUST always generate a subsequent
offer, even if  the peer did indicate support for the 'ice2' ice-option.
This offer MUST reject all data streams associated with a Failed check
lists by setting port in "m=" line to zero.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2019 22:32:58 +0000

Hi,

...

> You are right and I would assume ice-sip-sdp should spell this out. How about:
>
> Once the agent has successfully nominated a pair, the state of the check list associated with the pair is set to Completed. Once the state of
> each check list is set to either Completed or Failed, for each Completed check list the agent checks whether the nominated pair matches the 
> default candidate pair. If there are one or more pairs that don't match, and the peer did not indicate support for the 'ice2' ice-option, the controlling 
> agent MUST generate a subsequent offer (Section 3.4.1), in which the connection address, port and transport protocol in the "c=" and "m=" lines 
> associated with each data stream match the corresponding local information of the nominated pair for that data stream. Furthermore, if there are 
> any Failed check lists, the controlling agent MUST always generate a subsequent offer, even if  the peer did indicate support for the 'ice2' ice-option. 
> This offer MUST reject all data streams associated with a Failed check lists by setting port in "m=" line to zero.

Looks good. Just a few minor editorial change suggestions:

Once the agent has successfully nominated a pair, the state of the check list associated with the pair is set to Completed. Once the state of
each check list is set to either Completed or Failed, for each Completed check list the agent checks whether the nominated pair matches the 
default candidate pair. If there are one or more pairs that don't match, and the peer did not indicate support for the 'ice2' ice-option, the controlling 
agent MUST generate a subsequent offer, in which the connection address, port and transport protocol in the "c=" and "m=" lines 
associated with each data stream match the corresponding local information of the nominated pair for that data stream (Section 3.4.1.2.2.). 
Furthermore, if there are one or more check lists with the state set to Failed, the controlling agent MUST generate a subsequent offer in order to remove 
the associated data streams by setting the port value of the data streams to zero (Section 3.4.1.1.2.), even if  the peer did indicate support for the 'ice2' ice-option. 

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Jul 2019 18:40:32 -0400

On Tue, Jul 23, 2019 at 6:33 PM Christer Holmberg <
[email-masked]> wrote:

> list associated with the pair is set to Completed. Once the state of
> each check list is set to either Completed or Failed, for each Completed
> check list the agent checks whether the nominated pair matches the
> default candidate pair. If there are one or more pairs that don't match,
> and the peer did not indicate support for the 'ice2' ice-option, the
> controlling
> agent MUST generate a subsequent offer, in which the connection address,
> port and transport protocol in the "c=" and "m=" lines
> of the nominated pair for that data stream (Section 3.4.1.2.2.).
> Furthermore, if there are one or more check lists with the state set to
> Failed, the controlling agent MUST generate a subsequent offer in order to
> remove
> the associated data streams by setting the port value of the data streams
> to zero (Section 3.4.1.1.2.), even if  the peer did indicate support for
> the 'ice2' ice-option.
>

This looks good to me too. I have copied Suhas so that he can review and
update draft-ietf-mmusic-ice-sip-sdp section 3.3.4 (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-36#section-3.3.4)

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Jul 2019 09:33:36 +0000

Hi,

It would be really good if the draft was on GitHub. Then one could submit pull requests with the new text, and one will be able to better follow what the changes in the next version of the draft will be.

Because, this is not the only issue I raised. I also had comments regarding the ice-option and ice-pacing attribute.

Regards,

Christer

From: mmusic <[email-masked]> on behalf of Roman Shpount <[email-masked]>
Date: Wednesday, 24 July 2019 at 1.41
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement

On Tue, Jul 23, 2019 at 6:33 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Once the agent has successfully nominated a pair, the state of the check list associated with the pair is set to Completed.. Once the state of
each check list is set to either Completed or Failed, for each Completed check list the agent checks whether the nominated pair matches the
default candidate pair. If there are one or more pairs that don't match, and the peer did not indicate support for the 'ice2' ice-option, the controlling
agent MUST generate a subsequent offer, in which the connection address, port and transport protocol in the "c=" and "m=" lines
associated with each data stream match the corresponding local information of the nominated pair for that data stream (Section 3.4.1.2.2.).
Furthermore, if there are one or more check lists with the state set to Failed, the controlling agent MUST generate a subsequent offer in order to remove
the associated data streams by setting the port value of the data streams to zero (Section 3.4.1.1.2.), even if  the peer did indicate support for the 'ice2' ice-option.

This looks good to me too. I have copied Suhas so that he can review and update draft-ietf-mmusic-ice-sip-sdp section 3.3.4 (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-36#section-3.3.4)

Best Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 25 Jul 2019 11:15:26 -0700

Hi Christer
   Roman has been submitting PRs here in the past. Please feel free to
submit the PR and thanks for starting the discussion.

https://github.com/suhasHere/ice-sip-sdp/blob/master/ice_sip_sdp.coriander

Cheers
Suhas

On Wed, Jul 24, 2019 at 2:33 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> It would be really good if the draft was on GitHub. Then one could submit
> pull requests with the new text, and one will be able to better follow what
> the changes in the next version of the draft will be.
>
>
>
> Because, this is not the only issue I raised. I also had comments
> regarding the ice-option and ice-pacing attribute.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *mmusic <[email-masked]> on behalf of Roman Shpount <
> [email-masked]>
> *Date: *Wednesday, 24 July 2019 at 1.41
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Subject: *Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement
>
>
>
> list associated with the pair is set to Completed.. Once the state of

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Jul 2019 09:25:20 +0000

Hi,

Ok, I didn’t realize I was supposed to submit against the coriander file – instead I submitted against the -36 file. I can try to fix that, but I will have to do that a little later.

In any case, people can still the suggested changes in the pull requests.

Regards,

Christer

From: Suhas Nandakumar <[email-masked]>
Date: Thursday, 25 July 2019 at 21.15
To: Christer Holmberg <[email-masked]>
Cc: Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement

Hi Christer
   Roman has been submitting PRs here in the past. Please feel free to submit the PR and thanks for starting the discussion.

https://github.com/suhasHere/ice-sip-sdp/blob/master/ice_sip_sdp.coriander<https://protect2.fireeye.com/url?k=900b1413-cc8136fa-900b5488-0cc47ad93e2e-e643c905dbcf3110&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2Fice-sip-sdp%2Fblob%2Fmaster%2Fice_sip_sdp.coriander>

Cheers
Suhas

On Wed, Jul 24, 2019 at 2:33 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 24 July 2019 at 1.41
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] ICE-SIP-SDP: Concluding ICE statement

Best Regards,
_____________
Roman Shpount