Subject: [clue] Question of deactivation scenario

From: Christian Groves <[email-masked]>
Date: Fri, 19 Sep 2014 14:02:01 +1000

I want to see if people have a common understanding of an re-ADV 
removing a media capture. Consider a scenario where an audio and two 
video captures have been Advertised, Configured and the SDP has been 
provided. Media is flowing.

The Media Provider for some reason decides that one of the video media 
captures is no longer available and sends an updated Advertisement 
removing the video capture.

Q1. Does the Media Consumer need to send an updated Configure message? I 
assume not as if the MP is not Advertising a media capture there's 
little else the MC can do but accept the removal.

Q2. I assume that it wouldn't matter at what stage the MP stops sending 
the media e.g. before the re-Advertisement, after the re-Advertisement 
or after the updated SIP-reinvite moving the media stream? Again there's 
little the MP could do to influence this.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Sep 2014 15:23:10 -0400

> little else the MC can do but accept the removal.

IMO the consumer SHOULD send a new Configure, even if it is unchanged.
But I don't think it MUST.

Until it does, I think the provider SHOULD consider to send whatever is 
is capable of among what was last configured.

OR, perhaps we should assume that the provider applies the last received 
Config to the new advertisement and sends what matches. (But in this 
case it must ignore things that don't match, whereas when it receives a 
new Config it will reject it if some things don't match.)

Note that the above alternatives are not equivalent. In principle the 
provider can assign new identifiers to everything in the new 
advertisement, for captures, scenes, etc., even when the substance of 
what is being advertised is not changed. (This might be silly, but there 
may be cases where it is what makes sense.)

> little the MP could do to influence this.

I think there is potentially a difference to error reporting.

If you stop receiving a capture-encoding and don't know why, it may make 
sense to display some sort of error message to the local administrator 
and/or users. If you are told it is going away first, then you can avoid 
that.

Much of this is an implementation issue. But without some guidelines, we 
might get poor interop experiences.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Sep 2014 10:37:23 +1000

Hello Paul,

Please see below.

Regards, Christian

> But I don't think it MUST.
[CNG] I wonder if this is really a should given that the message is 
basically a no-op. What does the configure do?

>
> Until it does, I think the provider SHOULD consider to send whatever 
> is is capable of among what was last configured.
[CNG] I think this is the issue. Sometimes there's a "graceful" 
situation where it is possible to send an Advertisement before stopping 
sending media, then there's a "non-graceful" (i.e. someone powers off a 
camera) where the media stops before the Advertisement.

>
> OR, perhaps we should assume that the provider applies the last 
> received Config to the new advertisement and sends what matches. (But 
> in this case it must ignore things that don't match, whereas when it 
> receives a new Config it will reject it if some things don't match.)
[CNG] A MC doesn't have to send a Config in response to an Advertisement 
so I think the MP has to do this as part of normal processing.

> what is being advertised is not changed. (This might be silly, but 
> there may be cases where it is what makes sense.)
[CNG] I theory yes. I think it would be good to document somewhere what 
the consequence of this is.

> If you stop receiving a capture-encoding and don't know why, it may 
> make sense to display some sort of error message to the local 
> administrator and/or users. If you are told it is going away first, 
> then you can avoid that.
>
> Much of this is an implementation issue. But without some guidelines, 
> we might get poor interop experiences.
[CNG] Yes

>
>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Sep 2014 10:29:38 -0400

Inline.

> basically a no-op. What does the configure do?

I'll comment on this below.

> so I think the MP has to do this as part of normal processing.

I listed two *alternatives* above. They are conceptually different, 
though in most common cases they will yield the same result. It is 

> the consequence of this is.

Exactly. This is why we need to be precise on what happens between the 
sending of the new advertisement and the receipt of a new Configure that 
references it. Restating my two alternatives:

1) the provider keeps sending as many of the previously configured 
capture encodings as it can, defined by the last received Configure and 
the advertisement that it referred to. In this alternative, this could 
potentially include captures that are no longer advertised. It would 
also cover the case where the new advertisement renamed things such that 
the old config wouldn't select anything in the new advertisement.

2) at the time the provider sends the new advertisement it also 
reinterprets the last received configure against the new adv, and sends 
only those things that are selected.

ISTM that (2) is very well defined and should provide consistent results 
across all implementations. OTOH, (1) when well implemented might 
provide a more "graceful" transition, but probably not as consistent.

Also factoring into this is the question of what to do between the time 
the advertisement is sent and the ACK received, and what to do if the 
advertisement receives a NAK.

>> we might get poor interop experiences.

So I think it would be good to provide some (non-normative) guidelines.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 24 Sep 2014 13:47:27 +1000

Hello Paul,

..snip..
> sending of the new advertisement and the receipt of a new Configure 
> that references it. Restating my two alternatives:
>
> capture encodings as it can, defined by the last received Configure 
> and the advertisement that it referred to. In this alternative, this 
> could potentially include captures that are no longer advertised. It 
> would also cover the case where the new advertisement renamed things 
> such that the old config wouldn't select anything in the new 
> advertisement.

> reinterprets the last received configure against the new adv, and 
> sends only those things that are selected.
>
> ISTM that (2) is very well defined and should provide consistent 
> results across all implementations. OTOH, (1) when well implemented 
> might provide a more "graceful" transition, but probably not as 
> consistent.

> Also factoring into this is the question of what to do between the 
> time the advertisement is sent and the ACK received, and what to do if 
> the advertisement receives a NAK.

[CNG] I think there's a modification of the behaviour of (1) that 
factors in the ACK.

(3) If possible, the provider keeps sending the previously configured 
capture encodings until it receives an ACK to the Advertisement at which 
point it applies the behaviour of (2). At least the MC knows that the 
capture encoding is being removed before the media packets stop in 
situations where the MP can give notice.
In the NACK case the MP should probably resend the Advertisement and 
hopefully receive an ACK but in reality if there's a syntax error 
causing a NACK its probably not going to be fixed by resending so the MP 
could just drop the media stream.