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

[Gunnar Hellstrom <[e-mail]>]

Randall and all,

Attached is a version of the draft on negotiating human language with a 
discussion added about use of Caller preferences/Callee capabilities or 
SDP, including a proposed coding based on RFC 3840/3841.

I am afraid that this is getting a bit complex, both the specification 
in SDP and the one in SIP, but I see this structure needed to express 
all kinds of user needs and relay service types.

I also realize that the declarations in sdp about media capabilities 
represent a good source of information that could be used for routing 
decisions, so a merge of the SDP and SIP based methods might be of 
interest.

I mean that it for example does not make sense to send a call with video 
to a callee that cannot handle video.

Sorry for not providing a nice formatted draft.
There are use cases added, and the sections on coding according to RFC 
3840 and 3841.

In RFC 3840 / 3841, there is a concept of implicit capabilities. If that 
could be extended to include contents of sdp, we could possibly combine 
the SIP and SDP based versions to something doable.

You have mentioned a couple of times that we could take a simple 
approach and not complicate it with asymmetric capabilities or 
preferences in different directions. I tend to agree that that must 
still be an option. A coarse selection of service could be done anyway. 
Selection of exact performance of a relay service including the 
asymmetric aspects would then need to be handled in some other way.

Regards
Gunnar
------------------------------------------------------------------------

On 2013-07-24 02:48, Gunnar Hellstrom wrote:
> On 2013-07-24 02:05, Paul Kyzivat wrote:
>> On 7/23/13 6:35 PM, Gunnar Hellstrom wrote:
>>>
>>> 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?
>>
>> That would work within a single medium.
>>
>> But I don't think we can use that mechanism to trade off between 
>> different media. For that I think some other, more complex, mechanism 
>> would be needed.
>>
>> Or else we would need a more complex definition of which things are 
>> being prioritized against one another in order to use the q-values.
> I proposed a simpler mechanism in a recent mail. It was to insert at 
> the end of the humintlang tag a character a "!" for highly preferred, 
> nothing for manageable and "#" for
> a non-preferred but possible fall-back language and modality.
>
> I think it will be very important for most users to have a chance to 
> indicate this three-level preference order between different media as 
> well as between different languages within one medium.
>
> I am hesitating a bit for the type of coding I proposed, and saw your 
> proposal of q-value as something cleaner. When coding, you could make 
> sure that the last resort medium gets q-values under 0.4, the strongly 
> preferred between 0.7 and 1 and the managed ones between 0.4 and 0.6.
>
> You can see the earlier motivation for the preference between 
> modalities in the archive at:
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11871.html
>
>
>>
>>>> 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.
>>
>> I notice Henning just asked about this today, in a different forum.
>>
>> Perhaps some things are better done at the sip level, and others at 
>> the SDP level.
>>
>> Its also possible that correlations between different media streams 
>> should be left to other mechanisms. E.g., CLUE could signal better 
>> correlations between audio and video.
> Yes, but here we have three media. video, audio and text. CLUE need to 
> take text on board.
>
> But you are right, if this mechanism is moved to SIP level, then we 
> get the complex task to point out to what m-lines with the same medium 
> do the humintlang-tags for that medium relate to. Simplifications need 
> to be taken, so that we do not end up in specifying another CLUE.
>
> I think that part of the background for this draft is that the 
> mechanism shall be usable in 3GPP Multimedia Telephony . That might be 
> a reason why it ended up specified in SDP.
>
> Gunnar
>>
>>     Thanks,
>>     Paul
>>
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>