I have a problem with WebRTC group chatting. [I have achived this on my code]
client-1 create's offerSDP for client-2
client-2 accepts the offerSDP and replay answerSDP to the client-1 (the creator)
client-1 accept and set it as remoteDescription. Now video chat happening.
fine,
Now client-3 comes in.
In my code client-3 receives client-1's offerSDP and emit's answerSDP to all the client's present in the server.
Now Both client-1 and client-2 will get the answerSDP from client-3 and both will recevies client-3's video.
Problem:
client-1 has [localvideo, client-2_video, client-3_video]
client-2 has [localvideo, client-1_video, client-3_video]
client-3 has [localvideo, client-1_video]. Here this client not knowing about client-2
why? what i have to do here? Helo me please.
You need to exchange a unique offer/answer pair for each connection. It's not possible to re-use them for different connections.
In your example client-3 would need to receive an offer from client-1 AND client-2. And it would need to send a unique answer to both of those other clients as well.
Related
I would like to send messages between two peers using WebRTC without a signaling server. I'm using QR codes to send over the connection descriptions, and I found an example implementing exactly this:
https://github.com/TomasHubelbauer/webrtc-qr-signaling-channel
However, it requires scanning the QR code both ways. I'm wondering if it's possible to only have to scan a QR code from the phone, but still establish a connection?
Conceptually, I'm thinking like this:
ClientA shows QR code, essentially saying "here's how to connect to me."
ClientB scans it, and now knows how to find ClientA.
ClientB sends "here's how to connect to me" to clientA.
They now both know how to find and talk to eachother.
However, this doesn't seem possible when looking through the WebRTC documentation. If this isn't possible to do - then why?
I strongly doubt it is possible.
During the offer/answer exchange, each of the peers generates a self-signed (D)TLS certificate and includes its cryptgraphic hash ("fingerprint") in the SDP. Without the answer's SDP, the offering peer would be unable to authentify the answering one.
You might be able to achieve the same user experience, however, by implementing a signalling server on one of the peers. The QR code would contain the URL of the signalling server together with authentication data, and once connected the two peers could perform a traditional offer/answer SDP, and even trickle ICE candidates.
Let's say I have an application that has a list of live streamers who are currently broadcasting via WebRTC. In order for a device to plug into a particular broadcaster, they need to send their SDP to the specific broadcaster that they click on.
So I gather my local SDP information, and send that to the Signaling server to be transferred to the broadcaster and await the answer.
My question is, how does the signaling server know which broadcaster to send this SDP to? And where do you store this identifier?
My first thought was use the ip address as the unique identifier but that can change as I move around and change connections.
And is it normal to store this identifier on the web socket itself as a property? I don't know how else you would know which web socket to send along the SDP?
Sorry if this is a n00b question, very new to WebRTC.
I also faced same situation like you.
In my case, I used Socket.IO for bidirectional communication.
So what I did is using member's id and socket.io's room.
When socket.io client connected to server, this client joined specific room automatically.
That room's name is client's socket ID. You can check this doc.
For example, your service is broadcasting. right?
And maybe broadcasters in your service have unique id (in Database).
So when client is connected to server, escape from default room immediately, and join new room that name is client's unique id.
Then, now you can send some messages like sdp to specific client with client's unique id.
So I managed to connect to the websocket with my API token and I do get notifications. For incoming calls, I do get a push with all info like so:
{"type":"push","targets":["stream"],"push":{"type":"mirror","source_device_iden":"XXXXXXX","source_user_iden":"ujC7S24sQxw","client_version":206,"dismissible":true,"title":"5555551212","body":"Incoming call","application_name":"Pushbullet","package_name":"com.pushbullet.android","notification_id":"6","icon"
"Big value here"}}
So I can see that call came from 555-1212 (I changed number for privacy) and it all makes sense. However, for SMSs, all I get is a notification that SMS changed. No body field so I can't see where it came from and what the message is. All it says is sms_changed for type:
{"type":"push","targets":["stream"],"push":{"type":"sms_changed","source_device_iden":"XXXXXXXXX"}}
What am I doing wrong? I would like to get the SMS message and sender info so that I can publish it. Any and all help will be greatly appreciated.
This is not publicly documented yet and we might be changing the implementation in the near future so I'm hesitant to make it public. Also I don't know the specifics of the current implementation.
You can view how it works right now by using www.pushbullet.com and looking at the network traffic (in chrome inspector) when you do SMS stuff on the website.
Signaling is not addressed by WebRTC (even if we do have JSEP as a starting point), but from what I understand, it works that way :
client tells the server it's available at X
server holds that information and maps it to an identifier
other client comes and sends an identifier to get connection information from the first client
other client uses it to create it's one connection information and sends it to the server
server sends this to first client
both client can now talk
This is all nice and well, but what happends if a 3rd client arrives ?
You have to redo the whole things. Which suppose the first two clients are STILL connected to the server, waiting for a 3rd client to signal itself, and start the exchanging process again so they can get the 3rd client connection information.
So does it mean you are required to have to sort of permanent link to the server for each client (long polling, websocket, etc) ? If yes, is there a way to do that efficiently ?
Cause I don't see the point of having webRTC if I have to setup nodejs or tornado and make it scales to the number of my users. It doesn't sound very p2pish to me.
Please tell me I missed something.
What about a chat system? Do you really need to keep a permanent link to the server for each client? Of course, because otherwise you have no way of keeping track of a user's status. This "permanent" link can be done different ways: you mentioned WebSocket and long polling, but simple periodic XHR polling works too (although this will affect the UX, depending on the interval).
So view it like a chat system, except that the media stream is P2P for reduced latency. Once a P2P WebRTC connection is established, the server may die and, of course, the P2P connection will be kept between the two clients. What I mean is: both users may always block your server once the P2P connection is established and still be connected together in the wild Internets.
Understand me well: once the P2P connection is established, your server will not be doing any more WebRTC signalling. The connection is only needed to keep track of the statuses.
So it depends on your application. If you want to keep the statuses of users and make them visible to others, then you're in the same situation as a chat system: you need to keep a certain link, somehow, to make sure their statuses are synced. Otherwise, your server exists to connect them together and is not needed afterwards. An example of the latter situation is: a user goes to a webpage, the webpage provides him with a new room URL, the user shares this URL to another peer by another mean, the other peer joins the room, server connects them together (manages WebRTC signalling) and then forgets them. They are now connected until one of them breaks the link. Just like this reference app.
Instead of a central server keeping one connection per client, a mesh network could also be considered, albeit difficult to implement.
I have a project coming up where I need to send and receive messages through a specific mobile operator, which only provides an SMPP interface. The whole project will be a hosted website. I have already read quite a lot, but I do not yet quite understand what is actually needed from my side to use the protocol.
Should my application try to maintain a constant connection to the smpp?
Can I simply connect, send a message and then disconnect?
Are receiving messages based on push or pull?
Thanks for the help.
SMPP is a peer-to-peer protocol. That should mean that SMS Gateway (your side) and SMSC (your mobile operator) need to have a proper bind/connection established. Even when there are no SMS or DLRs to send/receive, there is a continous exchange of smpp PDU (enquire_link/enquire-link_resp) that ensure that the bind is established.
In detail, if you send an enquire_link PDU and you get no response (enquire_link_resp) the bind is broken. Your sms won't be delivered (will remain enqueued in your gateway store), and you won't receive MOs (incoming sms) or DLRs (delivery report). To re-establish the connection you should re-initiate the connection.
So, my answer would be that you need a constant connection to SMSC.
You are stating you want to receive messages, as a result at least a bind_receiver is needed. Because you don't know when messages are going to come in, you will have to be constantly connected, rather than disconnecting after each event.
With regards to your question about "push or pull" this depends on how you solve the first problem. If you can build a solution that is constantly connected, the result will be a push (the carrier will push it to you as soon as they receive the message). If (for some reason) you cannot maintain a constant connection, you'll end up building a pull mechanism. You'll connect to the carrier ever X seconds to see if they have a message waiting for you.
I do need to highlight 2 pitfalls though:
A number of carriers in the world, do not store or even accept messages if you are not connected, therefore, depending on which carrier you interact with, you might be forced to use a continuous connection.
Most carriers do not allow you to open and close connections in quick succession. Once you disconnect, you can not reconnect for a time frame of X seconds.
Therefore a constant connection is really the way to go. Alternatively, you can look into a company like Nexmo, which will provide you with a HTTP Call every time a message arrives.
I'm not sure which language your developing your application in, but if you use any of the popular languages (Java, PHP, Perl) there are modules out there that handle basic SMPP Connectivity for you. A quick google search for your language and "SMPP Client" will give you a list of references.