I am running Asterisk 11 and using MySQL realtime. I've used FreePBX previously, and it shows all details how many users are registered in realtime. I can check a user registration if I type show peer username on Asterisk CLI. However, I would like to know whether a specific user has registered SIP server or not in realtime.
Example
UserA - registered
UserB - unregistered
UserC - registered
I checked sip_buddies table in MySQL, and it only shows regseconds. I couldn't figure out whether a user is registered or not with this information. Does anyone how to check user's registration in realtime?
You have 3 options
1) (bad one) do command "sip show peers" (rtcachefriends has to be set to yes)
2) (better one) create an event listener, which will listen for an event via AMI and store that info.
3) (db variant) Set
rtupdate=yes
rtautoclear=yes
and check in db registration time. Downside - a lot of db writes.
This is not the specific answer, but is a relevant solution to different Asterisk setups. Some deployments use openSIPS as a clients registration proxy (it's better than the baked in SIP capabilities of Asterisk, even with the new pjsip stack). In this case "sip show peers" will be empty. In that case you can use the Management Interface via the opensipsctl application. opensipsctl ul show on the proxy will show all clients registered to the proxy.
Related
We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2
types:
Block in one way. You are blocked, but you can write to
blocked user.
Block in two ways. You are blocked and you also can't
write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)
XMPP Clients
XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.
XMPP Servers
XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.
Help:see this link
If we are talking about XMPP protocol - there is an ability to block any communications from/to (see example 48)
So, by default, you can set it for each user for example.
Then, if we need to allow to communicate with someone specific,
then you can add this user to your privacy list with action=allow and order greater than 'full block'. Here is actually a good example of whitelist implementation via Privacy Lists, see example 8:
and (3) 'special', which allows communications only with three
specific entities.
We are developing a consumer hardware product. Each device is registered on a central webserver and the owner also have a user account to which the device is linked. The owner may also choose to share the device with other users.
Now, to solve the problem of getting through firewalls etc we are using XMPP: the user access his/her devices using an iOS/Android app. The app connects to the XMPP-server and so does the hardware devices. So the app can access the devices by sending custom XMPP stanzas.
Currently the device and the mobile app use the same JID, so the device will allow messages only from the same bare JID as itself uses. To allow for sharing devices we are planning to use the roster instead: the device will get its own JID ("hw381983829#thexmppserver.com") and will accept stanzas from all JID's in its roster.
The problem I'm having is that the users, devices and device-sharing data are stored on the webserver. I would like to use this same information on the XMPP-server: all users and devices on the webserver are allowed to login to XMPP and the roster of a device is the same as the users that may access it. This information can be accessed through a JSON API.
One way would be to mirror changes as they happen, but I don't like that idea since there are too many steps that could go wrong.
The best solution I can think of is to let the XMPP server use the JSON API instead of its builtin database. It would be read-only, but that is not a problem since all registration and sharing should be done on the webserver.
Any ideas on how to proceed? The functionality described above is more or less all that we need: we don't need S2S, offline messages, etc. We are currently using Ejabberd, but Prosody or Openfire are perhaps better alternatives?
For authentication, it looks like this ejabberd contribution does exactly what you need:
https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http
For roster, it is easy to write a custom roster module that will be hitting your HTTP backend instead of query the database thanks to ejabberd API.
You can have a look at mod_roster as a guide to implement the methods: https://github.com/processone/ejabberd/blob/master/src/mod_roster.erl
I'm new with web sockets, and i want to create a private chat with laravel between authenticated users and anonyme users , i'm not asking to give me the codes, i want a way to do that , i want to understand how can i do that
I'm thinking to that for a couples days ago, and i fount that i should make this steps :
1- Create chat with socket
2- intergrate it with laravel (1)
3- show connected users ( i don't know id if that i should make that with socket or with laravel framework )
4- fix the chat to make it private ( build some socket or somethink like that)
i want to know how i can do that ?
Thakns
https://packagist.org/search/?q=socket
If I were doing this, I would separate the sockets server and the frontend implementation.
This would allow you to scale both the dispatch and the client services at different rates.
You can use any library of your choosing, usually the best is going to be on the top.
http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket
That explains it a bit more than I am willing to.
basically you will have one instance of laravel that is only responsible for rest/socket communication. It will provide the client(frontend) with the information that it needs.
When a registered user logs in, You simply notify your socket server via rest a user has logged in, In turn your socket server will query the db for all currently logged in users, trigger the event of UserLoggedIn , attaching perhaps an array of logged in users which would then be broadcasted to all of the listening clients.
When a client receives that notification, your js (if necessary) would update the list of available chatters with the one provided by the dispatch.
You will also need to maintain a list of active unregistered user socket connections so that you know who's where and who should get what message.
This is the general idea behind it.
I just started working on xmpp its wiki page says that "The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server."Hence it is decentralized
In my application I want that user can create a specific group chat box on a click of button.
My question is if the main user who created chatbox become offline will the chat box created by him will remain alive as decentralized suggest that user who created will act as a server. If not , could anyone suggest what can be done for keeping chatboxes alive even when the user become offline.
Multi User Chats (called 'MUC' in the XMPP world) are hosted by a XMPP component. This means that the user who initiated the chat *does not act as chat provider, but this particular MUC component. This component runs usually on the same machine as your XMPP server. Therefore the chat exists - if the MUC is marked as permanent - even if the user quits the chat.
More information can be found in XEP-0045: Multi-User Chat
I have got an Openfire Jabber server with in excess of 75,000 users listed. Of those, 150 or more can be online at any one time.
Is there anywhere that I can collect the JIDs (usernames) of the currently logged in users? I have full database access to the underlying data, but the server does not appear to write the current status back to the DB. Because of the number of users, rosters are not being used.
A very useful set of data being returned would be from a simple (password protected) webpage with one JID per line, optionally with the login time, and maybe also the last time that account performed an action [like send a message]. The latter two are not as essential, but would be useful if the data is available, as well as any other information that was available regarding the user session.
dont know if this will help but I ran into it looking for similar functionality. As defined in XEP-0045 http://xmpp.org/extensions/xep-0045.html#disco-roominfo :
An implementation MAY return a list of existing occupants if that information is publicly
available, or return no list at all if this information is kept private. Implementations
and deployments are advised to turn off such information sharing by default.
So you would need to ensure it works as advertised on Openfire (all xmpp servers ive come across have a bug or two in them), and I imagine you would need to code some logic to get the results.
Good luck.
Not a perfect answer, but the query you want is probably embedded in the session-summary.jsp page. I got to it on a locally hosted server at http://localhost:9090/session-summary.jsp. What I don't know is if that is then stored in the database where it is query-able, or if it is stored internally to the client. The latter is more likely.
The data that page displays is Name, Resource, Status, Presence, Priority, Client IP, and Close Connection.