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
[1]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]
[2]https://wiki.mozilla.org/Loop/Architecture/MVP#GET_.2Fcalls.2F.7Btok
en.7D
[1] [3]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] [4]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
References
1. http://call.mozilla.com/
2. https://wiki.mozilla.org/Loop/Architecture/MVP#GET_.2Fcalls.2F.7Btoken.7D
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1023281
4. https://bugzilla.mozilla.org/show_bug.cgi?id=1015085#c3
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
