I'm trying to understand what kind of standard protocols can be used for "Raise hand" function in SIP VoIP calls. I see this function is implemented in many products, but I can't find any standard protocol definition for this.
Consider we have 3 entities: Host (call leader, Alice), Conference Server, Endpoint (regular participant, Bob).
Scenario: Bob presses "Raise Hand" button. Alice looks on a list of users in conference, and sees that Bob raised a hand.
What I was able to find so far:
Alice: can send SIP SUBSCRIBE to server to get NOTIFY messages about users in a conference (RFC4575 https://www.rfc-editor.org/rfc/rfc4575)
Bob: it can simply send DTMF code like *9 to conference server to raise a hand
Conference SIP Server: how it will notify Alice that Bob has raised a hand? Should it be also a NOTIFY message? In which format?
Alice: answered a question and wants to "lower Bob's hand". How it can be achieved in standard way?
Related
Consider I've 2 users Alice and Bob on my Jabber Server. To add into the rosters with subscription as both, I need to do the following steps:
Alice sends a subscription request to Bob.
When Bob receives the request, he approves it.
Bob may also be interested in Alice's presence, so he subscribes to her.
And Alice needs to approve Bob's request.
BUT
Now consider, Bob was not on the server, i.e. he is unregistered and Alice tries to add him into her roster.
Following are the steps which will take place:
Alice sends a subscription request to Bob.
Bob, being unregistered, didnt receive the request.
Alice->Bob subscription set as None.
Process ends Here.
Now, Bob got himself registered. How would Alice get to know that Bob got himself registered and she needs to send the subscription request again OR How would Bob pushes a notification to every user who added him into his/her roster? Which XEP/Ejabberd Module handles this?
We debugged Whatsapp and got to know that, in this case, Bob pushes a notification to all those users who added him in their rosters.
Well the way I see it's more like, which type of configuration do you employ as several scenarios come into factoring when setting up your environment. Here are a few ways I know such things might turn out.
The server in question plays a key role in connecting Xmpp clients, in a situation such as the on the Internet DNS servers play a prominent role in interconnecting clients, so if Bob was not registered at the time Alice sent a request, he might have a caching service that records all interconnection service, and when he becomes registered and he has an Xmpp service that auto-discovers peers on the network(like I said this would be user specific), but there has to be some type of user setting involved in the discovery process; his service would then pull all past requests from the cache and depending on time limits be able to retrieve Alice's request and then he can respond. This is more from a philosophical perspective. But if you are a developer , you can write plugins for all the described scenario above. If you need some more technical parameters we can talk about that such as the type of discovery method you want to write on Bobs server , the type of caching engine you might want to put on Bobs network and how to plug it into his Jabber server etc, this was just my own two cents. Just consider the situation somewhat similar as having a packet collector and retrieving offline messages when you log in, but in this case it would encompass the Jabber server and the packet collector would be the caching service engine you plug in to your server.
If it were a LAN, it might be a little more difficult to be as dynamic as retrieving host records and all inter-connectivity issues, but the plausible solution I can muster is to have a preemption of all available contacts, or better still operate withing a specific sub-net.
"What will happen in SIP if both parties send INVITE to each other at same time"
What will be the behavior in the above case?
Which call will Process?
The received first INV may be proceed to establish the call by the SIP Proxy, whereas the received second INV maybe rejected by a 4xx response. But since SIP is session based it is also possible that the Proxy can establish both calls. But one call should be in hold state. Only one call will ve active.
The most likely behaviour is that the SIP user agents would display a new incoming call.
Since they would also both have an outgoing call in progress it would be up to the user as to whether they would answer the incoming call or ignore it and persist with their original outgoing call.
The crucial point is that the two INVITE requests are independent. It would be the same as if two people called each other on their mobile phones simultaneously.
RFC 3261 section 14.2 says
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
So, I think both the parties will generate 491 response to each other. But I am still not sure as both of these INVITE will be part of different dialogs and standard mentions on the same dialog.
I have establish chat communication between two users using jabber-net xmpp client and vysper server by apache.
I am looking for broadcast facility using the same.
There are different mechanisms for "broadcasting", a word which I understand as "sending one message which is distributed by the server to many receivers".
When a user changes his "status" (for example "do not disturb me - I'm coding") a so call "presence" message is sent out which is distributed to all his contacts. This is a broadcast, and presence messages are intended to do that in XMPP.
There is at least another popular possibility: multi-user chat ("MUC"). MUC has the notion of "rooms", where users can "enter" to become part of a "conversation". Every message sent by one of the participants is sent to all others.
There are more similar mechanisms available, depending on what you actually want to do.
At this moment we are building a new architecture that is based on the principles of CQRS and domain-driven-design. We are now having some discussions about how we should deal with external communication. To make the question more concrete I use the example of sending a SMS notification when a customer creates a order.
The client creates a NewOrderCommand that is handled by the associated command handler. The handler creates a new Order object in the domain model, that generates a NewcustomerCreatedEvent. The object is saved in the event store and the event is published to all the listeners.
So far so good but now the question. Where should we sent out the SMS notification?
Our first instinct told us we should send it out by using a event listener that listens for the NewCustomerCreatedEvent and sends out the message. The problem with this approach is that the sending of the SMS is also part of our business logic. We are selling hosted services so our clients should be able to see all the SMS messages that are sent on their behalf. Because the sending of the message takes place outside of the domain we are not able to do that.
So we created an SMS domain and now when the event listener receives the NewCustomerCreatedEvent the event handler creates a new command SendSmsMessageCommand that will create a new SMSMessage object in our domain, sends out the SMS notification and creates a SmsSent event that we use to create the view.
At first we were sending the SMS message in the domain model, but we realized that this could give some problems. Let's say that after sending the SMS something happens (an exception is thrown) and the transaction is rolled back. Our domain supports this completely so data wise we are ok, but the SMS message is already sent, so when the command is resent the SMS notification will be sent again.
We were thinking about sending out the SMS on the SmSSent event but that would be a little bit strange, because the event says the message is already sent but is isn't.
The example above brings us to the question how to deal with external communication in the CQRS and domain-driven-design concept? We are not only talking about sending an SMS notification but also about sending an invoice to and external billing system and all other sort of communication to the outside world. Should we do this in the domain because it business logic or should we always do that based on events in our event handlers? And if we do so, is it acceptable to use events that say that the message is sent when it's not actually done yet?
Hope you guys have already dealt with this situation and can give us some advice on this subject.
I would think a domain object for the SMS message is not necessary. You just need to report the SMS's sent to the customer, correct? The SMS messages are not used in any domain logic, correct?
So I would have the handler send an SMS and then publish another event that says an SMS was sent and have an event handler listen for the SMS sent message and materialize that info in a read model so that the customer can view them.
You could use a Saga, or a Process Manager as Microsoft calls it. This basically listens to events, which change the saga's state, and issues commands based on the state logic implemented in the saga.
In your case it would be a two state saga, that waits for both CustomerCreatedEvent and OrderCreatedEvent, and, either issue a command to send an sms, if you have a specialised bounded context for communication, or call an infrastructure service, through an interface, to send the sms.
Here you can find Microsoft's article on the saga/process manager pattern:
https://msdn.microsoft.com/en-us/library/jj591569.aspx
And two articles containing implementations:
http://danielwhittaker.me/2015/03/31/how-to-send-emails-the-right-way-in-a-cqrs-system/
http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/
I'm working on a design for a xmpp chat solution which involves some servers and where at least one server is connected with serious bandwidth limitations.
Assuming, we have two servers A and B, some users 0..n connected to Server A and some conferences 0..m provided by Server B.
Now assume, some users enter a conference room and a message is sent to that room. Will
Server B send this message once to
Server A and Server A distributes it
to the users or will
Server B send this message to each individual user of Server A?
According to the protocol spec, XEP 045, multi-user chat messages are reflected independently to each participant. I can't tell on a brief read if it is legal to send them server-to-server without reflecting. However, it might be worth asking this question on an xmpp.org mailing list, where the experts tend to hang out.