my sip provider doesn't support some SIP headers that I need to send to my IP Phones. I can specify my own headers, but my provider add some prefix in front of them everytime.
I need to send Call-info header to my phone. But my provider adds something like X-PH- prefix so my IP phone doesn't understand that modified header.
I need to create some sort of middleware which I'll have between IP phone and Provider's server in my network. Is there any proxy / middleware that I can use?
I would recommend putting a Session Border Controller [Sonus, Dialogic etc] with "Header Manipulation Rules" Capabilities. Other options are using Opensips / Kamailio to make the header manipulations, but it has a learning curve for the way the rules are defined and of course the pain of putting it together in the network.
BTW, since you are specifically looking for RFC compliant SIP Headers [Call_info], you can always push for it with the carrier you are dealing with. Get them to comply to the SIP Specs. Maybe they see merit pushing their vendors for compliance.
Related
I want to send SMS from AngularJS web application using Ozeki sms gateway. Can anyone tell me how to do this? pr suggest me some reference link or code sample.
Plain sending
Assume we skipping other protocols available inside Ozeki Sms NG product (like SMPP, Email, DB etc), and getting to HTTP protocol only, you can go this way:
Prerequisites:
Figure out best way for you to make HTTP request to send SMS
(I'm not AngJS guy so may be there are already few ways to make HTTP-request from Angular, but at least any Ajax method passing params to executing PHP-script for making HTTP request (with curl, file_get_contents) will be totally Ok).
Make sure your Ozeki SMS server is reacheable via IP/domainname etc by your PHP-script so your code can reach its endpoint.
Doing it:
Inside Ozeki install service provider like HTTP Client
http://www.ozekisms.com/index.php?owpn=195&info=service-provider-connections/http-client-connection
or HTTP Server (more powerful version of HTTP Client allowing call back URLs)
http://www.ozekisms.com/index.php?owpn=197&info=service-provider-connections/http-server-connection
Then according (to docs) execute request like
http://server_ip:9501/api?action=sendmessage&username=________&password=________&originatior=__________________&recipient=__________________&messagetype=SMS:TEXT&messagedata=______________
*Some fields are not necessary, it may vary depending on Ozeki version you use.
** port 9501 - is a default Ozeki HTTP port which may be changed in general settings, also it has HTTPS port as well. Basically the correct port is the same which you already use when accessing Ozeki Web GUI.
After executing sending request (try from browser or from something like Postman first) you should get responce in XML format informing you about result of your transaction.
Possible next step... DLRs
Getting delivery reports (if supported by your operator) is a common "i want it too" question.
In case you need them - there is great embedded feature inside "HTTP Server" connector (mentioned above).
Here you can see more details
http://www.ozekisms.com/index.php?owpn=431
"reporturl" - is a field you may use to set kind of "call back url". In other words in this optional field you may specify full URL and list fields to be passed along. So you only have to create your own endpoint to catch them (as GET request from Ozeki server) and use inside your software.
Does Google Universal Analytics support x-forwarded-for header for ip filters?
I am trying to filter out internal ips but it doesn't seem to work. The application is sitting behind a proxy, so the client's ip is in the x-forwarded header.
According to this question the measurement protocol (which forms the base for all versions of the Google Analytics tracking) ignores x-forwarded ip headers.
This is solved in serverside implementations as Google has added a parameter uip (must be a valid IP, will always be anonymized by setting the last three numbers to 000) to the measurement protocol to send a clients ip. I don't know terribly much about proxy servers, but it might be possible to stitch the parameter into the request instead of using a header field.
I haven't actually tested this solution yet, but I'm working on it.
It seems like you should be able to do something like this:
import ua from 'universal-analytics'
import publicIp from 'public-ip'
const user = ua(GOOGLE_ANALYTICS_ID)
const uip = await publicIp.v4()
user.set('uip', uip)
After that, you have set the users IP for all coming events and page views.
I'm working with a sysadmin that uses a Juniper solution that behaves as a proxy. I have no idea what it is, but here's a picture of the web interface: http://imagebin.ca/v/1UKN1jGYPUWd
Through that proxy, I'm trying to use Sharepoint's REST API, unfortunately there are some headers (such as X-RequestDigest) that Juniper's proxy doesn't forward to Sharepoint.
Basically, I need the equivalent of nginx's proxy_pass_request_headers for Junipers' applications.
The sysadmin doesn't seem to know what HTTP header forwarding is, or how to configure it. Can anyone identify the solution he's using from the picture ? Does anyone know where to find documentation about this ?
Further to my comment added above, there appears to be no way to implicitly pass variables around. You can tell the current IVEOS images that the Web URL you're linking to is a Sharepoint Site, and it'll do "clever" things with the URL, but I'm not exactly sure what you want it to do, and whether they'll handle it.
Here are the screen shots for the "Sharepoint" configuration panels on the Web Resources page. As I'm not a Sharepoint Admin, I can't tell you whether these are useful to you or not.
I hope it helps!
You may be looking for the Web Resource custom header policy
https://www.juniper.net/documentation/en_US/sa8.0/topics/task/operational/secure-access-web-rewrite-custom-header-policy.html
Edit: The first resource became a dead link. New link: https://www.juniper.net/techpubs/en_US/nsm2012.2/topics/task/configuration/remote-management-secure-web-resource-policy-configuring-nsm.html
Fur custom headers (to send some user information) we've used the "Web Rewriting Resource Policy"
SSO Cookies/Headers > General tab -> Headers and Values
to pass custom user data (user name, role, client certificate).
I assume you have the backend application (sharepoint) configured as the a PTP (PassthroughProxy) we bresource. I am pretty confident that only standard HTTP headers are passed to the backend by default :(
To pass all custom headers I found following book (Juniper(r) Networks Secure Access SSL VPN Configuration Guide): https://books.google.be/books?id=5OYf6u5vzFsC&pg=PA369&lpg=PA369&dq=Juniper+pass+custom+headers&source=bl&ots=s5oF5NEKjP&sig=8091EV2Pyw6pIFQifMOIR2pLpLk&hl=de&sa=X&ved=0ahUKEwiFwpf6m_DOAhWFWRQKHXoRD0EQ6AEIPDAE
where it says
Passing custom headers can be enabled by:
Users > Resource Polities > Web > Custom Headers
This option may not be visible on the admin interface by default, it needs to be enabled:
Users > Resource Policy > Web > Web ACL and there's a "Customize" button
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
I'm trying to secure the channel between my socket.io client and the node.js side. The main web application is in Drupal so I can't pass the cookies to node.js if node.js is on another host. I'd like to add some custom headers to he Socket.io HTTP handshake (like the PHP session).
Do you know if it is possible?
Using Socket.io 0.7
P.S: I am just brainstorming here a little bit. I like this problem and am going to think a little bit more about this. I only thought about it yet from node.js same domain only...
Github issue
I don't know(don't think so) if it is possible to add headers.
P.S: I think you should also try to fill issue at https://github.com/LearnBoost/socket.io/issues. The nice thing about github is that author will receive an email when somebody posts an issue. Also the people at learnboost are really nice people who like to help you out.
Proxy
Proxy all your request so that request come from same domain.
Refererer
The refererer is passed so you can pass information from this. This can also be spoofed so you better create something you can validate(only once) from Drupal. I guess this would be pretty easy to implement...
only allow message-flowing after verification.
What I know you can do is disconnect sockets via socket.disconnect(). Open connection and retrieve socket.io's id, but only accept messages after identity has been approved. I would make a route available via express which Drupal can curl post socket.io's id to to (keep route private). Because you are inside Drupal's domain you can access Drupal's session information.
// v0.7.x
var sid = socket.id;
To make this secure the only option is to use SSL(that is the only way you can make any communication link secure anyway). If you trust both domain's SSL is probably not really necessary. Then if socket.io's id is allowed you will allow message-flowing else I would just disconnect the connection.
PusherApp
Another option would be to implement/clone pusherapp authentication => http://pusher.com/docs/client_api_guide/client_channels#subscribe-private-channels
P.S: I will to try and upload an example later, but for now it is time for me sleep. Hopefully this made any sense :)...