Subject: Re: [MMUSIC] draft-ietf-mmusic-data-channel-sdpneg - proposed text enhancements

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 2 Mar 2015 13:20:43 +0100

Paul,

Thanks for further feedback.
What would you think of following modification of section 5.2.1's first paragraph?

Thanks,
Juergen

*Old text in draft-ietf-mmusic-data-channel-sdpneg-00:*

*5.2.1. Managing stream identifiers*
For the SDP-based external negotiation described in this document,
the initial offerer based "SCTP over DTLS" owns by convention the
even stream identifiers whereas the initial answerer owns the odd
stream identifiers.  This ownership is invariant for the whole
lifetime of the signaling session, e.g. it does not change if the
initial answerer sends a new offer to the initial offerer.

*New text proposed for draft-ietf-mmusic-data-channel-sdpneg-01:*

*5.2.1. Managing stream identifiers*
For the SDP-based external negotiation described in this document,
the offerer initially adding a DTLS/SCTP based "m" line to the
signaling session owns the even SCTP stream identifiers whereas
the corresponding answererowns the odd SCTP stream identifiers
as long as this "m" line is in use.If this "m" line is removed from
the signaling session (its port number set to zero),and if usage of
this or of a new DTLS/SCTP based "m" line is renegotiatedlater on,
then the even and odd SCTP stream identifier ownership is redetermined as well.
In this case that agent owns the even SCTP stream identifiers which
generates the newSDP offer with re-used or new DTLS/SCTP based "m" line.

On 27.02.2015 21:56, Paul Kyzivat wrote:
> On 2/27/15 2:52 PM, Juergen Stoetzer-Bradler wrote:
>> Paul,
>>
>> Thanks much for your feedback.
>> Please see my remarks below.
>>
>> Thanks,
>> Juergen
>>
>> On 27.02.2015 16:56, Paul Kyzivat wrote:
>>> Juergen,
>>>
>>> See a couple of comments inline...
>>>
>>> On 2/27/15 10:29 AM, Juergen Stoetzer-Bradler wrote:

[snip]

>>>
>>>>  9. In first paragraph of Section 5.2.1 replacement of first sentence
>>>>          "For the SDP-based external negotiation described in
>>>>     this document, the initial offerer based "SCTP over DTLS" owns
>>>>     by convention the even stream identifiers whereas the initial
>>>> answerer
>>>>     owns the odd stream identifiers."
>>>>     with
>>>>          "For the SDP-based external negotiation described in this
>>>>     document, the sender of the initial offer owns by convention the
>>>> even
>>>>     stream identifiers whereas the sender of the initial answer owns the
>>>>     odd stream identifiers."
>>>
>>> This is confusing. It isn't clear from the text whether the owner of
>>> even identifiers is determined by the sender of the first offer in the
>>> *signaling session* (e.g., sip dialog), or the sender of the first
>>> offer that includes the "m" line of this SCTP association.
>>>
>>> It wasn't entirely clear before, but it is less clear now. IIUC it
>>> should be the sender of the first offer of the "m" line. But thinking
>>> about it more as I type, I expect it is more complex than that. If the
>>> association is subsequently renegotiated then I suspect the owner of
>>> even IDs is also renegotiated. (This starts to overlap with the other
>>> discussion of negotiation.
>>
>> [Juergen] I see. Agree that the new sentence wasn't really clearer after
>> all.
>> We could reformulate this by saying that the offerer which adds the
>> DTLS/SCTP based "m" line to the signaling session for the first time
>> (could be in the initial SDP offer or in a subsequent SDP offer) owns
>> the even SCTP stream ids as long as this "m" line is in use. And if this
>> "m" line is removed (its <port> set to zero) and later on re-used again,
>> that then that agent owns the even SCTP stream ids which creates this
>> new SDP offer with this "m" line's <port> set again to a non-zero value
>> (as long as this "m" line is again in use).
>>
>> What do you think? What that make it clearer?
>
> ISTM that whenever the association is renegotiated, which of necessity means that there will be a 
> state change resulting in no channels regardless of how many had previously existed, then the 
> owners of the even and odd ends should also be redetermined.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Mar 2015 11:36:55 -0500

> What would you think of following modification of section 5.2.1's first

It is better, but it doesn't cover all the cases.
When an O/A is done with a=connection:new, then the DTLS is 
reestablished and the SCTP association is reestablished. So all of the 
SCTP streams that had been present will be gone.

IMO the owner of even/odd should be reestablished too at this time.

	Thanks,
	Paul

>> ISTM that whenever the association is renegotiated, which of necessity
>> means that there will be a state change resulting in no channels
>> regardless of how many had previously existed, then the owners of the
>> even and odd ends should also be redetermined.
>>
>>     Thanks,
>>     Paul
>>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Mar 2015 16:53:44 +0000

Hi,

I think I agree with Paul.

It would be good if odd/even could be bound to active/passive, but unfortunately the offerer does not know which role it will get when it sends the offer (in which it already needs to include the port numbers).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎03/‎03/‎2015 18:37
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-data-channel-sdpneg - proposed text enhancements

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Mar 2015 12:02:55 -0500

On 3/3/15 11:53 AM, Christer Holmberg wrote:
> It would be good if odd/even could be bound to active/passive, but
> unfortunately the offerer does not know which role it will get when it
> sends the offer (in which it already needs to include the port numbers).

IIUC the even/odd ownership only applies for channels assigned with 
DCEP. Those that are externally determined, including those negotiated 
with SDP, are independent of that.

But still the inability to know who will be active until after the O/A 
is complete breaks the assignment of channels by DCEP prior to 
completion of the O/A, so active/passive doesn't work for even/odd.

ISTM that the even owner can simply be tied to the side that offers 
'connection:new", whether that is with a new m-line or with an existing 
m-line.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Thu, 5 Mar 2015 15:42:19 +0100

Paul, Christer,

Agree that the previous text proposal didn't take into account cases where an existing
SCTP based media description is modified resulting in a re-establishment of the SCTP association.

Paul, if I understand RFC 4145' Section 5 correctly, then the answerer may add
"a=connection:new" to its answer even if the offer contained "a=connection:existing",
in which case the SDP offer/answer negotiation result of the connection attribute would
also be "new". Thus in such a case it would actually be the answerer which requests the
establishment of a new SCTP association.
With this in mind, we'd propose to reformulate the text as follows.
(Such that the even SCTP stream id ownership remains tied to the SDP offerer.)

Thanks again,
Juergen

*5.2.1. Managing stream identifiers*
If an SDP offer / answer exchange(could be the initial or a subsequent one)
results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media description being
accepted, and if this SDP offer / answer exchange results in the
establishment of a new SCTP association, then the SDP offerer owns the
even SCTP stream ids of this new SCTP association and the answerer owns
the odd SCTP stream identifiers.
If this "m" line is removed from the signaling session (its port number
set to zero), and if usage of this or of a new DTLS/SCTP based "m" line
is renegotiated later on, then the even and odd SCTP stream identifier
ownership is redetermined as well as described above.

On 03.03.2015 18:02, Paul Kyzivat wrote:
> IIUC the even/odd ownership only applies for channels assigned with DCEP. Those that are 
> externally determined, including those negotiated with SDP, are independent of that.
>
> But still the inability to know who will be active until after the O/A is complete breaks the 
> assignment of channels by DCEP prior to completion of the O/A, so active/passive doesn't work for 
> even/odd.
>
> ISTM that the even owner can simply be tied to the side that offers 'connection:new", whether that 
> is with a new m-line or with an existing m-line.
>
>     Thanks,
>     Paul
>
>> Regards,
>>
>> Christer
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Mar 2015 10:14:26 -0500

Juergen,

Yes, your proposed wording seems to do the job.

	Thanks,
	Paul

On 3/5/15 9:42 AM, Juergen Stoetzer-Bradler wrote:
>> 'connection:new", whether that is with a new m-line or with an
>> existing m-line.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards,
>>>
>>> Christer
>>>