Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-01

[Gunnar Hellstrom <[e-mail]>]

On 2013-07-23 20:00, Paul Kyzivat wrote:
> I just reviewed this new version. I have a number of comments:
Good comments Paul,
>
> * Section 5:
>
> You don't go into the details of the O/A rules. But I infer you assume 
> that the answer will be a subset of the offer, with the priorities 
> possibly changed. This is a common strategy with SDP O/A, but it is 
> limiting because it doesn't allow the answerer to indicate 
> capabilities it has that weren't mentioned by the offerer. Knowing 
> that could be useful, especially if a mismatch is going to result in 
> recruiting a relay service.
>
> I suggest that answer allow the answerer to indicate all of its 
> capabilities and preferences, and at the same time indicate choices 
> made. (If a choice was made.)
<GH>Yes, very useful to indicate all.
>
> * Section 7.1:
>
> Instead of humanintlang-send and humanintlang-recv, how about just 
> giving the lang tag and a send/recv/sendrecv parameter with it? This 
> would be more concise when sendrecv can be used.
>
> Suggest using a parameter (q) to indicate relative preference for 
> languages, rather than ordering. This can show degree of preference, 
> and can show when multiple languages have the same preference.
>
<GH>Have you seen my request for an indication of level of preference 
between the different modalities? A possiblility to indicate for example 
that British Sign Language is highly preferred, but English text possible.
The q values could be used for coding of such relative level of 
preference even between modalities. a q=1 for BSL in video, and a q=0.1 
for English in text.   Right?
> Example:
>
> a=humanintlang:EN;sendrecv;q=1,ES;recv;q=.5
>
> To accommodate my comment about section 5, perhaps the answer can 
> "mark" the alternative(s) that have been chosen for use, if any. (I'm 
> not sure I like this, but for now, lets assume a "*" suffix on the 
> direction in the answer.) E.g., assuming the offer above, then an 
> answer like:
>
> a=humanintlang:EN;sendrecv*;q=1,FR:recv;q=.5
>
> Also in this section, the following:
>
>    Note that while signed language tags are used with a video stream to
>    indicate sign language, a spoken language tag for a video stream in
>    parallel with an audio stream with the same spoken language tag
>    indicates a request for a supplemental video stream to see the
>    speaker.
>
> might be ambiguous in the presence of many streams. It might be good 
> to define a grouping framework (RFC 5888) usage to group an audio 
> stream with a video stream that contains the speaker(s) of the audio.
<GH>This is both a threat and a solution. There are already other 
reasons to group media in SDP. We have a risk of ending up in a very 
complex coding in SDP to get this correctly specified in an environment 
where there are also other reasons to group m-lines. This is why I am 
still hesitating if the whole thing would not fit better as tags on the 
SIP level.
>
> Also in this section, the following:
>
>    Clients acting on behalf of end users are expected to set one or both
>    'humintlang-send' and 'humintlang-recv' attributes on each media
>    stream in an offer when placing an outgoing session but ignore the
>    attributes when receiving incoming calls.  Systems acting on behalf
>    of call centers and PSAPs are expected to take into account the
>    values when processing inbound calls.
>
> Are you intending to exclude clients taking a more active role? (E.g., 
> Isn't it possible that a client receiving an incoming call in a 
> language it doesn't support might bridge in a relay service?)
<GH>I have asked for deletion of this limiting paragraph.
>
> Should a client that can't do anything useful with the language info 
> still indicate its language preferences in the answer? I would think 
> this would still be helpful. It might allow the caller, or a 
> middlebox, to compensate in some way. What I suggest above allows that.
<GH>Yes, I prefer that view. The answering part shall answer if it can. 
middleboxes or the offering part may do the invocation of services to 
cover the gaps.
>
> * Section 7.2 (Advisory vs Required):
>
> Rather than "*" suffix, would be cleaner to have a separate indicator. 
> And it seems like this should not be on a particular language tag. If 
> you speak both Spanish and English, you may want the call to succeed 
> if the callee can do one or the other, and otherwise fail. A tag per 
> language doesn't do that.

<GH>Yes, tricky.  I am getting a feeling that we should start a draft 
describing usage in parallel to this one, so that use cases can be 
verified.

>
> Need more discussion for how to denote this.
>
>     Thanks,
>     Paul
>
Gunnar
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic