Subject: RE: [MMUSIC] Video phone and offer/answer model

From: Belling Thomas <[email-masked]>
Date: Wed, 5 Jan 2005 15:52:17 +0100

Hi folks,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, January 05, 2005 3:14 PM
> To: Jun KOSHIKO
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Video phone and offer/answer model
> 

...

> 
> But I think your issue is that the *caller* doesn't want the call to 
> succeed unless there is both voice and video. I don't know of 
> any *good* 
> way to do this currently.
> 

A clean way to resolve that would probably bee a new type of grouping within the grouping framework. As a minimum, the grouping would express that all media for the grouped m-lines need to be established together, or none of them.
As the media belong together in the sense that they need to be handled by a combined application, the more far-reaching idea would be to indicate the application in the new grouping type. This obviously is more complicated, but also more powerful, and issues like how to define and/or register such applications come up.

I do not know if this is worth the effort, and there would certainly be a backward compatibilty issue with hosts not understnding the extension. For those kind of hosts as callee, the caller would still need to terminate the call if undesirable media combinations are selected.

Best regards,

Th Belling

----------------------------------
Dr. Thomas Belling
Siemens AG           
Sankt-Martin-Str. 76 
D-81541 München Germany
Com MN PG NT MN 1
MCH M 34 307
Tel     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   [email-masked]

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

---

From: Jun KOSHIKO <[email-masked]>
Date: Thu, 06 Jan 2005 18:40:30 +0900

Hello Folks;

Thank you for your replies.

> Belling Thomas wrote:
...

> A clean way to resolve that would probably bee a new type of grouping
> within the grouping framework. As a minimum, the grouping would express
> that all media for the grouped m-lines need to be established together,
> or none of them. As the media belong together in the sense that they
> need to be handled by a combined application, the more far-reaching
> idea would be to indicate the application in the new grouping type.
> This obviously is more complicated, but also more powerful, and issues
> like how to define and/or register such applications come up.

RFC3388, grouping framework of m line, seems like a good resolution for
the problem. Thanks for the information.

I imagine that your idea of indication of the application like the
following example. A new semantic like "VIDEO-PHONE" will be defined,
and lines of two m lines (audio/video) will be grouped. And some
attributes will be newly defined for video-phone specific use. 
Is my understanding true?

...
a=group:VIDEO-PHONE 1 2
m=audio 30000 RTP/AVP 0 4 18
a=mid:1
a=xxx:xxx  (<- newly defined attribute)
m=video 30002 RTP/AVP 31 34
a=mid:2
a=xxx:xxx  (<- newly defined attribute)

As a minimum, I guess LS(Lip Synchronization) semantic defined in
RFC3388 could be applicable without difining a new type of grouping.

I think that video and audio stream need to be synchronized for the
video phone service. And synchronization of video and audio implies the
existance of common codecs both of video and of audio. Considering the
following case, I guess that a callee usually rejects the offer if it
doesn't support either (0) of audio codec or (31) of video codec. 

I feel slightly uncomfortable about using LS semantic because the usage
of LS semantic seems like different from the problem.

 Caller                                 Callee
   |                                       |
   | (offer)                               |
   | a=group:LS 1 2                        |
   | m=audio 30000 RTP/AVP 0               |
   | .                                     |
   | .                                     |
   | a=mid:1                               |
   | m=video 30002 RTP/AVP 31              |
   | .                                     |
   | .                                     |
   | a=mid:2                               |
   |-------------------------------------->|
   |                                       |
   |                               (answer)|
   |<--------------------------------------|

> I do not know if this is worth the effort, and there would certainly be
> a backward compatibilty issue with hosts not understnding the extension.
> For those kind of hosts as callee, the caller would still need to
> terminate the call if undesirable media combinations are selected.

I think something like SIP require header may be needed to avoid
undesirable media combinations considering a backward compatibility.

Best regards,
Jun Koshiko

> D-81541 M|nchen Germany

---------------------------------------------------------
Jun KOSHIKO
Next Generation Strategy
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------