search

rayo / xmpp

Fork of the XMPP XEP repo
http://gitorious.org/xmpp
3 stars 3 forks source link

Race condition in outbound dialing #89

Closed benlangfeld closed 10 years ago

benlangfeld commented 10 years ago

Requests for creation of an outbound call via the <dial/> command suffer from the same race condition as Asterisk suffers from, documented in this thread.

The conclusion of the Asterisk discussion was that the API would support providing an ID in the origination request, which the resultant call would assume for its lifetime. This allows the client to guarantee that it knows the ID that events will come from before they will ever arrive.

It's my belief that Rayo needs to adopt the same thing, and that this could take two forms:

  1. Add a uri attribute to <dial/>. The call should be created at this URI if possible, or an error returned if not.
  2. Allow sending a <dial/> command to a call JID which doesn't yet exist, causing it to come online and assume the role of the requested call. This requires minimal spec changes, not affecting the model, and simply explaining this explicit resource creation behaviour. @mpermar originally objected to this idea when it was raised several years ago on the basis that PRISM Rayo call IDs had a special format used for sharding purposes in the gateway implementation. If that is a real concern for any current implementations, I guess there is a third solution:
  3. Implement a two-step call creation process, similar to that described in the Asterisk thread, in order to reserve a call object before it is instructed to be dialed. Combine this with option 2 in order to trigger dialing.

All of these options can be implemented in the server in a backward-compatible manner, falling back to the current behaviour. The issue lies in clients exploiting this feature. I would consider adding a special entry to capabilities info on the server indicating support for it, but since we're pre-1.0 and experimental still, this seems inappropriate spec-bloat.

My preference right now is option 2 for its simplicity, but I'm willing to be convinced of option 3. Any objections to this change to the spec? Anyone have any objection to implementing this functionality?

/cc @mpermar @crienzo

benlangfeld commented 10 years ago

This problem also applies to creating components. We should probably apply whatever solution we choose here to component creation also.

benlangfeld commented 10 years ago

@crienzo prefers option 1 here for its relative simplicity. I think I'm happy with this. I'll wait on thoughts from @mpermar.

mpermar commented 10 years ago

Hi guys,

I'm fine with either 1. or 2. as long as it is not 3. which overcomplicates things and adds some lag too. As long as it is optional I think everyone is happy.

Cheers, Martin

On Wed, Feb 26, 2014 at 7:11 PM, Ben Langfeld notifications@github.comwrote:

This problem also applies to creating components. We should probably apply whatever solution we choose here to component creation also.

Reply to this email directly or view it on GitHubhttps://github.com/rayo/xmpp/issues/89#issuecomment-36156823 .

Martín Pérez

Founder, http://www.jobsket.com

crienzo commented 10 years ago

Between option 1 and 2, I prefer 1.

benlangfeld commented 10 years ago

I'll get option 1 specified shortly.

benlangfeld commented 10 years ago

This will be in Rayo v0.4

benlangfeld commented 10 years ago

FS support requested at http://jira.freeswitch.org/browse/FS-6282