(reposting with better formatting, the list didn't liked HTML)
Thanks Adam;
Here are a couple of remarks / comments about what's proposed in the
document:
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.
[0]
https://wiki.mozilla.org/Loop/Architecture/MVP#GET_.2Fcalls.2F.7Btoken.7D
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1023281
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.
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.
Instead of exposing the callerId in terms of MSISDN number / email, we
could use the alias identity services is providing to us (I believe it's
something like <hash(email)>@identity.services.mozilla.com>).
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?
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, as I commented at [3].
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1015085#c3
POST /call-url/{token}
=================
That's a way to update an existing call url, it should be a using the PUT
method.
Deprecated endpoints
=================
(We want to deprecate the current ways to be notified of the
cancellation of a call — and to cancel the call).
If we decide to go the websocket-only way, then it makes sense to
deprecate these two endpoints.
However, I would like to have a confirmation that it makes sense from a
mobile perspective.
Web sockets
==========
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.
I don't know how websocket channels work atop the GSM network and if
they're reliable enough. If not, we could consider also using another
mechanism to send in-call information the other 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.
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). In the former
case, we probably should add the callId inside the progressURL.
If we do this change, error handling for a wrong callId would be done
even before starting a websockets connection.
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.
> Offered traffic 0.1 Erlang per subscriber
Is this a typo? I don't understand the meaning.
> Maximum Simultaneous Connections 11,656,238
Current max sockets connections on an EC2 host is 250K. This means we'll
need approx. 46 servers to handle the long term max sim. connections.
This seems to be a lot of servers (for 500M users).
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.
Thanks again, this doc is really useful,
— Alexis
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
