Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments

[Paul Kyzivat <[e-mail]>]

Roman,

On 1/23/17 8:16 PM, Roman Shpount wrote:
>
> On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 21 Jan 2017, at 14:23, Christer Holmberg wrote:
>
>             -9.1, 2nd paragraph: Don't the lower layers need to be
>             established before the
>             upper layers? Won't removal of the TCP connection or DTLS
>             association break
>             an existing SCTP association?
>
>
>         Roman had lots of input on this, so I'll let him reply.
>
>
>     Okay
>
>
> Replacing of TCP connection or DTLS association does not break the SCTP
> association. SCTP is designed to run over unreliable transports, so
> short term loss of connectivity when one TCP connection or one DTLS
> association is being replaced by the other would be handled by the SCTP
> re-transmit timers. Also, when ICE is used, switching from one ICE
> candidate to another, including switching between two ICE tcp candidates
> or switching from udp to tcp candidate, does not affect existing SCTP
> association. Existing SCTP association continues to run despite the
> underlying candidate switch and as far as SCTP association is concerned
> it is running over the same unreliable transport. Finally, DTLS
> association can be re-established to force re-keying the long running
> connection. This can be done without affecting SCTP association running
> on top of these DTLS associations.
>
> This is why we are saying that the SCTP association, the DTLS
> association and the TCP connection are managed independently from each
> other.  Each can be established and  closed without impacting others.
> Each protocol uses its own means to detect connection closure, failure
> or timeout.

I can see that this can be a good thing when it is what you want/need.

OTOH, if one of the two parties involved changes, and there is no state 
sharing, you need to establish a new SCTP association. This may turn out 
to be the case even when the offerer doesn't know that the other party 
has changed.

So how are these two cases distinguished in the signaling? AFAICT the 
only thing available is sctp-port. If the offerer doesn't realize a 
change is coming, then it won't change its port. And in that case the 
answerer won't know what port its predecessor used, so it might choose 
the same value.

Of course, this is largely a 3pcc scenario, and if it is initiated in 
the middle then the middle can probably know to change the port somewhere.

But I'm not sure if that is the only case.

	Thanks,
	Paul