Subject: [rtcweb] Codec control and SDP offer/answer frequency

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 22:47:01 +0200

Hi,

In Vancouver two proposals for codec were presented, one based on COP and one based on the SDP imageattr attribute. The result from the straw poll was that people preferred to move forward with the SDP based solution.

When Harald presented his poker game example, he mentioned that there could be changes with a few seconds interval.

For my clarification, does that mean that a UA would send SDP offer/answers every few second???

If so, I don't think that would create good results.

First, it would cause heavy load on every entity that has to parse the SDP, as they need to parse the whole message body, and then figure out what has changed.

Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the session, there is a high risk that SDP offers (not only those related to codec control) would be rejected. Offer/answer is a rather "heavy" mechanism, and I don't think it's intended to be used in the suggested way. Normally you would send one (or a few) offer/answer(s) during call establishment, and between zero and a few during the session.

Or, did I missunderstand something?

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Aug 2012 11:00:31 +0200

> If so, I don't think that would create good results.
I don't quite buy the analysis - details below.

The example given (the "poker game") would almost certainly be a very 
specialized application, with no requirements for interworking (you 
can't dial into a game from a videophone), and would most likely be 
implemented via a central server (if nothing else, to take care that 
nobody's cheating).

For this type of application, where the end systems are already doing 
data exchange that is not representable in SDP (the game itself), I 
think a sensible architecture would be to pass the SDP offer/answer over 
the data channel. This means that traffic latency for passing SDP is on 
the same order as for media.
> First, it would cause heavy load on every entity that has to parse the SDP, as they need to parse the whole message body, and then figure out what has changed.
Given that in such a specialized application, the only entity that has 
to parse SDP is the central node - how much CPU time do you think SDP 
parsing will take? (number of CPU-milliseconds?)
>
> Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the session, there is a high risk that SDP offers (not only those related to codec control) would be rejected.
Why, given that it's a point-to-point exchange? Admitted, glare will 
happen, and will have to be resolved in the usual ways (ROAP gave one 
mechanism that the game protocol can adopt).
> Offer/answer is a rather "heavy" mechanism, and I don't think it's intended to be used in the suggested way.
Well.. the Arpanet was originally intended for connecting teletypes to 
mainframes. It's proved to be useful in a few scenarios it was not 
originally created for.
> Normally you would send one (or a few) offer/answer(s) during call establishment, and between zero and a few during the session.
>
A specialized poker game is not intended to be interoperable with a 
videophone?
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2012 11:38:23 +0200

Hi Harald,

> the same order as for media.

Offer/answer over the data channel???

Slide 3 of your presentation talks about the signalling channel.

Now, if you want to define a datachannel protocol that uses SDP syntax, fine, but please don't call it offer/answer :)

Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane.

> parsing will take? (number of CPU-milliseconds?)

I don't have numbers, but I can tell you that it is a relatively heavy process. And, it's not only about the parsing, but also about the processing of the parsed result.

In addition, are you actually negotiating anything, or are you simply "indicating"?

> mechanism that the game protocol can adopt).

Sure, there are procedures how to handle it. My point is that it may cause bad user experience - espeically if more critical offers are rejected (e.g. offers where you are adding new streams, doing un-hold etc).

>mainframes. It's proved to be useful in a few scenarios it was not originally created for.

Let's not get stucked on the poker game use-case then.

In general, if we think there will be use-cases which would trigger frequent offer/answers, I think it's the wrong approach.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Aug 2012 12:40:37 +0200

> Also, you would need to describe how the data channel protocol relates to negotiating being done on the signalling plane.
The format of the signalling channel is defined to be outside the scope 
of the specification, so it's perfectly legitimate to use the data 
channel for that purpose - application decision!
> In addition, are you actually negotiating anything, or are you simply "indicating"?
See draft-lennox - there may be negotiation going on, if we change the 
boundaries.
I see the normal use of this feature to be a change in q values only.
> Sure, there are procedures how to handle it. My point is that it may cause bad user experience - espeically if more critical offers are rejected (e.g. offers where you are adding new streams, doing…
All state changes have to be negotiated in a way that makes sure they 
eventually resolve, no matter what they are. This is not a problem 
specific to resolution negotiation.
> In general, if we think there will be use-cases which would trigger frequent offer/answers, I think it's the wrong approach.
And I want to be a lot more specific before worrying.
In the interworking case, I see that there can be issues, because 
existing systems have existing procedures - so I accept the theory that 
every-few-seconds offer/answer is a problem there.

In the WebRTC application case, I want to see a specific problem before 
I start worrying.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2012 13:05:20 +0200

Hi, 

>>> think a sensible architecture would be to pass the SDP offer/answer 
>>> over the data channel. This means that traffic latency for passing 
>>> SDP is on the same order as for media.
>> Now, if you want to define a datachannel protocol that uses SDP 
>> syntax, fine, but please don't call it offer/answer :)
>>
> The format of the signalling channel is defined to be outside the scope of the specification, so it's perfectly legitimate to use the data channel for that purpose - application decision!

Sure, applications can do whatever they want.

But, I think it would be good to have a standardized mechanisms which works for any application. AFAIK, that was the whole purpose of the discussion in Vancouver.

>>> Given that in such a specialized application, the only entity that 
>>> has to parse SDP is the central node - how much CPU time do you think 
>>> SDP parsing will take? (number of CPU-milliseconds?)
> See draft-lennox - there may be negotiation going on, if we change the boundaries.

Sure - for which offer/answer IS a good mechanism, as I assume the boundaries won't change that often.

>>>> Second, due to race conditions rules, SIP transaction rules etc, and *other* usages of SDP offer/answer within the 
>>>> session, there is a high risk that SDP offers (not only those related to codec control) would be rejected.
>> Sure, there are procedures how to handle it. My point is that it may cause bad user experience - espeically if 
>> more critical offers are rejected (e.g. offers where you are adding new streams, doing un-hold etc).
> All state changes have to be negotiated in a way that makes sure they eventually resolve, no matter what 
> they are. This is not a problem specific to resolution negotiation.

Correct. But, if you can indicate resolution changes without affecting other procedures, that makes the system more flexible.

If you need to re-NEGOTIATE something, then I agree you very likely will need something like offer/answer.

And, if you are talking about a data channel protocol, my issues may not be valid. So, maybe I'm the only one who missunderstood your message in Vancouver, then :)

>>> Well.. the Arpanet was originally intended for connecting teletypes 
>>> to mainframes. It's proved to be useful in a few scenarios it was not originally created for.
> In the interworking case, I see that there can be issues, because existing systems have existing procedures - so I accept the theory that every-few-seconds offer/answer is a problem there.
>
> In the WebRTC application case, I want to see a specific problem before I start worrying.

I belive also CLUE may have usage for this mechanism, eventhough I don't think there is any such formal decission made.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Aug 2012 13:22:33 +0200

Clipping to a single issue....

> But, I think it would be good to have a standardized mechanisms which works for any application. AFAIK, that was the whole purpose of the discussion in Vancouver.
Since we've settled on using SDP at the UA/Application interface, 
representing the data in SDP is a valid way of describing that interface 
- thus indeed making it available for use by any application written to 
that interface.

The particular worry you raised was how fast applications can do 
offer/answers - which is dependent on how their signalling channel is 
implemented, and how many intermediate nodes have to process the data.

That's what I'm thinking will be different in the Pokerstars example 
than in a SIP-telephone-gateway example.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2012 17:11:21 +0200

Hi, 

> Since we've settled on using SDP at the UA/Application interface,

Correct (eventhough someone in Seattle may have a different opinion ;)

>- thus indeed making it available for use by any application written to that interface.

Correct.

> The particular worry you raised was how fast applications can do offer/answers - which is dependent on 
> how their signalling channel is implemented, and how many intermediate nodes have to process the data.

Correct.

> That's what I'm thinking will be different in the Pokerstars example than in a SIP-telephone-gateway example.

I agree that the impacts are different - but I'd like to have a solution that works in all cases.

So, if I understand you correctly: you suggest that the codec control information is transported using SDP/a=imageattr "internally" (between app and browser), but then people can send it over the wire however they want?

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Aug 2012 22:36:38 +0200

> So, if I understand you correctly: you suggest that the codec control information is transported using SDP/a=imageattr "internally" (between app and browser), but then people can send it over the w…
Yes. I believe that's the model we have agreed on.

---

From: <[email-masked]>
Date: Thu, 23 Aug 2012 20:59:57 +0000

Hi,

Harald Alvestrand wrote:
>> So, if I understand you correctly: you suggest that the codec control
>information is transported using SDP/a=imageattr "internally" (between app
>and browser), but then people can send it over the wire however they want?
>

I think that is fully in line with how SDP is treated in RTCWeb in general (at least so far), so there does not seem to be anything special about this case.

Markus

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2012 08:18:37 +0200

Hi,

> I think that is fully in line with how SDP is treated in RTCWeb in general (at least so far), so there does not seem to be anything special about this case.

Fair enough.

But, that means that IF we use SDP offer/answer on the wire, and that offer/answer is not appropriate for codec control, we need to define another mechanism.

(By "we" I don't necessarily mean the rtcweb wg, but the community in general)

Regards,

Christer