I have had trouble configuring inbound and outbound calls using FreePBX with SIP provider TWilio.
As it stands I cannot make external calls or receive calls from Twilio.
I have monitored TCP port 5060 and can see traffic routed to my address when I engage a call using my number provided through Twilio but from the FreePBX cli I observe the following when I see incoming traffic.
[#DATE] NOTICE[18449]: res_pjsip/pjsip_distributor.c:368
log_unidentified_request: Request from '' failed for '54.252.254.64:5060' (callid: 41822dbe439f067b0ef90f596b3998d2#0.0.0.0) - No matching endpoint found
I have searched the web already for similar issues but have yet to come across anything of use. As this is early testing I have put the system on a DMZ to avoid the NAT firewall.
Note: This is my first post to stack overflow so I may not be correctly following the layout for posting, I apologize in advance. Suggestions are welcome.
Thanks
This is likely a configuration error.
Check the setup guide. But also, I found from another user with the same error that they changed the following:
pj_sip was set to port 5060 instead of chan_sip
Let me know if this helps at all!
Related
Using the Smooch API, I am trying to obtain all of the messages sent to my Facebook appid in the past few minutes or hours.
The Get Messages REST method does exactly what I need, except for that it only returns messages from a particular appUserId. This isn't useful unless you already know what users have sent you messages. I cannot use a webhook as the application resides behind a corporate firewall. Opening the firewall to connections that originate from the outside is not an option (even with white-listing).
Is there a way to invoke the Get Messages REST method such that it will ignore the appUserId filter? Perhaps some sort of wildcard character?
GET {{url}}/{{apiVersion}}/apps/{{appId}}/appusers/{{appUserId}}/messages
Unfortunately you do need to have the appUserId (or userId) on hand in order to query user messages.
Webhooks are a pretty essential part of building a Smooch integration. If you can't receive them through your firewall, then you might consider building an intermediary service outside of your corporate network for receiving Smooch webhooks. For each webhook event you receive it would either:
Forward it through a secure tunnel into your coprorate network
Store the appUserId (or the whole event) in its own database, and provide a secure endpoint that allows your corporate network service to query that data
I'm curious to know more about your use case, e.g which Smooch channels are you integrating? With more details I might be able to improve this answer.
#alavers We would like to leverage nearly every messaging integration you offer.
#alavers You may want to consider providing a Get Messages variant that is better suited for use within a corporate firewall environment. An excellent example is the http long poll implementation provided by APIs such Amazon's SQS API. Their receiveMessage method waits for up to the specified time period but returns as soon as a message is received. This provides nearly the same performance of a webhook but eliminates the need for a customer to open their corporate firewall to connections that originate from outside the corporation. Most IT departments will approve connections that originate from within the corporation, but permitting connections that originate from the outside becomes a very difficult sell.
working on Twilio API on EC2 ubuntu server to respond incoming calls with a simple text message. the script seems to be running good at port #5000, configured port number at security groups too. The response is supposed to show at http://public-dns:5000 but it is not showing up ? any ideas how to fix this ? thoughts ?
Hi if anyone else ever needs help connecting an Avaya IP Office phone system with Twilio Elastic SIP trunking, feel free to reach out to me, we got it to work after some trial and error and the connection seems very good. Will save us some good money.
The final piece to the puzzle for us had to do with the IP address that Twilio sends SIP invites from for incoming calls to the Avaya system. To get this to work in the Avaya we had to set up 4 SIP "Lines" pointing to 4 different "ITSP IP Address" values and 4 "Incoming Call Routes" per DID because Twilio sends from 4 different domestic IP addresses. I did read some documentation about being able to leave the ITSP IP Address blank (0.0.0.0) since we do have the "ITSP Domain Name" populated but that does not seem to work in our situation.
In researching this on the Internet I surprisingly did not find much evidence of Avaya customers ever having to deal with this issue (with or without Twilio), however I did find some examples of some other PBX systems having this issue with connecting to Twilio but those systems seemed equipped to configure multiple IP addresses for a single line.
Thus my question - do any Avaya customers have a suggestion for an alternate configuration to make this work? Anything we could do on our firewall? Twilio does not support sending SIP Invites from a single IP address or via a proxy server address. Fortunately we only have about 10 DID's so this won't be that hard to setup and maintain.
Credit goes to zakabog at the Avaya support forum for answering this, who said:
"Setup the 4 different SIP lines but give the URIs the same incoming group ID, that'll let you use one incoming call route for each DID."
My reply:
"That sounds like a very good idea. I will try that and report back. You are referencing the "SIP URI" tab right that we'd point all 4 of them to line 19 even though we have setup a line 19, 21, 23 and 25, right?"
His reply:
"Exactly, there is the line number and then there's the incoming and outgoing ID, and those numbers don't need to match. So you can have everything share the same incoming or outgoing group ID, it helps keep the ARS and incoming call routes less cluttered."
And my final reply (it worked!):
"Yes that works like a charm. Much better, I don't mind setting up 4 SIP lines but wasn't thrilled about dup'ing the other stuff. Thank you thank you."
I received following question later on the Avaya forum:
"I do need help trying to get this up and running. The main issue is that we can not resolve the ITSP Domain Address field in the Line -> SIP Line -> "ITSP Domain Name" with {our-domain}.pstn.twilio.com
It would be REALLY interesting, step by step, how you would go about getting Twilio to work with 1 SIP trunk on Avaya Office."
My reply:
"Yes, this was my issue too. The way we have it working is by creating 4 SIP lines for each of the 4 Twilio domestic IP addresses (SIP Line tab), 54.172.60.0 through 54.172.60.3. And then using zakabog's suggestion we use only one of these line numbers on the "SIP URI" tab. This allows to only have to create 1 set of "Incoming Call Routes" pointing to that same "Line Group ID" as is shown for the "Incoming Group" and "Outgoing Group" on the "SIP URI" tab. Please note that these call routes will require the "+1" for the "Incoming Number", assuming these are US DID's. Feel free to send me a phone number or email address and I'd be glad to arrange a discussion with you or show you my screen."
You can actually put more than one IP address on the ITSP Proxy address. I did and put a weight to the server:
54.172.60.0w1,54.172.60.1w2,54.172.60.2w3,54.172.60.3w4
This would allow you to create one SIP Trunk line.
I know in airports, for example, I've connected to their AP, and it pops up a browser window to log in on my device. Is it possible to do so with NodeMCU in lua, or even with c firmware?
This can accomplished by setting the DNS server for a connecting client [via DHCP] to a sort of DNS proxy. It doesn't need to be a fully featured DNS server, it only needs to be able to either return a static DNS answer for any host name query or forward the request to a real DNS server, to resolve host names as usual.
The static answer effectively hijacks web requests at the DNS level, by forging the DNS answer, causing all host names to resolve to the IP address of a local web server. That local web server ignores any Uri details and serves a login prompt for every request. It must also maintain a list of client MAC addresses that have authenticated.
NodeMCU does have a built-in DHCP server, as part of it's built-in WiFi AP, but running both a web and a DNS proxy in ESP8266's limited memory would be a hell of a trick. I think that two of them working cooperatively, interfaced using the SPI bus might be workable... maybe even three of them, one dedicated to maintaining the list of authenticated MACs, expiring them, etc.
Note that the only part of this I have done on an ESP 8266 is some very simple web server functionality, so it's mostly theory. If you try it I'd be very interested in hearing about it. :-)
You might want to try out CaptiveIntraweb project (https://github.com/reischle/CaptiveIntraweb) which is based on NodeMCU.
There is also thread (http://www.esp8266.com/viewtopic.php?f=32&t=3618) on ESP8266 community forum that discusses the solution details.
I'm working with the API using HTTMultiParty and I'm having trouble capturing the outgoing HTTP requests when I make POSTs. I don't see them at all in wireshark. I am capturing on the wireless adapter (I have no other internet connection) and filtering on
http.host contains "docusign"
but I can't see anything come up. Even with just an HTTP filter, I see nothing new captured while I see a request and response. Why is wireshark unable to view the traffic from my rails app? Note: I can see the request made by my browser to the rails app.
Since it's https traffic, assuming you know the IP address of the server you're talking to, use the filter ip.addr == x.x.x.x and you should see TLS traffic leaving leaving your client.
I presume in the above comments that you mean "ip.dst" because there is no such thing as "tcp.dest" as far as I'm aware.
Slightly old but here's a complete list of filters.