Ambiguity in call/mixer subdomains #41

Closed
bklang opened this Issue Jun 16, 2012 · 10 comments

3 participants

@bklang

The proposed spec recommends that calls be in a "call" subdomain, and mixers in a "mixer" subdomain. How strong is this recommendation? The spec clearly assumes that implementations will follow the recommendation.

Consider this case from Example 20:

<iq from='shakespeare.lit'
    to='juliet@capulet.lit/balcony'
    type='result'
    id='h7ed2'>
  <ref xmlns='urn:xmpp:rayo:1' id='9f00061'/>
</iq>      

The spec proposes that this call be assigned a JID 9f00061@call.shakespeare.lit, but the Rayo client would have no way of knowing that unless it was configured as such or the specification required it. Without a hint to the contrary, the least surprising assumption would be that the call's ID be in the same domain as the offer was placed, or in this case 9f00061@shakespeare.lit. The spec goes on to say that the subsequent ringing event would be from a calls subdomain:

<presence from='9f00061@call.shakespeare.lit'
          to='juliet@capulet.lit/balcony'>
  <ringing xmlns='urn:xmpp:rayo:1'/>
</presence>

But in that case, is it really safe to assume that this is the same call? Though somewhat unlikely, it is currently possible that two different call subdomains exist, perhaps in some kind of clustered rayo backend where call1.shakespeare.lit and call2.shakespeare.lit are handled by different backend processes. It is further possible that two identical call IDs would be issued, one for each call subdomain. In that case it would be impossible for the Rayo client to distinguish which call was which.

I suggest a these clarifications:

  1. Decide whether call and mixer subdomains are required, and whether the names are a part of the specification. I would argue against making this a requirement; if an implementation wants to use a single domain for everything, why should that not be permissible?

  2. Have some way of unambiguously relating call IDs with their resulting JID. One way to do this would be to make the call ID returned by the "originate" iq result be the full JID like this:

<iq from='shakespeare.lit'
    to='juliet@capulet.lit/balcony'
    type='result'
    id='h7ed2'>
  <ref xmlns='urn:xmpp:rayo:1' id='9f00061@call.shakespeare.lit'/>
</iq>
@benlangfeld
Rayo member
  • So, firstly, call IDs should be universally unique.
  • I agree about clients needing to know which subdomain call events will come from.
  • The subdomains should not be required, but should be permissible, as long as they are subdomains of the service domain, much like XMPP components.
  • I agree that all refs should include a full address, rather than a simple ID, but possibly both.
@benlangfeld
Rayo member

@loopingrage I'm going to go ahead and make this change unless you speak up.

@loopingrage
Rayo member

The issue with this change is that it leaks XMPP details into the Rayo payload. This is not desirable. How about requiring that XMPP implementations provide a 'disco' service to get the call and mixer domains (if any)?

@benlangfeld
Rayo member

At this point I don't think we have any reason to care about leaking xmpp. We can offset this by making two changes:

  1. Adding a URI scheme to the ref:
<ref xmlns='urn:xmpp:rayo:1' id='xmpp:9f00061@call.shakespeare.lit'/>
  1. Permitting multiple ref elements, one per transport:
<iq from='shakespeare.lit'
    to='juliet@capulet.lit/balcony'
    type='result'
    id='h7ed2'>
  <ref xmlns='urn:xmpp:rayo:1' id='xmpp:9f00061@call.shakespeare.lit'/>
  <ref xmlns='urn:xmpp:rayo:1' id='http://shakespeare.lit/call/9f00061'/>
</iq>
@bklang

Is it safe to assume (read: we should make it explicit) that each <ref/> element returned is equivalent, and that the Rayo client should choose the id that makes the most sense? This bothers me a bit, in that the id should probably be an opaque string, rather than something we introspect. Also, does having multiple <ref/> elements mean that the Rayo server has to track all IDs that are returned, because the client could select any of them?

@benlangfeld
Rayo member

The client should parse all URIs returned and choose one based on which transport mechanisms it supports (ie the URI scheme). Duplicating this information in a transport attribute feels wrong.

If a server supports multiple transports, its internal config should determine which are active, and the server should only return refs for transports over which a call is accessible. Short answer, yes, and I don't see it being a problem.

@bklang

That assumes that id attributes are specified to be a URI. Is that true?

@benlangfeld
Rayo member
@benlangfeld
Rayo member

Go ahead

@benlangfeld benlangfeld was assigned Apr 3, 2013
@benlangfeld benlangfeld added a commit that closed this issue Apr 5, 2013
@benlangfeld benlangfeld Require that refs be a full URI for a call
In `<ref/>` elements, id is replaced by a uri attribute. When requesting joins, call URIs must be used.

Fixes #41
51a420c
@benlangfeld
Rayo member

I'm leaving out multiple refs for now pending a use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment