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

From: Belling Thomas <[email-masked]>
Date: Mon, 10 Jan 2005 19:15:11 +0100

Dear Jon,

comments below

BR, Thomas

> -----Original Message-----
> From: Jun KOSHIKO [mailto:[email-masked]] 
> Sent: Thursday, January 06, 2005 10:41 AM
> To: [email-masked]
> Cc: Belling Thomas
> Subject: Re: [MMUSIC] Video phone and offer/answer model
> 
> 
> 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 I stated, I see two options:

1. Having a general new semantics, e.g. "COMBINED-APPLICATION" to express that the answerer shall either accept or reject all grouped media streams together.

2. Having specific semantics for each combined application, e.g. VIDEO-PHONE as you propose. For each application, this may imply different additional things compared to 1, e.g. lipsynch.

> 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)|
>    |<--------------------------------------|

If you are only intrested in a combination of audio and video, LS might do, although it is not exactly what you had in mind. An answerer will probably accept or reject both media streams if lipsynch is required, because this implies the media streams are closely linked together. One the other hand, you might only want a combined acceptance or rejection of media streams without lipsynch, and then LS would not be appropriate - perhaps a bit theoretical for an audio and video combination.

> 
> > 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.

The drawback of this solution is that an answering host supporting a combined audio-video application, but not the new semantics, would reject the offer, although it might well behave in the desired way if no SIP require header is used. It is more graceful for the offerer to terminate the session only if such an answerer indeed did an undesirable selection. 

> 
> Best regards,
> Jun Koshiko
> 
> > 
> > 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
> 
> ---------------------------------------------------------
> 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
> ---------------------------------------------------------
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Jan 2005 15:36:53 -0500

I think this is bordering on silliness.

Read the thread.

You have the four cases of two variables:
1) The caller offers audio and video, the called answers with both
	This works with multiple sections, choices for each from the 
	offer, a single choice for each from the answer.
2) The caller offers audio and video, the called answers audio only
	99.99% of the time, the caller will accept the call audio only.
	This is the normal case of a video phone calling an audio phone.
	You almost always want to accept the call.  If you DON'T want to
	let the call complete, the caller can reject accept the answer.  
	Done.
3) The caller offers audio, the called would like video.  This is the
	audio phone calling the video phone.  99.99% of the time, the 
	right thing is to just make an audio choice and be happy.  
	If you want to reject the call, the called party can do that.
4) The caller offers audio, the called is audio only.  No problem, 
	right?

Where is the problem?

I say this as someone who has done this.  I'm happy to show you a SIP video
phone that places and receives calls from other video phones and audio
phones.  It works very nicely, as anyone who has seen it can attest.

Lip Sync is a completely separate issue from offer/answer.  The videophone
mentioned above has perfect lip sync with no problems without any
proprietary anything.   If you want to make lip sync better, the only
thing I think you would like is to understand the absolute time difference
between the audio clock and the video clock.  In every system I've seen,
if you maintain the sync implied by the first packets, you're fine.
It would be nice to not have to assume this.  Just for reference, the above
system maintains perfect sync on calls lasting 6-8 hours.  It probably works
for longer, but I haven't looked to see if it does.

If we don't absolutely need another mechanism, please, let's not make more
work.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Belling Thomas
> Sent: Monday, January 10, 2005 1:15 PM
> To: 'Jun KOSHIKO'; [email-masked]
> Cc: Belling Thomas
> Subject: RE: [MMUSIC] Video phone and offer/answer model
> 
> Dear Jon,
> 
> comments below
> 
> BR, Thomas
> 
> 1. Having a general new semantics, e.g. "COMBINED-APPLICATION" to express
> that the answerer shall either accept or reject all grouped media streams
> together.
> 
> 2. Having specific semantics for each combined application, e.g. VIDEO-
> PHONE as you propose. For each application, this may imply different
> additional things compared to 1, e.g. lipsynch.
> 
> If you are only intrested in a combination of audio and video, LS might
> do, although it is not exactly what you had in mind. An answerer will
> probably accept or reject both media streams if lipsynch is required,
> because this implies the media streams are closely linked together. One
> the other hand, you might only want a combined acceptance or rejection of
> media streams without lipsynch, and then LS would not be appropriate -
> perhaps a bit theoretical for an audio and video combination.
> 
> >
> The drawback of this solution is that an answering host supporting a
> combined audio-video application, but not the new semantics, would reject
> the offer, although it might well behave in the desired way if no SIP
> require header is used. It is more graceful for the offerer to terminate
> the session only if such an answerer indeed did an undesirable selection.
> 
> >
> > Best regards,
> > Jun Koshiko
> >
> > >
> > > Best regards,
> > >
> > > Th Belling
> > >
> > >

---

From: Jun KOSHIKO <[email-masked]>
Date: Thu, 13 Jan 2005 19:37:02 +0900

Thank you for your reply.

> 4) The caller offers audio, the called is audio only.  No problem, 

I can grasp the understanding for what you are saying. Now I would like
to consider about human interface. For example, in the following case,
if the caller reject the offer which includes audio and doesn't include
video, although the callee's phone ring and the it's hung up, the call
will be cancelled. This way seems unfriendly interface, I think.

If the caller can group m lines of video and audio and the callee
understand it, the callee can reject the offer to avoid such a situation.
Definitely, whether the situation can be avoided or not depends on the
implementation of the device of callee.  If the callee which doesn't
understand the grouping attribute of m lines will accept the offer, and
then the call will be cancelled after the callee's phone rang and the
user got the phone up, naturally.

   Caller                                  Callee
(Video phone)                          (Audio Phone)
      |                                      |
      | INVITE with SDP(video/audio)         |
      |------------------------------------->|
      | 180 Ringing without SDP              |
      |<-------------------------------------| Phone Ring!!
      | 200 OK with SDP(audio)               |
      |<-------------------------------------| Hung up!!
      | ACK                                  |
      |------------------------------------->|
      | BYE                                  |
      |------------------------------------->| Call cancelled!!
      | 200 OK                               |
      |<-------------------------------------|
      | ACK                                  |
      |------------------------------------->|
      |                                      |

Best Regards,
Jun Koshiko

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 13 Jan 2005 09:46:20 -0500

I think this is a poor system design.  This is scenario 2 where the caller
offers audio and video, but the called party only has audio, and you want
refuse the answer because the caller insists on video.  Your problem is that
the called party doesn't know it's going to be refused, so it begins
alerting.  The call is cancelled after the alerting begins, and you don't
like that.

I'd prefer your caller to accept the call audio only.  That's what all the
systems I've ever seen would do.  I've never seen a system refuse a call if
it didn't offer/answer video.  In the systems I'm most familiar with, this
scenario occurs even though the called party has video capability.  It
occurs when the called user disables the video, and it also occurs when the
local environment can't handle the bandwidth implied.  The caller should not
have an expectation that everyone he calls will accept video, even if he
knows they have the capability to.  

I think we have so much work to do, and this requirement is of so little
interest, that we should not spend any time on it.  If there are lots of
systems that need to be able to refuse a call if the caller can't handle
video, I'd like to hear about them.

Brian

> Sent: Thursday, January 13, 2005 5:37 AM
> To: [email-masked]
> Cc: 'Belling Thomas'; Brian Rosen