Re: [MMUSIC] Comments on imageiddr

[Kyunghun Jung <kyunghun.jung at samsung.com>]

Title: Samsung Enterprise Portal mySingle

Dear Mr. Jonathan Lennox:

 

We would like to thank you for the comments.

This attribute was designed with mobile terminals in mind and reactions to unexpected events would depend on

the policy of operators. For example, in case of bit-rate,

 

(1) If session setup results in a bit-rate that cannot not provide any image size with the imageattr, the call would be blocked.

(2) if the bit-rate changes (decreases) during communication, either frame rate or quality, or both, would be reduced.

      If the situation continues, the call would be dropped.

 

With MCU, it will also depend on the capability and implementation of MCU. In some cases, imageattr can be simply ignored.

Or MCU can encode at the highest bit-rate/image size and subsample the stream to match the capability of handsets.

We witnessed some gateway products claiming such capabilities.

 

Thank you for the consideration and suggestions!

Sincerely yours,

Kyunghun Jung

Samsung Electronics Co., Ltd.

------- Original Message -------
Sender : Jonathan Lennox<jonathan at vidyo.com>
Date   : 2008-11-18 01:17 (GMT+09:00)
Title  : [MMUSIC] Comments on imageiddr

I was asked to repeat on the list my comments at the mic on the
imageaddr draft, so here we are.

First of all, the current draft does an offer/answer exchange whereby
the offerer lists a set of possibilities for send and receive image
attributes, and then the answerer responds with some subset of these.

My question was what each side should do if something changes (e.g.
available bandwidth) such that the requested image size isn't easily
achievable.  MUST (or SHOULD) there be a new offer/answer exchange, or
can one side just start sending something that doesn't conform to what
was negotiated?

It sounds like the consensus at the mic was that they could, since the
resolutions negotiated are advisory.


My second question was what you should do if you have several sources in
a session, e.g. coming from an MCU, which might have different preferred
natural resolutions or aspect ratios.

One suggestion would be to define the imageaddr attribute as a source
attribute as well as a session attribute.

There was some suggestion at the mic that this didn't really matter so
much, again since the resolutions are advisory.


-- 
Jonathan Lennox
Vidyo, Inc
jonathan at vidyo.com


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic