Subject: Re: [MMUSIC] Comments on imageiddr

From: Kyunghun Jung <[email-masked]>
Date: Tue, 18 Nov 2008 09:00:45 +0000 (GMT)

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<[email-masked]>
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

[email-masked]

_______________________________________________

mmusic mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic