Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

[Paul Kyzivat <[e-mail]>]

On 6/8/13 12:11 AM, Cullen Jennings wrote:
>
> On Jun 7, 2013, at 11:39 PM, Paul Kyzivat <[e-mail]> wrote:
>
>> On 6/6/13 1:41 AM, Cullen Jennings wrote:
>>>
>>> On Jun 5, 2013, at 11:17 PM, Paul Kyzivat <[e-mail]> wrote:
>>>
>>>>>   And it is likely to receive RTP packets before it receives an answer in some important scenarios.
>>>>
>>>> You keep saying that. But is it really true when ICE is used?
>>>> Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable.
>>>
>>> I'm assuming that some applications will bring up a data channel (using ICE), as soon as the far end starts alerting the user so this will be done by the time the far end users agrees to send media. At that point it would be nice to start sending media with no clipping. That allows all the ICE setup time to disappear from the media clipping latency problem.
>>>
>>> I realize lots of applications will not work this way.
>>
>> We're mixing apples and oranges here I think.
>>
>> In a pure sip environment there probably won't be a data channel, except for CLUE. But perhaps CLUE is what we should be considering when we are talking about bundle in a pure sip environment.
>>
>> Even webrtc won't always be using a data channel.
>>
>> In cases where there is a data channel, I don't know how much data will be exchanged over it before the "alerting" is done and the connection acknowledged. I certainly want that to be very constrained. So I'm not sure what the relevance of the data channel is to this discussion.
>
> I don't think it is constrained. A JS app can bring up the data channel and never alert or get any consent from the end user if there is no camera or microphone involved. People are thinking of using this to do P2PLive  style video distribution among other things. If you go back to my high /  mid / low path slides from a way back, you can see I want to bring up a data channel than use that data channel to pass back and forth any updated offer / answers so that they are direct and don't add extra load to the web server. All of this could happen before any alerting even started.

I agree its not technically constrained.

But still I think the app needs to be circumspect in the sort of data it 
passes prior to getting some sort of confirmation from the user.

Stuff that is just used to finish setup of communication is probably 
innocuous. But even that ought to be subject to policy control.
I may wish to appear unavailable until I answer the alert.

	Thanks,
	Paul