I have a Twilio SIP trunk connected to FreePbx, all users are using the webrtc module of FreePBX to make calls. They can make and receive calls fine with two way audio, however with outbound calls the caller does not hear ringtone (ringing) as the B number is ringing which is causing some level of confusion with the users.
I've checked the r flag in Outbound Dial Settings and this is enabled but other than this im a little stuck.
[SIP SETTINGS]
host=hostname
username=username
secret=supersecret
type=peer
In Settings -> Asterisk SIP Settings i have the external and internal networks set
To confirm, using a softphone with the extensions works fine, it's only via WEBRTC.
I've rung wireshark traces and these all show 180 ringing on both ends
Verbose call log: https://pastebin.com/s7BfwUMw
Looking at your logs, you're properly receiving the 180 Ringing event from Twilio at 10:17:13, after the call has started at 10:17:09 and has been answered at 10:17:19, so as you spotted it, the problem does not come from the upstream operator not sending the signalling information, but rather from Asterisk, or from the internal WebRTC FreePBX client.
Just thinking here, but if for some reason, your WebRTC client is not ready to handle audio event thought the call has started (and the callee is ringing), then you won't hear any ringback tone. Such situation can occur for example if your WebRTC client starts the call without having gathered all its ICE candidates (this is trickle ICE connection mode, but that should not be the case though, as I think Asterisk does not support it). Unfortunately, there's not much you can do in this case apart from modifying the configuration or JavaScript code of the WebRTC client.
Now, on the Asterisk side, indeed, the r option should do the job. I'm not sure FreePBX allows you to control the dialplan commands, but if it does, you may want to try to force Asterisk to answer the call, then playback a ringing tone while dialing out. The PlayTones function can be useful then.
exten => _44X.,1,Answer
exten => _44X.,n,Wait(1)
exten => _44X.,n,Playtones(ring)
exten => _44X.,n,Wait(3)
exten => _44X.,n,Dial(SIP/...)
Note that you will have to have a indications.conf file properly configured to have this working. I guess other functions like Ringing, Progress can be used, but I think the idea of answering the call before dialing out is worth a try. Of course, this is a bit hacky as the way to go should definitely be to use Dial without the r option.
Hope this helps!
Related
After a WebRTC session has been established, I would like to stop sending the stream to the peer at some point and then resume sending later.
If I call removeStream, it does indeed stop sending data. If I then call addStream (with the previously removed stream), it resumes. Great!
However, is this safe? Or do I need to re-negotiate/exchange the SDP after the removal and/or after the re-add? I've seen it mentioned in several places that the SDP needs to be re-negotiated after such changes, but I'm wondering if it is ok in this simple case where the same stream is being removed and re-added?
PS: Just in case anyone wants to suggest it: I don't want to change the enabled state of the track since I still need the local stream playing, even while it is not being sent to the peer.
It will only work in Chrome, and is non-spec, so it's neither web compatible nor future-proof.
The spec has pivoted from streams to tracks, sporting addTrack and removeTrack instead of addStream and removeStream. As a result the latter isn't even implemented in Firefox.
Unfortunately, because Chrome hasn't caught up, this means renegotiation currently works differently in different browsers. It is possible to do however with some effort.
The new model has a cleaner separation between streams and what's sent in RTCPeerConnection.
Instead of renegotiating, setting track.enabled = false is a good idea. You can still play a local view of your video by cloning the track.
I need to develop a custom WebRTC peer (I need to establish audio or/and data connection between web-browser and non-browser). I however, struggle to find a proper, clear description of the handshake phase.
Answers to questions such as How to create data channel in WebRTC peer connection? are not entirely helpful, as they are not too detailed. Specifically, they say nothing about SDP contents.
Can anyone explain this or recommend any good documentation?
Here is a page with some graphs showing how the signaling process works. Basically, you set some client side stuff first:
PeerConnectionFactory; to generate PeerConnections,
PeerConnection; one for every connection to another peer you want (usually 1),
MediaStream; to hook up the audio and video from your client device.
Then you generate an SDP offer
peerConnection.createOffer();
on the caller side and send it to the callee. The callee sets this offer
peerConnection.setRemoteDescription(insert-the-offer-here);
and generates an SDP answer
peerConnection.createAnswer();
and sends it back to the caller. The caller receives this answer and sets it.
peerConnection.setRemoteDescription(insert-the-answer-here);
Both the caller and callee get a call to
onAddStream() {...} //needs to be implemented in your code
The callee when the caller's offer is set and the caller when the callee's answer is set. This callback signals the beginning of the connection.
You can also use ICE (STUN/TURN) to avoid firewall and NAT issues, but this is optional. Although in production code, you probably want to implement it anyway.
Note: Webrtc documentation is scarce and subject to change, take everything you read about webrtc (at least anything written as of now) with a grain of salt...
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.
I'm setting up some higher end security systems for a client. I'm using blue iris (his request) which has alot of great options for alerting you via cell phone or POTS telephone call. Unfortunately the building is 100% VoIP with no POTS and the camera server is in that building. I want it to ring a house number via a Automated VOIP call when an event is triggered in blue Iris then play a pre-recorded message.
We have a couple of Asterisk/Elastix PBXes in the company. I'm not sure how to proceeded:
Blus iris event triggered, it sends message/request/alert to a extension on the PBX
PBX makes the automated call to the group of numbers whenever that extension is dialed/contacted/triggered/etc.
I'd use an external script file (PHP, Ruby, BASH) to generate your call request on the PBX. See my answer at [
Asterisk AGI - Originate a call using php agi
] for more details. However, what you're doing is entirely possible, as I do it myself for a couple of different solution sets.
Essentially, and most easily, you'd generate a call file via script and within it ensure you have a couple of channel variables set that are keys for specific routing. When the call connects at the far end, the near end goes into a dialplan on the ASTPBX where exactly what message is played, after-message behaviour, etc, is managed by the channel variables you've set.
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.