Re: WebRTC Service: On temporary call URLs
On 2/24/14 05:07, Alexis Métaireau wrote:
That's interesting, because I had something in mind that I haven't
made explicit: because the token server returns nodes to use for the
users, I was planning on using this in order to avoid charging the
load balancers. e.g. something like this (Bob wants to be called):
1. Temp URL is generated by the server for Bob. This URL is tied to a
node, e.g. https://node42.loop.services.mozilla.com/call/{token}
2. Bob gives this URL to Alice in order to be called
3. Alice clicks on the link and the node know what's the format of the
token because /node42/ runs only this version of the service.
As long as the version of the service is valid, node42 is up, and when
this is not valid anymore we can ditch it.
Sure, that does effectively the same thing with the load distribution
advantage you describe. I'm perfectly happy binding the token syntax to
the authority name like you suggest.
However, this approach doesn't work well in the case we want these
temporary URLs to be persistant (the b. case).
If we're handing out different servers for different format versions, we
can defer this until we actually deploy permanent tokens (assuming we
eventually decide to do so). In other words, the permanent tokens will
need to be at a different authority (machine), and we can use versioning
for that machine's URLs only.
So let's go with what you propose, and we can worry about putting
versions in the URL path when and if they become necessary.
--
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
Re: WebRTC Service: On temporary call URLs
Le 20/02/2014 18:15, Adam Roach a écrit :
> The "version" allows us to transition between schemes in the future,
> if we need to change the properties of the URL -- it allows us to
> unambiguously change the format of the {token} [2]. For example, if we
> decide to re-key the HMAC, we can increase the version number. The
> same goes if we decide to add fields, encode them differently, or even
> go to a completely different design (such as a sparse key into a
> database table).
Right! If I get this right, this is to be able to have an URL generated
at a time /t1/ still be valid at /t2/, where /t2/ - /t1/ <= token duration.
That's useful when a) on a transition period and b) if we're planning to
have such URLs not temporary (e.g. without expiration).
My assumption was that these URLs would always be temporary, and in this
case we probably want to shut down the node once is
reached.
That's interesting, because I had something in mind that I haven't made
explicit: because the token server returns nodes to use for the users, I
was planning on using this in order to avoid charging the load
balancers. e.g. something like this (Bob wants to be called):
1. Temp URL is generated by the server for Bob. This URL is tied to a
node, e.g. https://node42.loop.services.mozilla.com/call/{token}
2. Bob gives this URL to Alice in order to be called
3. Alice clicks on the link and the node know what's the format of the
token because /node42/ runs only this version of the service.
As long as the version of the service is valid, node42 is up, and when
this is not valid anymore we can ditch it.
However, this approach doesn't work well in the case we want these
temporary URLs to be persistant (the b. case).
This all boils down to: do we want to support such "persistent" URLs ?
If yes, then what you're proposing (versioning the token) is useful. If
not, then I think we can avoid doing so.
— Alexis
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/21/14 11:58, Romain Testard wrote: Guys, I want to clearly understand, will this prevent URL customisation (mz.la/romain) as well as easy to remember generated URLs (mz.la/two_driving_dolphins) ? I'm not sure we want to do these things but I want to understand the implications of that decision. Because of the mechanism I'm proposing for revocation, the URLs we're generating right now will be time-limited. This can be a relatively long time period, like on the order of a month, but not indefinite. So, you can go ahead and shorten these URLs with a service, but the shortened URL's period of validity will be bound to the longer URL's period of validity, unless the service allows you to update the long URL associated with a short URL. That said, because we have an indicator of the token format (the "version" in my original email on this topic), it's very easy to bolt on "permanent" call-me URLs at a later date, once we know how they need to behave. But "how they need to behave" is actually much trickier than it appears at first glance; in particular, the revocation story gets murky: if you've given "mz.lo/romain" out to hundreds of people, revocation is a pretty extreme measure, akin to changing a phone number. And we almost certainly don't want to roll permanent URLs out without some kind of revocation, as this could make the service functionally useless for people: would you continue to use the service if you started getting nuisance calls on "mz.la/romain" as frequently as you get email spam? So I think the important thing to note is that we don't support what you propose right now, but we do have specific architectural hooks that will allow us to add it at a later date once we better understand the requirements. -- 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
Re: WebRTC Service: On temporary call URLs
On 2014-02-21, at 09:58, Romain Testard wrote: > Guys, I want to clearly understand, will this prevent URL customisation > (mz.la/romain) as well as easy to remember generated URLs > (mz.la/two_driving_dolphins) ? > I'm not sure we want to do these things but I want to understand the > implications of that decision. I don’t think that there would be a problem with using a URL shortener. If the question is whether you might be able to generate call URLs with vanity paths, then I think that the answer would be no: that’s what a URL shortener is for :) ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
Guys, I want to clearly understand, will this prevent URL customisation (mz.la/romain) as well as easy to remember generated URLs (mz.la/two_driving_dolphins) ? I'm not sure we want to do these things but I want to understand the implications of that decision. Romain On 2/20/2014 8:31 PM, Adam Roach wrote: On 2/20/14 12:08, Dan Mosedale wrote: On Thu Feb 20 09:15:15 2014, Adam Roach wrote: Keep in mind that the nominal user experience for this, once we get to MVP, will be rooted in an address book. I'll have my list of contacts, which includes phone numbers and email addresses. When an address book user is activated by a user, we'll check whether the contact info corresponds to a Loop user. If so, we place a call in that direction; otherwise, we offer to create a "call me" URL and (if possible) deliver it using the contact means (email or phone/SMS) corresponding to the address book entry. So, when we create the URL, we'll know who the user intends to give it to. This is important because it allows us to say "You have an incoming call from Alexis" rather than "You have an incoming call from some random person." The delivery of calling party identity is simply considered table stakes for a communications service nowadays [1]. I'm confused. Isn't the main use case for the "call me link" making it very easy for someone who doesn't already have an account to become engaged enough with our tool that they will be interested in upgrading to get an account to get the better user experience you're describing? The "better user experience" you call out *is* for the user with an account, for whom we presumably want as pleasant an experience as possible. The user *without* an account still has to deal with activating the link that has been provided to them. In fact, from the perspective of the user *without* an account, there will be literally zero difference in experience between the system I describe and one without this feature. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/20/14 12:08, Dan Mosedale wrote: On Thu Feb 20 09:15:15 2014, Adam Roach wrote: Keep in mind that the nominal user experience for this, once we get to MVP, will be rooted in an address book. I'll have my list of contacts, which includes phone numbers and email addresses. When an address book user is activated by a user, we'll check whether the contact info corresponds to a Loop user. If so, we place a call in that direction; otherwise, we offer to create a "call me" URL and (if possible) deliver it using the contact means (email or phone/SMS) corresponding to the address book entry. So, when we create the URL, we'll know who the user intends to give it to. This is important because it allows us to say "You have an incoming call from Alexis" rather than "You have an incoming call from some random person." The delivery of calling party identity is simply considered table stakes for a communications service nowadays [1]. I'm confused. Isn't the main use case for the "call me link" making it very easy for someone who doesn't already have an account to become engaged enough with our tool that they will be interested in upgrading to get an account to get the better user experience you're describing? The "better user experience" you call out *is* for the user with an account, for whom we presumably want as pleasant an experience as possible. The user *without* an account still has to deal with activating the link that has been provided to them. In fact, from the perspective of the user *without* an account, there will be literally zero difference in experience between the system I describe and one without this feature. -- 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
Re: WebRTC Service: On temporary call URLs
On Thu Feb 20 09:15:15 2014, Adam Roach wrote:
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible)
deliver it using the contact means (email or phone/SMS) corresponding
to the address book entry. So, when we create the URL, we'll know who
the user intends to give it to.
This is important because it allows us to say "You have an incoming
call from Alexis" rather than "You have an incoming call from some
random person." The delivery of calling party identity is simply
considered table stakes for a communications service nowadays [1].
I'm confused. Isn't the main use case for the "call me link" making it
very easy for someone
who doesn't already have an account to become engaged enough with our
tool that they will be interested in upgrading to get an account to get
the better user experience you're describing?
Otherwise how do we expect to convince enough people to bother to
create a Firefox account, given that the network benefits (i.e. the
systems that all your contacts are already reachable on) have already
accrued in other systems that are believed to be relatively well-liked
(viz Skype, mobile phone)?
Dan
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future,
if we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The
same goes if we decide to add fields, encode them differently, or even
go to a completely different design (such as a sparse key into a
database table). It gives us an "out" to reconsider the design of the
token if it doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature
of the system, not a problem: the check for revocation of a serial #
is part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme
in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple versions of the application; it's multiple versions
of the URL field format. At any given moment, any single version of
the server application running would be expected to be able to parse
the current URL format, plus any of the previous URL formats that have
been issued within the ${max_url_duration} seconds.
Yes, this requires some conditional logic in the server code when (if)
we decide to change to change the token format, but that should be
pretty lightweight.
[1] cf.
http://pimcore-1872623517.us-east-1.elb.amazonaws.com/infoservices/resources/whitepapers/whats-next-in-caller-identification-services#.UwYya8dn9N0
[2] Since the current plan is for all tokens to be time-bounded with a
known maximum possible duration, the general means of transitioning
from token format "n" to token format "n+1" would be to introduce the
new format on the new version number; have both formats running
side-by-side for this maximum possible duration; and then retire
format "n" altogether.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/20/14 04:54, Alexis Métaireau wrote:
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
Sure, for most of the HTTP interactions, this is true, and it's a good
principle in general. The way I was viewing this was that the handed-out
call URLs (unlike other operations we're performing) weren't going to be
idempotent: accessing the resource twice would create two calls. In
traditional HTTP design, this would typically be relegated to something
like POST, but we can't pass around URLs with an embedded method in a
well-supported way.
That said, I see that the GET/POST proposal you have addresses this in a
more resource-based fashion, and agree that it's a cleaner way to handle
URLs.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme...
# A "*" means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible) deliver
it using the contact means (email or phone/SMS) corresponding to the
address book entry. So, when we create the URL, we'll know who the user
intends to give it to.
This is important because it allows us to say "You have an incoming call
from Alexis" rather than "You have an incoming call from some random
person." The delivery of calling party identity is simply considered
table stakes for a communications service nowadays [1].
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future, if
we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The same
goes if we decide to add fields, encode them differently, or even go to
a completely different design (such as a sparse key into a database
table). It gives us an "out" to reconsider the design of the token if it
doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature of
the system, not a problem: the check for revocation of a serial # is
part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme
in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple ver
Re: WebRTC Service: On temporary call URLs
Adam, thanks for starting this discussion,
Le 20/02/2014 04:52, Adam Roach a écrit :
> Putting this together, what we want is something that semantically
> evaluates to:
>
> http://authority/action/url-format-version/{serial
> #,caller,callee,expiration,hmac}
As Martin points out, URLs should not represent actions, they should
represent things.
On the experiment we made with Romain Gauthier and Nicolas Perriault, we
went ahead and chose the following scheme:
# A "*" means this URI requires authentication (a valid token from the token
server,
# which contains user id).
* POST /call-url/ → Create the call url a callee can click on.
GET /calls/{token} → Get the app (that's the url in question, which
displays an app)
POST /calls/{token} → Add an incoming call (does a simple push notif
and gets room tokens)
* GET /calls/ → List incoming calls for the authenticated user.
{token} was something that is containing the user id of the callee plus
a . I don't understand why we're trying to put information about the
caller here, since we don't know who is this.
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
> Ideally, we also want the ability to identify multiple versions of URL
> encodings, should we decide to migrate to include an enhanced scheme
> in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
— Alexis
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
On 2/19/14 22:32, Martin Thomson wrote: I think that you need to consider confidentiality here as well. It might be desirable to have the addressing information concealed. That implies a mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens You'll note that I employ pretty much that technique exactly, modulo the encryption (which I call out in the final paragraph as "not in this version, but probably desirable for the next", and which the draft concedes is optional) and the use of bitmasks and bloom filters for invalidation (since revocation is expected to be exceedingly rare). That leads to the next concern, which is that committing to a URI format is not wise in general because that can dictate server architecture. If you do as you describe (s/http/https), then loop.services.mozilla.com is it. You can't hand out tokens that reference a specific deployment or server, you can't move stuff without paying redirect or proxying costs. Apparently, I was not sufficiently clear. I was not describing client behavior in any way whatsoever. I was describing server behavior. The intention here is exactly that the client asks for a full URL, and the server provides one. The client is in no way involved in synthesis of the URL. -- 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
Re: WebRTC Service: On temporary call URLs
Ultimately, we're going to need to hand out a URL that causes a call
to happen. To make sure you are understood, are you proposing making it
more "nouny" by doing something like passing out /contact/... URLs that
lead to a page with enough smarts to create a call (using the same
token) with a REST API? I can see some advantages of this approach; one
of these /contact/... urls could lead to a tiny bit of html that is
basically like an entry in a contact list, containing presence info, an
icon, and some buttons for placing calls (it might even have a chat
window). But, this is a bit more involved, and requires more server
resources. I do hasten to point out that there is nothing that prevents
us from adding this later on, if we think it would be useful.
As for the rest of the URL, I don't think anyone is actually
suggesting we treat these as anything other than opaque URLs; the
examples are merely that. Basically, we should write the client to
handle http:// ?.net/{anything well-formed} coming back from the server
that mints call (or more RESTy) URLs.
Byron
On 2/19/14 8:32 PM, Martin Thomson wrote:
As it stands, I believe that we have two "things" here: a registry of contact
URIs, and a registry of calls. So the nouns might be /contact/{token} and /calls/{token}.
That leads to the next concern, which is that committing to a URI format is not
wise in general because that can dictate server architecture. If you do as you
describe (s/http/https), then loop.services.mozilla.com is it. You can't hand
out tokens that reference a specific deployment or server, you can't move stuff
without paying redirect or proxying costs.
___
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
Re: WebRTC Service: On temporary call URLs
I think that you need to consider confidentiality here as well. It might be
desirable to have the addressing information concealed. That implies a
mechanism like: http://tools.ietf.org/html/draft-rescorla-stateless-tokens
Now for a variation on a well-worn screed that I had to repeat many times while
I was at Skype...
I think that the general guidance for designing APIs on HTTP is that URLs
should not represent actions, they should represent things. So /call/ might be
OK in the noun sense, but if the intent is to load this with other actions, I
think that I might have to question the wisdom of that. Not knowing what these
implied other actions are makes it hard to assess this properly though.
As it stands, I believe that we have two "things" here: a registry of contact
URIs, and a registry of calls. So the nouns might be /contact/{token} and
/calls/{token}.
That leads to the next concern, which is that committing to a URI format is not
wise in general because that can dictate server architecture. If you do as you
describe (s/http/https), then loop.services.mozilla.com is it. You can't hand
out tokens that reference a specific deployment or server, you can't move stuff
without paying redirect or proxying costs.
Since you are minting tokens anyway, why not provide clients with all the URIs
they will need, in full, when the token is minted. Then you can hand clients
off to https://idontcareabout.loop.services.mozilla.com.itspants.for.me/ and
change URI layouts and all sorts of magical stuff. The only fixed part is the
starting point.
I'll also note that /call/1/... and /call/... are identical in very many
respects. The first is revised by increasing 1 to 2, the second by picking
another name.
(I have a design for a RESTful registrar API if you are at all interested. I
built two of those in the past year, it's a fairly straightforward pattern.)
- Original Message -
From: "Adam Roach"
To: dev-media@lists.mozilla.org
Sent: Wednesday, February 19, 2014 7:52:53 PM
Subject: WebRTC Service: On temporary call URLs
[For the tl;dr, skip down the the line starting "Putting this all
together."]
I realize that, while I've had a few discussions with people about the
nature of the temporary calling URLs, I haven't really communicated some
of the requirements we have around them, and how we can meet those
requirements.
Users need the ability to revoke a URL that they have passed out -- if
it, for example, falls into the hands of marketers or people from whom
they do not wish to receive communications, users need a means to tell
the server that the URL can no longer be used to reach them. This means
the calling URLs must be unique each time they are generated; and,
ideally, will identify the party to whom they were given. This also
means that the URLs need to be tamper-proof, which implies some form of
integrity protection.
Second, for this kind of system where users can and will create
boundless state at a potentially rapid pace, we need to ensure that the
server is not required to store all that state -- it just doesn't scale.
This means the calling URLs need to encode all the information necessary
to identify the called party and the calling party.
Now, revocation is inherently state that we need to store; but
revocation events should be infrequent. Nonetheless, we don't want to
store such state in perpetuity, which means all calling URLs need to be
time bounded: once a URL expires, we can discard any associated
revocation state. We can also optimize the size of the data we need to
store for revocation: by including a short, unique serial number in each
URL, a revocation record can consist simply of that serial number along
with a date after which the URL is no longer valid (and, consequently,
after which the revocation can be discarded). Both pieces of information
are readily available from a URL each time it is used. If we use, say,
64-bit serials and 32-bit expirations, this requires nominally 96 bits
of state per revocation, which is pretty cheap.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme in
the future.
Putting this together, what we want is something that semantically
evaluates to:
http://authority/action/url-format-version/{serial
#,caller,callee,expiration,hmac}
Where "hmac" is an HMAC that includes the serial #, the caller, the
callee, and the expiration. We may find that we want to add more fields
to the part I have inside brackets here; using an explicit URL format
versioning allows us to do this very easily.
For example (and this is meant to be illustrative, not normative), a URL
that is minted to call from "a...@mozilla.com" to "a...@nostrum.com",
with an expiration of March 1st, 2014 at 21:19:13 CST might crafted
first by concatenating these three f
Re: WebRTC Service: On temporary call URLs
On 2/19/14 22:03, Timothy B. Terriberry wrote: Adam Roach wrote: Now, revocation is inherently state that we need to store; but revocation events should be infrequent. Nonetheless, we don't want to I assume you've thought about just using time-based expiration instead? The issue is that nuisance calls tend to be repetitive, and if someone is getting them on a URL that has, say, one month of validity on it, we want them to be able to stop them now, not wait for them to stop a month from now. -- 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
Re: WebRTC Service: On temporary call URLs
Adam Roach wrote: Now, revocation is inherently state that we need to store; but revocation events should be infrequent. Nonetheless, we don't want to I assume you've thought about just using time-based expiration instead? ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
