Subject: [Slim] Comments on proposed SLIM charter

From: "Ben Campbell" <[email-masked]>
Date: Fri, 13 Mar 2015 15:30:44 -0500

Hi,

For the record, I support this work. But I have some concerns about the 
proposed charter at https://datatracker.ietf.org/doc/charter-ietf-slim . 
Apologies if this rehashes old discussions; I have only recently joined 
the mailing list (I did scan the archive, but likely missed things.)

I don't find the charter text motivating the linkage between the mail 
problem and the real-time problem very convincing. I'm not saying it's 
wrong; just that it hasn't convinced me.

The text suggests a single work group to reinforce commonality in the 
solutions. That seems backwards to me; I'd like to see more on why 
people think the problems benefit from a common solution. Do you think 
there will be mechanism in common, beyond the use of language tags? Do 
you see a common implementor community? A common protocol development 
community?

I'd like to see something about why people don't think the real-time 
problem is at least partially solved by RFCs 3840 and 3841. If that's a 
forgone conclusion, the charter needs to clearly motivate it. The draft 
is slightly more helpful here in mentioning that 3840/3841 were 
considered but discarded, but that's not obvious from the proposed 
charter text.

Part of this may be that I am not sure if this is looking at a 
call-routing problem (i.e. getting the call to an appropriate 
destination for a language) and/or a language negotiation problem (i.e. 
deciding what language you are going to use once the call is 
established. The first is mentioned, although the text about invoking 
translators, etc, might also imply the second. The charter should 
clearly describe the problem.

If the idea is to finish the existing drafts, the charter should say 
that. Even so,
the schedule seems optimistic, unless you expect those drafts to go to 
WGLC right after
the charter is approved.

I find paragraph 2 a bit hard to follow--it seems to be a single complex 
sentence.

Thanks!

Ben.

---

From: Henning G Schulzrinne <[email-masked]>
Date: Fri, 13 Mar 2015 16:57:28 -0400

And, for the record, I continue to disagree with the current choice of
discarding a 3840-like (not necessarily the protocol itself) approach. I
consider this a call routing problem which is not appropriate for an SDP
solution, just by standard SIP architectural layering.

Henning

On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <[email-masked]> wrote:

> Apologies if this rehashes old discussions; I have only recently joined the
> mailing list (I did scan the archive, but likely missed things.)
>
> solutions. That seems backwards to me; I'd like to see more on why people
> think the problems benefit from a common solution. Do you think there will
> be mechanism in common, beyond the use of language tags? Do you see a
> common implementor community? A common protocol development community?
>
> forgone conclusion, the charter needs to clearly motivate it. The draft is
> slightly more helpful here in mentioning that 3840/3841 were considered but
> discarded, but that's not obvious from the proposed charter text.
>
> call-routing problem (i.e. getting the call to an appropriate destination
> for a language) and/or a language negotiation problem (i.e. deciding what
> language you are going to use once the call is established. The first is
> mentioned, although the text about invoking translators, etc, might also
> imply the second. The charter should clearly describe the problem.
>
> If the idea is to finish the existing drafts, the charter should say that.
> Even so,
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 13 Mar 2015 22:25:15 +0100

Henning G Schulzrinne skrev den 2015-03-13 21:57:
> discarding a 3840-like (not necessarily the protocol itself) approach. 
> I consider this a call routing problem which is not appropriate for an 
> SDP solution, just by standard SIP architectural layering.
I agree.
When I made the user to user call use case, I tried to make it 
implementable with the language indications in SDP, but it really felt 
like an unreliable hack.
Either asking the called terminal to make the analysis and invoke any 
needed translation, or having an ACD to request OPTIONS to the 
destination and then peek into SDP to find out if translation is needed. 
No one of these solutions are pleasant.

The draft also talks about policy-based routing as a solution. The work 
with policy based routing has not progressed as hoped at least as far as 
I know. It seems to be defined only for checking if one destination is 
open and if not select a replacement. Not any kind of "ACD" based on 
media capabilities and similar factors.

One problem we had with a RFC 3840 /3841 based method was that we did 
not know any way to differentiate between written language and spoken 
language tags. But we have now learned that that should be doable ( 
still to be clearly specified )

Servers are already supporting storage and comparison and routing based 
on RFC 3840 /3841  so it is very tempting to use that mechanism or an 
extension of it.

Gunnar

>
> Henning
>
> On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     For the record, I support this work. But I have some concerns
>     about the proposed charter at
>     https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if
>     this rehashes old discussions; I have only recently joined the
>     I don't find the charter text motivating the linkage between the
>     mail problem and the real-time problem very convincing. I'm not
>     saying it's wrong; just that it hasn't convinced me.
>
>     The text suggests a single work group to reinforce commonality in
>     the solutions. That seems backwards to me; I'd like to see more on
>     why people think the problems benefit from a common solution. Do
>     you think there will be mechanism in common, beyond the use of
>     language tags? Do you see a common implementor community? A common
>     protocol development community?
>
>     I'd like to see something about why people don't think the
>     real-time problem is at least partially solved by RFCs 3840 and
>     3841. If that's a forgone conclusion, the charter needs to clearly
>     motivate it. The draft is slightly more helpful here in mentioning
>     that 3840/3841 were considered but discarded, but that's not
>     obvious from the proposed charter text.
>
>     destination for a language) and/or a language negotiation problem
>     (i.e. deciding what language you are going to use once the call is
>     established. The first is mentioned, although the text about
>     invoking translators, etc, might also imply the second. The
>     charter should clearly describe the problem.
>
>     If the idea is to finish the existing drafts, the charter should
>     say that. Even so,
>     the schedule seems optimistic, unless you expect those drafts to
>     go to WGLC right after
>     the charter is approved.
>
>     I find paragraph 2 a bit hard to follow--it seems to be a single
>     complex sentence.
>
>     Thanks!
>
>     Ben.
>
>     [email-masked] <mailto:[email-masked]>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Mar 2015 17:40:24 -0400

> solution, just by standard SIP architectural layering.

In principle I agree with you. But to make it solely into a call routing 
problem ignores the need to consider capabilities of both the caller and 
the callee, and then if they don't match, do some extra stuff to bring a 
"transcoder" into the session.

That *could* be viewed as a call routing problem if it is always a 
"receiver makes it right" solution. For that, an intermediary at the 
callee's end (the callee's home proxy) would need to know the 
capabilities of the callee and the callee's devices before routing to a 
callee device, and pull in a transcoder.

But practically speaking we can't always count on the callee to take 
responsibility for this. The caller, or an agent for the caller, can do 
it, but must know the capabilities of the callee before doing so. I 
guess the caller (or a B2BUA intermediary on behalf of the caller) can 
do it after the call is accepted, based callee caps in the callee's 
Contact header. But it isn't really quite a conventional call routing 
case then.

	Thanks,
	Paul

>     For the record, I support this work. But I have some concerns about
>     the proposed charter at
>     https://datatracker.ietf.org/__doc/charter-ietf-slim
>     <https://datatracker.ietf.org/doc/charter-ietf-slim> . Apologies if
>     why people think the problems benefit from a common solution. Do you
>     think there will be mechanism in common, beyond the use of language
>     tags? Do you see a common implementor community? A common protocol
>     development community?
>
>     problem is at least partially solved by RFCs 3840 and 3841. If
>     that's a forgone conclusion, the charter needs to clearly motivate
>     it. The draft is slightly more helpful here in mentioning that
>     3840/3841 were considered but discarded, but that's not obvious from
>     the proposed charter text.
>
>     invoking translators, etc, might also imply the second. The charter
>     should clearly describe the problem.
>
>     the schedule seems optimistic, unless you expect those drafts to go
>     to WGLC right after
>     the charter is approved.
>
>     _________________________________________________
>     SLIM mailing list
>     https://www.ietf.org/mailman/__listinfo/slim
>     <https://www.ietf.org/mailman/listinfo/slim>
>
>
>
>

---

From: Henning G Schulzrinne <[email-masked]>
Date: Fri, 13 Mar 2015 18:20:20 -0400

Good point. To reduce the complexity, this would seem to have three phases:

(1) Discovery - The caller tells the other side all it can do, with our
without intermediate "help" (human or machine). Probably an OPTIONS
request, but maybe something else.

(2) Response - The callee provides its possible options from that list,
maybe preference-ordered, or a "sorry, I cannot do this, Dave".

(3) Call - Assuming that there's a meeting of the minds, the caller tries
again, with its preferred approach.

In general, having something that doesn't require keeping state across
phases would seem most robust.

Henning

On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <[email-masked]> wrote:

> callee's end (the callee's home proxy) would need to know the capabilities
> of the callee and the callee's devices before routing to a callee device,
> and pull in a transcoder.
>
> responsibility for this. The caller, or an agent for the caller, can do it,
> but must know the capabilities of the callee before doing so. I guess the
> caller (or a B2BUA intermediary on behalf of the caller) can do it after
> the call is accepted, based callee caps in the callee's Contact header. But
> it isn't really quite a conventional call routing case then.
>
>         Thanks,
>         Paul
>
>  Henning
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 14 Mar 2015 08:16:53 +0100

Yes, it is good to have a view of how a possible routing and adding of 
extra resources can be made.

We have two goals.
1. Decide which of a number of available callees we route the call to 
that gives the best match.

2. Decide if additional resources are needed in the call to interpret 
between the endpoints.

A mechanism for pulling in extra resources for interpretation when 
needed can be located at the caller end, in the middle or at the called 
end.

In a call-center type application, it is possible that the SLIM 
mechanism for conveying information about language and modality 
capabilities and preferences is used just from the caller to the ACD. 
The custom ACD then looks with other than SIP/SDP mechanisms at 
available call-taker profiles and selects the best match for whom to 
send the call to. That type of routing can be based on information in 
any part of the INVITE.

It is when we want to do more automatic selection and routing with SIP 
based mechanisms that we see that we need to either store the capability 
information from registration or fetch it before the decision is made.

RFC 3840/3841 information is already stored in the sip server from 
registration time and there is a selection and routing mechanism specified.
For an SDP based mechanism, I can imagine using OPTIONS to all possible 
callees at call time and comparing the results using a new specified 
mechanism or being left for the implementor. The policy-based routing 
that is sometimes talked about in relation to emergency calling could 
include such mechanisms and be used also outside the emergency service 
scope.

Having a box in the middle to take decision on including a third party 
in a call for translation can be made by having the translation services 
being included among the range of possible callees with a URI-list 
including the translation service and the original destination callee. 
The result when the best match is found to be a translation service is 
then that a multi-party call is set up.

This works if it is the callees who has the agreement with the 
translation service to invoke them when needed. But how can it be 
handled if it is the caller who has the agreement?

A couple of comments below:
Henning G Schulzrinne skrev den 2015-03-13 23:20:
> (1) Discovery - The caller tells the other side all it can do, with 
> our without intermediate "help" (human or machine). Probably an 
> OPTIONS request, but maybe something else.
Right, but what is the response on an OPTIONS request to a call center?
>
> (2) Response - The callee provides its possible options from that 
> list, maybe preference-ordered, or a "sorry, I cannot do this, Dave".
>
> (3) Call - Assuming that there's a meeting of the minds, the caller 
> tries again, with its preferred approach.
>
Yes, but cause a lot of traffic for interrogation of capabilities in the 
call center case(?)
>
> Henning
>
> On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     In principle I agree with you. But to make it solely into a call
>     routing problem ignores the need to consider capabilities of both
>     the caller and the callee, and then if they don't match, do some
>     extra stuff to bring a "transcoder" into the session.
>
>     "receiver makes it right" solution. For that, an intermediary at
>     the callee's end (the callee's home proxy) would need to know the
>     capabilities of the callee and the callee's devices before routing
>     to a callee device, and pull in a transcoder.
>
And that is what is done at registration time with RFC 3841.
>
>
>     But practically speaking we can't always count on the callee to
>     take responsibility for this. The caller, or an agent for the
>     caller, can do it, but must know the capabilities of the callee
>     before doing so. I guess the caller (or a B2BUA intermediary on
>     behalf of the caller) can do it after the call is accepted, based
>     callee caps in the callee's Contact header. But it isn't really
>     quite a conventional call routing case then.
>
>             Thanks,
>             Paul
>
>         Henning
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             Hi,
>
>         real-time
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Henning G Schulzrinne <[email-masked]>
Date: Sat, 14 Mar 2015 18:18:25 -0400

First, I'm not particularly worried about call signaling overhead. This is
likely to be trivial compared to all the other SIP signaling, let alone
media. I'm having a hard time picturing an ACD that would care about call
signaling volume.

The registration piece is separable - that was meant for relatively simple
situations where an end system indicated its capabilities. For the call
center, a program is likely to generate the current set of capabilities,
e.g., based on time of day ("Chinese-speaking CSRs are only available
during 9-5 business hours since they don't get enough calls at night.") and
other policies ("Platinum status customers get a real-time translation
service if needed, so all languages are supported.")

Something like (with completely bogus pseudo syntax):

OPTIONS
Preferred-Languages: ase; en (text); de (audio spoken, text)

which would indicate something like "can do ASL (video, naturally), English
(text only), German (speak, but not listen or text), in that order of
preference."

The call center would reply with some permutation of that, as in:

200
Preferred-Languages: ase; en (text)

Alternatively, the ACD could just respond to the OPTIONS request with all
of its capabilities, without the caller sending its preferences. Easier to
implement, but the list is likely longer.

In case the ACD can't do the requested media directly, it could redirect
the request using the standard SIP mechanism, e.g., to a VRS provider.

I'm trying to avoid fancy "q" parameters since I have never seen them used
in any real way, except as ordering indicator.

Based on the 3840/41 experience, as well as other attempts to do fancy
things in SIP, my guess is that all but trivially-easy negotiation won't be
implemented at all or will not interoperate. Thus, my bias is towards
solving 80% of the problem if the remaining 20% increase the complexity.

Henning

On Sat, Mar 14, 2015 at 3:16 AM, Gunnar Hellström <
[email-masked]> wrote:

> 1. Decide which of a number of available callees we route the call to that
> gives the best match.
>
> A mechanism for pulling in extra resources for interpretation when needed
> can be located at the caller end, in the middle or at the called end.
>
> In a call-center type application, it is possible that the SLIM mechanism
> for conveying information about language and modality capabilities and
> preferences is used just from the caller to the ACD. The custom ACD then
> looks with other than SIP/SDP mechanisms at available call-taker profiles
> and selects the best match for whom to send the call to. That type of
> routing can be based on information in any part of the INVITE.
>
> mechanism or being left for the implementor. The policy-based routing that
> is sometimes talked about in relation to emergency calling could include
> such mechanisms and be used also outside the emergency service scope.
>
> Having a box in the middle to take decision on including a third party in
> a call for translation can be made by having the translation services being
> included among the range of possible callees with a URI-list including the
> translation service and the original destination callee. The result when
> the best match is found to be a translation service is then that a
> multi-party call is set up.
>
> This works if it is the callees who has the agreement with the translation
> service to invoke them when needed. But how can it be handled if it is the
> caller who has the agreement?
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 15 Mar 2015 23:43:40 +0100

Henning G Schulzrinne skrev den 2015-03-14 23:18:
> First, I'm not particularly worried about call signaling overhead. 
> This is likely to be trivial compared to all the other SIP signaling, 
> let alone media. I'm having a hard time picturing an ACD that would 
> care about call signaling volume.
>
> The registration piece is separable - that was meant for relatively 
> simple situations where an end system indicated its capabilities. For 
> the call center, a program is likely to generate the current set of 
> capabilities, e.g., based on time of day ("Chinese-speaking CSRs are 
> only available during 9-5 business hours since they don't get enough 
> calls at night.") and other policies ("Platinum status customers get a 
> real-time translation service if needed, so all languages are supported.")
>
> which would indicate something like "can do ASL (video, naturally), 
> English (text only), German (speak, but not listen or text), in that 
> order of preference."
>
> Alternatively, the ACD could just respond to the OPTIONS request with 
> all of its capabilities, without the caller sending its preferences. 
> Easier to implement, but the list is likely longer.
>
> In case the ACD can't do the requested media directly, it could 
> redirect the request using the standard SIP mechanism, e.g., to a VRS 
> provider.
>
> I'm trying to avoid fancy "q" parameters since I have never seen them 
> used in any real way, except as ordering indicator.
>
> things in SIP, my guess is that all but trivially-easy negotiation 
> won't be implemented at all or will not interoperate. Thus, my bias is 
> towards solving 80% of the problem if the remaining 20% increase the 
> complexity.
So you suggest that we just extend the language and media feature tags, 
so that we can differentiate written from spoken language and so that we 
can code what is decided to be included from the directionality and the 
relative or absolute priority within a medium and between media.

We then gain that it is much easier to insert and extract the 
information from the SIP message rather than the SDP, while we instead 
might get problems to indicate which media stream we intend with each 
language and modality indication if the device has multiple media 
streams of the same kind.

For that situation, we might look at defining some interaction with the 
media-content RFC 4796.

And we do not specify any negotiation mechanism.

/Gunnar

>
> Henning
>
> On Sat, Mar 14, 2015 at 3:16 AM, Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Yes, it is good to have a view of how a possible routing and
>     adding of extra resources can be made.
>
>     We have two goals.
>     1. Decide which of a number of available callees we route the call
>     to that gives the best match.
>
>     2. Decide if additional resources are needed in the call to
>     interpret between the endpoints.
>
>     needed can be located at the caller end, in the middle or at the
>     called end.
>
>     capabilities and preferences is used just from the caller to the
>     ACD. The custom ACD then looks with other than SIP/SDP mechanisms
>     at available call-taker profiles and selects the best match for
>     whom to send the call to. That type of routing can be based on
>     information in any part of the INVITE.
>
>     It is when we want to do more automatic selection and routing with
>     SIP based mechanisms that we see that we need to either store the
>     capability information from registration or fetch it before the
>     decision is made.
>
>     For an SDP based mechanism, I can imagine using OPTIONS to all
>     possible callees at call time and comparing the results using a
>     new specified mechanism or being left for the implementor. The
>     policy-based routing that is sometimes talked about in relation to
>     emergency calling could include such mechanisms and be used also
>     outside the emergency service scope.
>
>     Having a box in the middle to take decision on including a third
>     party in a call for translation can be made by having the
>     translation services being included among the range of possible
>     callees with a URI-list including the translation service and the
>     original destination callee. The result when the best match is
>     found to be a translation service is then that a multi-party call
>     is set up.
>
>>     (1) Discovery - The caller tells the other side all it can do,
>>     with our without intermediate "help" (human or machine). Probably
>>     an OPTIONS request, but maybe something else.
>>     (3) Call - Assuming that there's a meeting of the minds, the
>>     caller tries again, with its preferred approach.
>>
>>     In general, having something that doesn't require keeping state
>>     across phases would seem most robust.
>     Yes, but cause a lot of traffic for interrogation of capabilities
>     in the call center case(?)
>>
>>     Henning
>>
>>     On Fri, Mar 13, 2015 at 5:40 PM, Paul Kyzivat
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         In principle I agree with you. But to make it solely into a
>>         call routing problem ignores the need to consider
>>         capabilities of both the caller and the callee, and then if
>>         they don't match, do some extra stuff to bring a "transcoder"
>>         into the session.
>>
>>         That *could* be viewed as a call routing problem if it is
>>         always a "receiver makes it right" solution. For that, an
>>         intermediary at the callee's end (the callee's home proxy)
>>         would need to know the capabilities of the callee and the
>>         callee's devices before routing to a callee device, and pull
>>         in a transcoder.
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Mar 2015 20:20:25 -0400

On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellström <
[email-masked]> wrote:

So you suggest that we just extend the language and media feature tags, so
> that we can differentiate written from spoken language and so that we can
> code what is decided to be included from the directionality and the

Indeed - whatever the minimum necessary to route the call and determine
what assistance is needed.

>
> We then gain that it is much easier to insert and extract the information
> from the SIP message rather than the SDP, while we instead might get
> problems to indicate which media stream we intend with each language and
> modality indication if the device has multiple media streams of the same
> kind.
>
>
That may well be a separable problem, and may be easier to solve with a
limited scope.

> For that situation, we might look at defining some interaction with the

Indeed; as long as we only need to indicate, rather than negotiate, a
straightforward extension of that model with something like

a:language:ase

would seem to be useful. In that case, each media entry would (typically?)
only have one language, although one can probably come up with scenarios
where multiple languages make sense (for example, I think there are MPEG
transport streams with multiple languages).

> And we do not specify any negotiation mechanism.

I'm inclined to leave that to implementations, as long as everybody knows
what the header fields mean, but the "how did we get those" can be magic in
a black box. Obviously, you can get non-sensical responses (Caller: I speak
only English; Callee: Great, let's converse in Swedish), but I doubt that
spelling this out in detail will help avoid these. I think a reasonable
goal is to make sure that end points can deal with the common scenarios and
know what to do. I've yet to see a UA that offers a higher-level
programming abstraction (such as CPL), so this is likely to be hard-coded
into the UA anyway, with limited configurability.

Henning

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 16 Mar 2015 08:19:35 +0100

Henning Schulzrinne skrev den 2015-03-16 01:20:
>
>
> On Sun, Mar 15, 2015 at 6:43 PM, Gunnar Hellström 
>     So you suggest that we just extend the language and media feature
>     tags, so that we can differentiate written from spoken language
>     and so that we can code what is decided to be included from the
>     directionality and the relative or absolute priority within a
>     medium and between media.
>
>
> Indeed - whatever the minimum necessary to route the call and 
> determine what assistance is needed.
>
>
>     information from the SIP message rather than the SDP, while we
>     instead might get problems to indicate which media stream we
>     intend with each language and modality indication if the device
>     has multiple media streams of the same kind.
>
>
> That may well be a separable problem, and may be easier to solve with 
> a limited scope.
>
>     For that situation, we might look at defining some interaction
>     with the media-content RFC 4796.
>
>
> would seem to be useful. In that case, each media entry would 
> (typically?) only have one language, although one can probably come up 
> with scenarios where multiple languages make sense (for example, I 
> think there are MPEG transport streams with multiple languages).
I meant this scenario:
If we in SIP headers declare  humintlang-audio: de, fr
And in SDP, there is
m=audio 7000 AVP/RTP 0
m=audio 8000 AVP/RTP 0

Then there is no indication for which audio stream we indicate language.

This starts to get into CLUE domains, so we should be careful not to go 
too far into such complications.

We can have a default assignment between the language declarations and 
the RFC 4796 Content attribute saying that the language declaration is 
for the stream marked with the "main" attribute if more than one stream 
of the same media type is started.
m=audio 7000 AVP/RTP 0

a=content:main

m=audio 8000 AVP/RTP 0

But the added complexity by this maybe already outweighs what we gain by 
having the language declaration in SIP headers rather than SDP.

> I'm inclined to leave that to implementations, as long as everybody 
> knows what the header fields mean, but the "how did we get those" can 
> be magic in a black box. Obviously, you can get non-sensical responses 
> (Caller: I speak only English; Callee: Great, let's converse in 
> Swedish), but I doubt that spelling this out in detail will help avoid 
> these. I think a reasonable goal is to make sure that end points can 
> deal with the common scenarios and know what to do. I've yet to see a 
> UA that offers a higher-level programming abstraction (such as CPL), 
> so this is likely to be hard-coded into the UA anyway, with limited 
> configurability.
>
>
>     /Gunnar
>
>
> Henning
>
/Gunnar

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Mar 2015 08:46:03 -0400

I suspect we're talking past each other. My suggestion, following your
comments, is to do two orthogonal things:

(1) A high-level declaration of media capabilities sufficient for call
routing, found in the SIP header. It does not rely on SDP and simply
provides (language, media direction, media type) tuples.

(2) A per-media description of the language used by a media stream, in SDP.
No preferences, just declaration, similar to the RFC 4796 model. This is
useful also for multi-stream sessions, e.g., where one audio stream is in
the original language, another is the simultaneous translation.

The SDP one seems trivial to describe as long as there's no notion of
negotiation or matching at the protocol-spec level. (Obviously, SDP end
points can do whatever they like, including dropping media streams they
have no use for.)

Does that make sense?

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Mar 2015 12:47:06 -0400

I have stated the reason multiple times - it is fundamentally the wrong
architectural level. It's like asking why we should put email addresses in
IP headers and route packets based on that - yes, it can work technically,
but it's still a bad idea.

In any event, we seem to be having a productive discussion among some of
the SLIM participants about a rough solution outline that avoids some of
these architectural issues, so the debate may be somewhat overtaken by
events.

Henning

On Mon, Mar 16, 2015 at 12:40 PM, Randall Gellens <[email-masked]>
wrote:

> At 4:57 PM -0400 3/13/15, Henning G Schulzrinne wrote:
>
> There has been significant work over the years on trying to resolve the
> SDP vs SIP issue.  First as a small and very informal group prior to and
> following the Orlando IETF.  The conclusion there was that SDP made more
> sense for the emergency calling case, so the work progressed along that
> route.  Then, in Berlin, Henning made his case that SDP was the wrong
> choice, and Gunner volunteered to see if the SIP-only approach could work.
> We went through email discussions (before there was a list, but Henning and
> the other SIP-only proponents were in the distribution list but did not
> actively participate) and worked through the cases.  I published revisions
> of the draft showing both as candidate solutions.  Finally, as the draft
> tries to make clear, we eventually reached the conclusion that neither
> approach is ideal, both have benefits and problems, but either could be
> made to work.  There are reasons why the SDP approach makes more sense,
> especially for the emergency services case, and the SIP case has a few more
> problems, but fundamentally, this more a stylistic/preference/religion
> debate than just technical aspects. We've spent much time and effort trying
> to make the best technical evaluation, and I believe we are moving forward
> on that basis.  I therefore don't have much patience for reopening the
> debate a third time, especially when it comes down to personal preference
> and not technical problems.  If we are going to ever get anything completed
> that can be implemented and deployed, we need to move forward.
>
> Therefore, I suggest that unless anyone can point to reasons why the SDP
> approach will not work, we should accept the conclusion and move forward.
>
>
>   On Fri, Mar 13, 2015 at 4:30 PM, Ben Campbell <<mailto:[email-masked]>
>> [email-masked]> wrote:
>>
>>  Hi,
>>
>> proposed charter at <https://datatracker.ietf.org/doc/charter-ietf-slim>
>> https://datatracker.ietf.org/doc/charter-ietf-slim . Apologies if this
>> rehashes old discussions; I have only recently joined the mailing list (I
>> did scan the archive, but likely missed things.)
>>
>>  <mailto:[email-masked]>[email-masked]
>>
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.
>> ietf.org/mailman/listinfo/slim
>>
>>
>>
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Did you know...
> That no one ever reads these things?
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 16 Mar 2015 14:33:55 -0500

> you see a common implementor community? A common protocol development 

Hi SLIM list participants:

I see that one of my comments has generated some discussion (namely the 
SIP vs SDP discussion.) Does anyone have thoughts on my other comment 
(quoted above)?

Thanks!

Ben.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Mar 2015 15:47:51 -0400

So far, at least, I'm not seeing much in common. Among other differences,
the one-way (largely) nature of email seems rather different from the
OPTIONS-style model in SIP, and the media division doesn't seem to apply as
naturally. Also, many of the typical email attachments may already have
language attributes, e.g., via the lang HTML tag, format-specific
attributes embedded in Word and PDF files, or the RFC 3282 Content-Language
header.

Henning

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 16 Mar 2015 23:21:20 +0100

Henning Schulzrinne skrev den 2015-03-16 13:46:
> (2) A per-media description of the language used by a media stream, in 
> SDP. No preferences, just declaration, similar to the RFC 4796 model. 
> This is useful also for multi-stream sessions, e.g., where one audio 
> stream is in the original language, another is the simultaneous 
> translation.
Ah, yes, I saw it as a limited functionality duplication of the SIP 
information. But, yes, it makes sense.
> negotiation or matching at the protocol-spec level. (Obviously, SDP 
> end points can do whatever they like, including dropping media streams 
> they have no use for.)
>
> Does that make sense?
Yes.
Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Mar 2015 10:32:12 -0400

> SIP vs SDP discussion.) Does anyone have thoughts on my other comment

I don't see much commonality. I have suspicion that there will be 
distinct bodies of people interested in working on these two things.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Mar 2015 20:22:21 -0700

> distinct bodies of people interested in working on these two things.

There are some people who are only interested in one of the two 
areas, while others are interested in both.  Obviously, different 
solutions are needed for the two problem spaces, and we have two 
drafts that each solve one of the two problems.

The work could be done in two groups, but given that both are aspects 
of the basic issue of facilitating communication among people who may 
use different languages, it also makes sense to do them in the same 
group.  I see some benefit and no harm.

-------------- Randomly selected tag: ---------------
The most savage controversies are those about matters as to which
there is no good evidence either way.        --Bertrand Russell