Re: [straw] What is an "end"?

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Paul,

-----Original Message-----
From: straw <[e-mail]> on behalf of Paul Kyzivat
<[e-mail]>
Date: Wednesday, 2 December 2015 at 8:37 PM
To: "[e-mail]" <[e-mail]>
Subject: [straw] What is an "end"?

>On 12/1/15 1:40 PM, Ben Campbell wrote:
>
>> - Define what we mean by e2e. I _think_ we are talking about end-user
>> devices, and that we don't want to leave room for semantic games along
>> the line of calling a b2bua an "end". (This would change the arguments
>> around certain requirements, e.g."don't terminate srtp".)
>
>I think this is important! And I think it goes beyond this draft or
>perhaps even this WG.
>
>ISTM that the definition of "end" is a matter of control. I may have a
>server somewhere (maybe in a cloud), as well as one or more local
>devices. As long as I control it and am aware of its behavior it can be
>considered an *end* representing me, and carry my identity in the
>signaling.
>
>And this can be true even if it is not an "end" in the overall topology
>of a call. For instance, I could have a B2BUA (application server)
>between my phone and the "other" party in a call. It might record the
>call (on my behalf) or otherwise process the media. It could serve as
>the hub for a decomposed endpoint.
>
>OTOH, a "traditional" SBC is typically *not* entirely under my control.
>It may well have policies that I disagree with, but can't avoid. I would
>like to ensure that it can't access the content of my media.

Agree with all the above. I don¹t see a way by which one endpoint can know
if the peer is a endpoint/B2BUA or SBC.
If both peers are using rfc4474 it can verify the identity of the peer but
it will still not tell whether that is the final destination
for the call or if the call goes beyond that device(like in the case of
B2BUA/SBC).

I don¹t see a way to solve this with existing mechanisms.

Ram

>
>This gets tricky when my SP provides application services to me in a
>shared server. It may give me some configuration options to influence
>the behavior of that server. But it may also have other policies of its
>own that it doesn't allow me to control.
>
>	Thanks,
>	Paul
>
>_______________________________________________
>straw mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/straw