Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion

From: Randall Gellens <[email-masked]>
Date: Sun, 7 Jul 2013 15:40:38 -0700

At 4:50 PM +1100 3/25/13, Christian Groves wrote:

>  Hello,
>
>  One thing that doesn't seem to be noted is an overlap with the work 
> of the CLUE WG. There has been some discussion in the CLUE working 
> group about adding attributes to captures to describe the language, 
> whether sub-titles are used, whether a stream comes from an 
> interpreter, etc. Where multiple streams are used I would expect 
> any work in this area should be aligned.
>
>  Regards, Christian

Hi Christian,

Thanks for the info.  Would it make sense to talk about this in 
Berlin?  I agree that if there is overlap in the approaches we should 
align them.

Also, I have an updated draft that was just uploaded.  It is now 
named 'draft-gellens-mmusic-negotiating-human-language-00' (adding 
-mmusic and hence reverting back to -00).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you can't annoy somebody there's little point in writing --Kingsley Amis

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2013 17:13:23 +1000

Hello Randall,

I had a look at the draft with respect to CLUE. The main difference 
between the CLUE usage of language and what is being proposed is the 
ability for the sender to specify sending AND receiving preferences. The 
current CLUE model is that an each endpoint Advertises what it can do 
and then each consumer chooses from this list. This could still result 
in an asymmetric usage of language (just negotiated differently).

You may need to consider the case where there are multiple streams of 
the same media type with different languages. e.g. an audio conference 
where one stream is the main audio of the conference and there's a 
second stream with a translation/s. This is the type of thing CLUE is 
considering. I'm not sure how this fits in with your work?

Some other comments:

With regards to the SIP "hint" it wasn't clear to me how this matches 
the languages in "humintlang-send" and "humintlang-recv". Is it planned 
that both will be supported in the header?

The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller sets 
media and language) but in the final paragraph of the 7.3 it sounds like 
the "hint" is only for audio?

7.4 Silly states - How do the language sub-tags come into play here? For 
example: the endpoint might specify a language for an audio stream which 
may be valid. If the endpoint also specified a sub-tag with "script" I 
guess it makes it a silly state?

Regards, Christian

On 8/07/2013 8:40 AM, Randall Gellens wrote:
>> interpreter, etc. Where multiple streams are used I would expect any 
>> work in this area should be aligned.
>>
>>  Regards, Christian
>
> Hi Christian,
>
> Also, I have an updated draft that was just uploaded.  It is now named 
> 'draft-gellens-mmusic-negotiating-human-language-00' (adding -mmusic 
> and hence reverting back to -00).
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jul 2013 14:58:28 -0700

Hi Christian,

Thanks for the review and comments.

At 5:13 PM +1000 7/9/13, Christian Groves wrote:

> between the CLUE usage of language and what is being proposed is 
> the ability for the sender to specify sending AND receiving 
> preferences. The current CLUE model is that an each endpoint 
> Advertises what it can do and then each consumer chooses from this 
> list. This could still result in an asymmetric usage of language 
> (just negotiated differently).

The draft doesn't try to accommodate asymmetric usage, since that 
usually can just happen without detailed technical backing.  The 
"-send" and "-receive" attributes are there because Harald warned 
that we'd be violating SDP otherwise.

If CLUE can allow the caller to indicate in the offer language needs 
for each stream, this to be taken into accounting in policy bvased 
routing, and the callee to respond to the offer with a language in 
common, then perhaps we don't need this proposal at all and can just 
drop it in favor of CLUE.  I admit at this point I am ignorant of 
CLUE (yes, clueless about CLUE).

>  You may need to consider the case where there are multiple streams 
> of the same media type with different languages. e.g. an audio 
> conference where one stream is the main audio of the conference and 
> there's a second stream with a translation/s. This is the type of 
> thing CLUE is considering. I'm not sure how this fits in with your 
> work?

This is a different, and more complex, scenario than what this 
proposal is trying to solve.  This proposal is focused on simpler 
cases where someone places an emergency call or calls a corporate 
call center.  Possibly this can be just a simple case of the more 
complex cases?

>
>  Some other comments:
>
>  With regards to the SIP "hint" it wasn't clear to me how this 
> matches the languages in "humintlang-send" and "humintlang-recv". 
> Is it planned that both will be supported in the header?

I suppose this depends on if the "-send" and "-recv" are really 
needed, and if so if they should be the same.

>
>  The "TBD" paragraph in 7.3 SIP "hint" mentions (where the caller 
> sets media and language) but in the final paragraph of the 7.3 it 
> sounds like the "hint" is only for audio?

Good catch -- this will need to be sorted out.

>
>  7.4 Silly states - How do the language sub-tags come into play 
> here? For example: the endpoint might specify a language for an 
> audio stream which may be valid. If the endpoint also specified a 
> sub-tag with "script" I guess it makes it a silly state?
>
>  Regards, Christian
>
>>>   One thing that doesn't seem to be noted is an overlap with the 
>>> work of the CLUE WG. There has been some discussion in the CLUE 
>>> working group about adding attributes to captures to describe the 
>>> language, whether sub-titles are used, whether a stream comes 
>>> from an interpreter, etc. Where multiple streams are used I would 
>>> expect any work in this area should be aligned.
>>>
>>>   Regards, Christian
>>
>>  Hi Christian,
>>
>> Berlin?  I agree that if there is overlap in the approaches we 
>> should align them.
>>
>  _______________________________________________
>  mmusic mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/mmusic

-------------- Randomly selected tag: ---------------
Not a shred of evidence exists in favor of the idea that
life is serious.                          --Brendan Gill

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 10 Jul 2013 01:23:18 +0200

On 2013-07-09 23:58, Randall Gellens wrote:
> cases where someone places an emergency call or calls a corporate call 
> center.  Possibly this can be just a simple case of the more complex 
> cases? 
My view is that it is intended to also cover user-to-user cases, where 
preferences are compared and a relay service (or language interpreter) 
can be invoked to bridge language gaps.

Gunnar

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Jul 2013 14:45:18 +1000

Hello Randall,

Please see my response below.

Regards, Christian

On 10/07/2013 7:58 AM, Randall Gellens wrote:
>> ability for the sender to specify sending AND receiving preferences. 
>> The current CLUE model is that an each endpoint Advertises what it 
>> can do and then each consumer chooses from this list. This could 
>> still result in an asymmetric usage of language (just negotiated 
>> differently).
>
> "-send" and "-receive" attributes are there because Harald warned that 
> we'd be violating SDP otherwise.
[CNG] By asymmetric I mean that a different language could be used in 
the send and receive sections. Are you saying that the draft assumes the 
same language in the "-send" and "-receive" attributes?
> drop it in favor of CLUE.  I admit at this point I am ignorant of CLUE 
> (yes, clueless about CLUE).

[CNG] I think you still want your proposal. Endpoints shouldn't be 
compelled to use CLUE to indicate a language preference. The first CLUE 
advertisement will most likely come after the initial SIP SDP Offer so 
it would be difficult to route the call based on CLUE language information.
I'm still trying to understand what the relationship/mapping would be 
between the language specified as a SIP "hint", to the SDP "-send" and 
"-receive" attributes in an Initial SDP Offer to any subsequent CLUE 
signalling that includes a language tag.
For example: If an endpoint sends an initial SIP (with 'hint' with SDP 
Offer with a set of languages for a single media (and indicates CLUE 
support). Should the endpoint when sending a CLUE Advertisement only 
advertise captures that contain the negotiated languages? (Seeing "the 
hint" is at the call level) Or, should it treat any media described by 
CLUE as something completely new?

>> thing CLUE is considering. I'm not sure how this fits in with your work?
>

[CNG] I don't think this is a problem for the SDP attributes, I think 
the issue is more for the SIP "hint" if it is media type specific. For 
example if you set "LANG1" and "LANG2" against "audio" and you actually 
have two streams one of LANG1 and another of LANG2 and base your routing 
decision on this there is a chance that you route to an endpoint based 
on LANG2 but when the endpoint inspects the SDP it actually wants the 
LANG1 stream.

>> matches the languages in "humintlang-send" and "humintlang-recv". Is 
>> it planned that both will be supported in the header?
>

[CNG] OK I didn't understand that from the draft.

>>  7.4 Silly states - How do the language sub-tags come into play here? 
>> For example: the endpoint might specify a language for an audio 
>> stream which may be valid. If the endpoint also specified a sub-tag 
>> with "script" I guess it makes it a silly state?
>>
>>  Regards, Christian
>>
>>>> language, whether sub-titles are used, whether a stream comes from 
>>>> an interpreter, etc. Where multiple streams are used I would expect

---

From: Christian Groves <[email-masked]>
Date: Wed, 10 Jul 2013 14:49:15 +1000

I wouldn't have thought that it would be use case specific... i.e. i'd 
only include my language when I called an emergency service. I would 
think an endpoint would be configured with the information and then 
provide it whenever I made a call. Is that the intent?

Christian

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 11 Jul 2013 07:34:52 +0200

> provide it whenever I made a call. Is that the intent?
Yes, that is the intent.

And for both relay service invocation and any other assisting service 
invocation, it is best for the user to dial the destination, and get the 
assisting service invoked by an indication like this in the call, rather 
than being forced to first call an assisting service and with them 
discuss who is the final destination of the call.

The other party in the call may be another user, a call center, an 
emergency service or a conference bridge.

Gunnar

>> My view is that it is intended to also cover user-to-user cases, 
>> where preferences are compared and a relay service (or language 
>> interpreter) can be invoked to bridge language gaps.
>>
>> Gunnar
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2013 14:36:18 -0400

> discuss who is the final destination of the call.

Viewed this way, it is similar to recognizing the need for, and 
recruiting, a transcoder. (See RFCs 5369 & 5370.)

	Thanks,
	Paul

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 11 Jul 2013 21:27:53 +0200

> recruiting, a transcoder. (See RFCs 5369 & 5370.)
Yes, that is a useful model. Especially the bridge, because there you 
can let all three parties take part of common media when that makes sense.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Sat, 13 Jul 2013 01:07:40 -0700

At 2:49 PM +1000 7/10/13, Christian Groves wrote:

>  I wouldn't have thought that it would be use case specific... i.e. 
> i'd only include my language when I called an emergency service. I 
> would think an endpoint would be configured with the information 
> and then provide it whenever I made a call. Is that the intent?

I expect so, but then, I also didn't expect it to be used much in the 
person-to-person case since usually language is implied by context 
when calling an individual.  I expect it to be used when a person is 
calling an call center (corporate or emergency).  To put it another 
way, I expect a personal client to always set language on outbound 
calls, but in most cases to ignore it on inbound calls.  I'd expect a 
corporate call center, as well as emergency call handling facilities, 
to pay attention.  I should make this more clear in the draft.

-------------- Randomly selected tag: ---------------
The average man does not know what to do with his life, yet wants
another one which will last forever.             --Anatole France

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 13 Jul 2013 20:04:32 +0200

On 2013-07-13 10:07, Randall Gellens wrote:
>> would think an endpoint would be configured with the information and 
>> then provide it whenever I made a call. Is that the intent?
>
I expect the setting to be retrieved from a personal profile (likely but 
not necessarily stored in connection with other user information and 
account information) and used in every call.

/Gunnar

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2013 12:11:31 +1000

Hello Randall and Gunnar,

I think Randall's clarification would be good to have in the draft. I 
think that when a caller support the language it is sent for every call. 
Whether the language is used by a receiver depends on the receiver's 
local capability.

Regards, Christian

On 14/07/2013 4:04 AM, Gunnar Hellstrom wrote:
> I expect the setting to be retrieved from a personal profile (likely 
> but not necessarily stored in connection with other user information 
> and account information) and used in every call.
>
> /Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 15 Jul 2013 08:40:23 +0200

I suggest to add a couple of use cases.

4.x.  Deaf French sign language user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a call.
The call offers a video stream listing FSL in both directions with highest preference and also
real-time text stream on low preference level for French in both directions.
Audio is also included but without language indications.
The call destination turns out to be another user of FSL with the same media and language settings.
The called client can find that the language preferences match, so the same language indications are
sent in the SDP answer, and the call can be connected without connection of any relay service.
The users can sign directly with each other in the video streams, and occasionally use the real-time
text streams for data that need exact spelling or noted.

4.y.  Spoken Japanese user calling a Spanish speaking person.

Someone who speaks Japanese and is subscriber of an on-line interpreting service places a call.
The call offers audio streams using Japanese in both directions on high preference level, video
with spoken Japanese with no specific preference and both message-wise and real-time text in
Japanese in both directions.
This user is customer of an on-line interpreting service. The service adds its interpreting
language capabilities to the SDP on lower level than the originator, and conveys the call to the destination.
The destination is a Spanish speaking person. The called terminal detects that Spanish is among the possible
languages even if not highest preference, so that call is answered with indication of spoken Spanish at high
priority level and Spanish text messaging in both directions at low priority level.
The on-line interpreting service detects that their translation between Japanese and Spanish is needed to
make the call work, so they allocate an interpreter to the call, and answers the call with an indication
of Japanese towards the caller.
Information that the call will be soon supported by a Japanese/Spanish interpreter is provided in the
appropriate languages in the text message connections.
The users can communicate in their own languages supported by the interpreter.

-------------------------------
More might be needed to clarify some more of the endless possible variations and benefit.

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-07-15 04:11, Christian Groves wrote:
> think that when a caller support the language it is sent for every 
> call. Whether the language is used by a receiver depends on the 
> receiver's local capability.
>
>
> Regards, Christian
>
>
>>> I expect so, but then, I also didn't expect it to be used much in 
>>> the person-to-person case since usually language is implied by 
>>> context when calling an individual.  I expect it to be used when a 
>>> person is calling an call center (corporate or emergency).  To put 
>>> it another way, I expect a personal client to always set language on 
>>> outbound calls, but in most cases to ignore it on inbound calls.  
>>> I'd expect a corporate call center, as well as emergency call 
>>> handling facilities, to pay attention.  I should make this more 
>>> clear in the draft.
>>>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Jul 2013 09:14:28 -0700

Hi Christian,

How about this text:

    Clients acting on behalf of end users are expected to set one or both
    'humintlang-send' and 'humintlang-recv' attributes on each media
    stream primarily intended for human communication in an offer when
    placing an outgoing session, but either ignore or take into
    consideration the attributes when receiving incoming calls, based on
    local configuration and capabilities.  Systems acting on behalf of
    call centers and PSAPs are expected to take into account the values
    when processing inbound calls.

At 12:11 PM +1000 7/15/13, Christian Groves wrote:

>  I think Randall's clarification would be good to have in the draft. 
> I think that when a caller support the language it is sent for 
> every call. Whether the language is used by a receiver depends on 
> the receiver's local capability.
>
>
>  Regards, Christian
>
>
>>>>   I wouldn't have thought that it would be use case specific... 
>>>> i.e. i'd only include my language when I called an emergency 
>>>> service. I would think an endpoint would be configured with the 
>>>> information and then provide it whenever I made a call. Is that 
>>>> the intent?
>>>
>>> context when calling an individual.  I expect it to be used when 
>>> a person is calling an call center (corporate or emergency).  To 
>>> put it another way, I expect a personal client to always set 
>>> language on outbound calls, but in most cases to ignore it on 
>>> inbound calls.  I'd expect a corporate call center, as well as 
>>> emergency call handling facilities, to pay attention.  I should 
>>> make this more clear in the draft.
>>>
>>  I expect the setting to be retrieved from a personal profile 
>> (likely but not necessarily stored in connection with other user 
>> information and account information) and used in every call.
>>
>>  /Gunnar

-------------- Randomly selected tag: ---------------
                DETERIORATA

Go placidly amid the noise and waste,
And remember what comfort there may be in owning a piece thereof.
Avoid quiet and passive persons, unless you are in need of sleep.
Rotate your tires.
Speak glowingly of those greater than yourself,
And heed well their advice -- even though they be turkeys.
Know what to kiss -- and when.
Remember that two wrongs never make a right,
But that three do.
Wherever possible, put people on "HOLD".
Be comforted, that in the face of all aridity and disillusionment,
And despite the changing fortunes of time,
There is always a big future in computer maintenance.

        You are a fluke of the universe ...
        You have no right to be here.
        Whether you can hear it or not, the universe
        Is laughing behind your back.
                -- National Lampoon

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Jul 2013 09:21:33 -0700

Hi Gunnar,

I am concerned that getting into person-to-person usage will
overly complicate the draft with no real-world benefit, since
person-to-person communication has context and implied language/media,
as stated in the draft.  The draft is trying to solve a more
focused real-world problem where there is no context.

At 8:40 AM +0200 7/15/13, Gunnar Hellstrom wrote:

I suggest to add a couple of use
cases.

4.x.  Deaf French sign language
user calling another deaf French sign language user.

Someone who mainly uses French sign language (FSL) places a
call.

The call offers a video stream listing FSL in both directions with
highest preference and also

real-time text stream on low preference level for French in both
directions.

The call destination turns out to be another user of FSL with the same
media and language settings.

The called client can find that the language preferences match, so the
same language indications are

sent in the SDP answer, and the call can be connected without
connection of any relay service.

The users can sign directly with each other in the video streams, and
occasionally use the real-time

Someone who speaks Japanese and is subscriber of an on-line
interpreting service places a call.

The call offers audio streams using Japanese in both directions on
high preference level, video

with spoken Japanese with no specific preference and both message-wise
and real-time text in

This user is customer of an on-line interpreting service. The service
adds its interpreting

language capabilities to the SDP on lower level than the originator,
and conveys the call to the destination.

The destination is a Spanish speaking person. The called terminal
detects that Spanish is among the possible

languages even if not highest preference, so that call is answered
with indication of spoken Spanish at high

priority level and Spanish text messaging in both directions at low
priority level.

The on-line interpreting service detects that their translation
between Japanese and Spanish is needed to

make the call work, so they allocate an interpreter to the call, and
answers the call with an indication

Information that the call will be soon supported by a Japanese/Spanish
interpreter is provided in the

The users can communicate in their own languages supported by the
interpreter.

More might be needed to clarify some more of the endless possible
variations and benefit.

Gunnar Hellstršm

Omnitor

+46708204288

On 2013-07-15 04:11, Christian Groves
wrote:

Regards, Christian

On 2013-07-13 10:07, Randall Gellens
wrote:

At 2:49 PM +1000 7/10/13, Christian
Groves wrote:

I wouldn't have thought that it
would be use case specific... i.e. i'd only include my language when I
called an emergency service. I would think an endpoint would be
configured with the information and then provide it whenever I made a
call. Is that the intent?

I expect so, but then, I also didn't expect it to be used much in the
person-to-person case since usually language is implied by context
when calling an individual.  I expect it to be used when a person
is calling an call center (corporate or emergency).  To put it
another way, I expect a personal client to always set language on
outbound calls, but in most cases to ignore it on inbound calls.
I'd expect a corporate call center, as well as emergency call handling
facilities, to pay attention.  I should make this more clear in
the draft.

I expect the setting to be retrieved from
a personal profile (likely but not necessarily stored in connection
with other user information and account information) and used in every
call.

/Gunnar

mmusic mailing list

[email-masked]

mmusic mailing list

[email-masked]

mmusic mailing list

[email-masked]

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

If you make people think they're thinking, they'll love you; but if you

really make them think they'll hate you.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 18 Jul 2013 22:23:35 +0200

Randall,
In my view the draft aims at solving the difference between the 
user-to-user call with known similar context and the situation when the 
user-to-user call has dissimilar contexts and need support.

The call center gets invoked because of the difference between the users 
in order to fill the gap.

Of course there are other situations where it can be useful, but this is 
the main application that I see.

In USA, it is called to dial-around, when the users are connected 
without connection of an assisting service, and use of relay service 
when assistance is needed and invoked.
In Sweden we call the concept Call-direct.
The function is mentioned and demonstrated a number of times 
Internationally, and this is an opportunity to get proper standardized 
support for it.

Users interested in this service will have the language settings. It is 
very valid to do the comparison between the users and invoke services if 
needed.
For users who have not set the language indicators, there will need to 
be a place for assumptions in the evaluation logic.

And. Most important, I think we should follow Christian's advice to get 
a way to include language indications specified here, and the ways to 
use it specified in other specifications.

But in order to get the indications useful, we must settle some use 
cases. So there we have a risk of including assumptions of how the 
indications can be used.

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-07-18 18:21, Randall Gellens wrote:
> Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
> Hi Gunnar,
>
> I am concerned that getting into person-to-person usage will overly 
> complicate the draft with no real-world benefit, since 
> as stated in the draft.  The draft is trying to solve a more focused 
> real-world problem where there is no context.
>
>> Information that the call will be soon supported by a 
>> Japanese/Spanish interpreter is provided in the
>> Gunnar Hellstrs(m
>> [email-masked] <mailto:[email-masked]>
>> +46708204288
>>> I think that when a caller support the language it is sent for every 
>>>>> it another way, I expect a personal client to always set language 
>>>>> on outbound calls, but in most cases to ignore it on inbound 
>>>>> calls. I'd expect a corporate call center, as well as emergency 
>>>>> call handling facilities, to pay attention.  I should make this 
>>>>> more clear in the draft.
>>>>>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 18 Jul 2013 23:28:19 +0200

On 2013-07-18 18:21, Randall Gellens wrote:
> as stated in the draft.
This is not true anymore in the multimedia communication area. Video may 
be included in a call because the user just want to see the other call 
participant or it is included because the user urgently prefers to get a 
sign language commuication.

Two persons urgently wanting to use British Sign Language should have a 
chance to find that both support and prefer that, and they should 
connect without a relay service.
The evaluation can be made by the answering part, the calling part on 
the answer if the intication is prpoerly inserted, or by a service 
provider in betweeen the users.

But if the answering part ignores the indications, nothing is gained.

Gunnar

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jul 2013 11:08:28 +1000

Hello Randall,

I think you're mixing protocol functionality with application.

 From a protocol perspective I think that all you need to say is 
something like:

Clients that have a language preference related to a media stream/s 
shall set the 'humintlang-send' and/or 'humintlang-recv' attribute on 
the applicable media stream at session establishment. Receivers of the 
'humanintlang-*" attributes may then apply session handling based on the 
received language/s and according to local policy. For example: Call 
centers and PSAPs may route the session to an operator that is capable 
of communicating in the preferred language/s.

I think this describes the protocol behaviour without requiring 
behaviour depending on user type.

Regards, Christian

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 19 Jul 2013 06:45:34 +0200

On 2013-07-19 03:08, Christian Groves wrote:
> 'humanintlang-*" attributes may then apply session handling based on 
> the received language/s and according to local policy. For example: 
> Call centers and PSAPs may route the session to an operator that is 
> capable of communicating in the preferred language/s.
>
Yes, this looks better.
With this wording, I see a risk that the answering part does not realize 
that they shall also send the attributes. So, I suggest to add "both 
when offering and answering" in the first sentence.
With that, and a couple of other small changes, the paragraph could be:

"Clients that have a language preference related to media stream/s shall 
set the 'humintlang-send' and/or 'humintlang-recv' attribute on the 
applicable media stream/s at session establishment both when offering 
and answering. Receivers of the 'humanintlang-*" attributes may apply 
session handling based on the received language preferences and 
according to local policy. For example: Call centers and PSAPs may route 
the session to an operator that is capable of communicating in the 
preferred language/s ."

/Gunnar