Summary:ASTERISK-01158: Alter IAX2 protocol to prevent competing registrations from multiple devices
Reporter:Steven Sokol (ssokol)Labels:
Date Opened:2004-03-04 18:10:18.000-0600Date Closed:2011-06-07 14:05:24
Versions:Frequency of
Description:Currently IAX2 allows a given set of credentials to be used from more than one device without notice or complaint.  This leads to situations where the two devices compete for call directed to their channel.  This leads to missed calls and also to general confusion.

Could we alter the message flow to allow for:

1) REGREQ--------------------->|
2) REGREJ[R]<------------------|
3) REGOVRD[SECRET]------------>|
4)                             |----------------->REJTERM
5)                             |<-----------------ACK
6) REGACK<---------------------|

In this case:

1) client A attempts to register using a set of credentials that have already been registered by client B.
2) Asterisk sends a rejection to client A with an indicator that the registration was rejected due to the crdentials already being in use.

3) Client A, perhaps after asking the user, sends a registration override message to Asterisk, along with the necessary credentials.

4)  Asterisk sends a reg termination message to client B, indicating that it will be logged out and should cease attempting to re-register ever X seconds (and perhaps client B will pop up a message saying "Unregistered, click here to re-register")

5) Client B sends an Ack indicating that it accepted the reg termination message and will cease its registration.

6) Having successfully logged out the previous device, the registry entry is updated to in point to client A, and Asterisk sends a regack to client A indicating that the registration has been properly updated.


I see this as having several positive characteristics.  First, it prevents the annoying "bouncing registration" issue from occuring.  Second, if we provide an additiona IE with the registration that indicates the phyisical location of the user, we have a big step towards presence monitoring.  We just need to add an application that conditionally allows users to query the presence and location of other users.

I also think that this could be done without breaking the current IAX2 protocol.  If client B did not understand the REJTERM message, it would send a NACK to Asterisk, and Asterisk would then have to REJECT the REG OVERRIDE message from client A.  Alternately, if client A did not understand the reason code for the initial rejection, it would still get the idea that it was not successfully registered.  Further, this would not have any impact on client A's ability to make outbound calls.

Thoughts?  Mark?


Comments:By: Brian West (bkw918) 2004-04-06 20:42:17

why not let it register more than one device per IAX login? Similar to how SER can do with SIP

By: twisted (twisted) 2004-04-18 02:17:11

HouseKeeping - This can be reopened if it's a serious request.

By: Steven Sokol (ssokol) 2004-04-18 18:07:27

I realize that this may need to wait for IAX3, or until the 1.0 release, but I was serious.  This has been a problem for me.  Brian may have the best solution -- alter the IAX2 registry to allow for multiple registrations of the same peer.  In any case, I think we need to have a mechanism for preventing or properly handling the competing registration issue.


By: Brian West (bkw918) 2004-04-18 18:56:21

Sip also needs to allow this also... :)

SER can... so asterisk should beable to do it with iax and sip.

By: Mark Spencer (markster) 2004-05-01 18:13:14

If anything I think that we could have a "priority" where your registration only works if it's got the higher level of "priority" on its registration.

By: twisted (twisted) 2004-05-01 19:56:31

could we specify priority based on device ip in iax.conf then?

By: Mark Spencer (markster) 2004-05-01 20:13:25

it would be a parameter of the register.  Of course the other thing is that we could simply permit you to register from multiple locations and send the call to more than one, but that would be a heck of a lot more work.

By: Steven Sokol (ssokol) 2004-05-02 10:50:00

If we have the priority tag, how do we control what device has the highest priority?  If we register a device with a lower priority, does the registration send back an indicator that "you were registered but you won't get any calls becuase you're not the highest priority registration"?

I still think the best answer is to paramterize it.  In iax.conf:

multireg=block OR override OR allow OR ringall

block = refuse to register until the existing registration is removed.

override = Notify and allow the user to override the existing registration (as described above)

allow = Allow the competing registrations as we have today.

ringall = Ring all devices registered with the same user id.

However we work it out, we have to end up with a solution where users don't log in and expect calls which may or may not arrive.  This is a _BIG_ deal for carriers who are rolling out IAX2-based soft phones and the IAXy.  Speaking of which...

How would we handle this on the IAXy, since the UI is limited to the analog phone and the associated indications?  Do we return a fast busy when the device goes off hook to indicate it simply CAN'T login?  Or do we use some method to temporarily register it (under a temp account), call it, and have Allison let the user know that something else is already using that login?


By: John Todd (jtodd) 2004-06-01 03:08:32

This doesn't really address the argument at hand, but I'm uncertain why you'd ever want to have multiple devices with the same login information, but that's just me.  It's "cheap" from a systems perspective to give out multiple logins that ring on the same numeric identifier.  The customer service issues aren't that significant.  But, I understand that not everyone has the same requirements as I do, and I even have some comments:

I think that the list above looks pretty reasonable, except that "override" seems to be something that needs to not be in the list.  When you start to talk about how to "notify" a user of something while they are not on the line, then you're really adding significant complexity.  

I'd add another type to Steven's list: mostrecent.   To use the instant message paradigm: I _expect_ my AIM client at work to get logged out when I log in from home.  I might expect the same thing from IAX2/SIP- the most recent client to initiate a registration is the one that "wins".   So, I can walk away from my IAXy, fire up my software client, log in with the same credentials.  Instead of the IAXy and the soft client "fighting" for the registration, the server would just look at who was the most recent client to "appear", and would respond correctly to both hard and soft phone's register requests (and accept calls, as well) but would only send outbound calls to the soft phone (in our example) because it was the most recent to change to a positive state.    If the soft phone suddenly fell out of registration (turn off laptop, network problem, whatever) then the IAXy would become the most recent valid client, and the calls would go in that direction again.  This is simply setting a timestamp on when a valid registration is seen, and then resetting/deleting that timestamp when the registration expires without refresh.

By: adam (adam) 2004-06-09 21:37:43

That would fit nicely into my desire to have the registration session open, not establishing a new registration session every three minutes. (Firefly keeps it registration open)

There's many other good reasons for it but it has nothing to do with this bug :)

I have to agree though, the current situation causes issues with end devices unaware they won't actually be receiving calls and worse still may receive some of the calls, leading them to believe it's working correctly.

By: Mark Spencer (markster) 2004-06-23 14:57:21

How do you determine which one is the "most recent"?  Do you mean the one to most recently go from being "not validly registered" to "validly registered"?

By: John Todd (jtodd) 2004-06-23 21:44:29

Mark: Yes.

I would suggest that a datestamp be created on the first valid registration of an IAX user/peer/friend, and that datestamp would remain constant until that registration times out without being renewed.  At that point, the datestamp would be reset to "zero" (or deleted, or whatever) and a check would be made to see the next most recent datestamp of the IAX user/peer/friend entries with the same credential information.

I suggest this as an optional setting, and not as the default behavior.

I'll also note that I don't typically see _good_ reasons for having the same credentials for the same entity registered in multiple places, but I can see how it would make life a lot easier from a dialplan and dialing rules perspective.  Those of us that prefer more exotic methods and "correct" methods to solve problems are often left only talking to the wall about our grand plans while short hacks to solve the problem get better utilized.  ;-)  "mostrecent" is a short hack that can be done other ways, but probably not more efficiently.

By: twisted (twisted) 2004-07-23 20:32:15

I'm going to suspend this for now, so we can revisit it later.