On 6/16/14 04:54, ale...@mozilla.com wrote:
Returning the issuer as part of the 302 on GET /call/{token} [0]
================================================
This is not compatible with the fact we try to not do a 302 anymore [1] in
order to a) avoid a roundtrip b) have urls such as http://call.mozilla.com
directly.
If we do use the fragment portion of the URL to send back information
(and we don't do a 302, e.g. we return it directly as a result of POST
/call-url) then anyone will be able to craft the URLs they send to look
like they're issued by anyone else.
One potential way to fix this is to add a GET on /call/{token} to
retrieve information about the call.
Sure, and that was my original design -- I was trying to avoid a second
round trip after the 302. But if we're going to be hosting the static
assets on the loop server (which I would have preferred from the
outset), then adding an explicit GET seems to make the most sense.
GET /calls?version=<version>
========================
In the flow you're proposing, we're returning two additional fields:
"callType" and "callerId" (the already mentioned progressURL put
aside).
About "callType": to be able to return the callType, we'll need to update the POST
on /calls/{token} to have an additional parameter "callType". I don't see this anywhere
in the proposed changes, hence the remark.
Ah, right. I'll fix that.
About "callerId": we currently don't expose the identity of the users of
our service to consumers. In other words, the callerId is not currently stored by the
server. If that's an information we need to disclose to consumers, then it needs the
server will need to store it, and that's something we tried to avoid until now.
Unfortunately, I don't see a way around it, at least for the duration of
call set-up. Once the call is set up, the information can be removed.
But we do need a unique, authenticated calling party identity for
user-to-user calls; see below.
Also, the UX mockups doesn't actually rely on any MSISDN number / email
address, but just displays a name. Wouldn't it be enough to let the
caller tell who she is?
No; the calling user identity needs to be authenticated. Among other
reasons, the identity of the calling user is used to determine whether
the called party is willing to even be disturbed by the incoming call:
note that the UX mockups include an option to receive calls only from
users in your address book. If the identity that shows up isn't unique
and authenticated, then this privacy feature is trivially circumvented.
POST /calls/user
=============
The resource location sounds wrong to me. The action we are trying is to
start a call, and as such we should be doing a POST on /calls to create a new
call
I don't care what color this bikeshed is. If you think it's
easier/cleaner/whatever without the "user" component, I'm happy removing it.
POST /call-url/{token}
=================
That's a way to update an existing call url, it should be a using the PUT
method.
No, not any more than the initial creation of the URL should be PUT.
This has side effects that well exceed those that are normally
associated with document PUT requests.
I know fernando (from TEF) wanted to avoid the cost of setting up web
socket connections on the client if possible, since we already have a
connection to the push server we could potentially leverage.
In talking to Doug Turner, he's had some concerns about the speed with
which push notifications are delivered to the client. For the kinds of
rapid-fire messaging we're talking about here, it's almost certainly not
up to the task.
I'm a little confused about the concerns regarding short-lived
websockets connections from the mobile device: these are just TCP
connections, which demonstrably work just fine from mobile devices.
*"progressURL :**WebSockets URL the client needs to connect to in order to complete
call setup procedure.*"
I believe this description doesn't reflect what the progressURL is. My
understanding is that it's somewhere you can connect to to be notified
about the progress of the setup call.
Sure, I'll clarify this text.
In the case we'll get more than one call setup at once for a client, it's
currently not clear to me if the client should setup more than one websocket
connection (e.g. one per call-setup or one for all of them).
Yes, the intention here is to have one per call. The messaging and
connection management becomes far more complicated if we try to combine
multiple calls in a single connection; and the gain for this extra cost
is virtually zero once you consider how frequently this situation will
arise.
In the former case, we probably should add the callId inside the progressURL.
I'm not sure what this gains you, but I'm not opposed to doing so.
For the "connecting", "half-connected" and "connected" states, you refer to
"the media" (media is not yet confirmed), but it's not clear to me what this is specifically. Can you
elaborate? I don't understand why this needs to be relayed by the server.
It needs to be relayed by the server because the endpoints don't have
any other way to communicate with each other. The point is to supervise
call setup to the point that both endpoints are satisfied that the call
is established. To have a polished UX, we need this information so that
reasonable progress and error information can be rendered to the user.
Offered traffic 0.1 Erlang per subscriber
Is this a typo? I don't understand the meaning.
No, it's not a typo -- it's an estimate of the peak traffic generated on
a per subscriber basis. "Erlang" is a unit of voice traffic load (see
https://en.wikipedia.org/wiki/Erlang_%28unit%29). Reasonable values for
offered traffic are generally in the range of 0.05 to 0.15 Erlang per
subscriber (and I suspect ours will be on the lower end of this), so I
picked a value somewhere in the middle.
I'm including my assumptions here in case someone with a telecom traffic
engineering background wants to double-check my work.
Transition
========
While the (lack thereof) concerns you're raising are valid, it doesn't
seem to make sense to avoid flag days for something that's MLP and only
released in nightly. e.g. in case it breaks, I believe we should just
let it break for now and focus on getting the new APIs right rather than
having backwards compatibility at this stage of the project.
I suppose a large portion of this depends on how quickly the change can
be made to the server, and how many users are experimenting with the
service at that time. In any case, given how little effort it would be
to keep the already issued URLs valid, I see no reason to rip out
working code rather than simply moving it behind a length check.
--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
