I'm not super familiar with VOIP.. I've been doing some research but have had a difficult time finding an answer to this question.
What I need to do, is check to make sure a phone is being forwarded to a specific number. I'm trying to determine if there is a way to do this by placing a call to it. Looking at rfc 3261, it seems the VIA header would contain the info I need if a forwarding phone just acts as a proxy, but it seems this is unlikely to work, judging from the line:
Each proxy uses the Via header field to
determine where to send the response and removes its own address from
the top.
Is it possible to tell if a call was forwarded to a specific number, simply by placing a call to it and monitoring the headers? If so, could I simply download a VOIP app, and snoop the packets with WireShark? Or will I need to create my own VOIP client?
You can use the SIP history-info header, see rfc4244 for details.
Related
I am not overly technically savy so I am asking the community if this can be done.
I am using ONSIP.com as a hosted PBX solution. ( Its easy and I like their interface.
What I would like to do is use their "bridge function" to have Twilio be the source for my SIP numbers.
I think this can be done because ONSIP describes how I can get an international number from DIDWW>com and have it "pointed" into to my system. So I thought, why not have Twilio supply me with numbers, local and international.
The real question I have though is can I make calls out on that SIP number, going through ONSIP.com to start the call but have Twilio actually make the call , (if that makes sense)
ONSIP.com charges 2.9/minute in or out bound and it appears as though Twilio is on 1/minute. so it would seem to make sense to do this if it can be done?
Here is their info on an inbound bridge
http://www.junctionnetworks.com/knowledgebase/onsip/admin-portal/apps/inbound-bridge
Thanks for any advice or input you might have on this subject.
What you need to find out is if OnSIP and Twilio both support SIP transfers.
To have a call you've started on OnSIP's server "moved" to Twilio it will require the use of SIP REFER requests, which are how call transfers are done in the SIP World. Without a transfer it means your call would end up going through both OnSIP's and Twilio's server and mean you end up incurring both sets of charges.
I suspect you'll find one or both of them don't support transfers since such functionality can be tricky for a SIP provider to implement and it's also it's not going to be in the originating provider's interests, in this case OnSIP, to provide you with a way of avoiding their call charges.
Perhaps an easier way for you would be to get an IP Phone or ATA that has two or more SIP lines and connect the first line to OnSIP for incoming calls and the second line to Twilio for outgoing calls.
For anyone who finds this now, Twilio does not support Sip Refer at the time of this post
I am still learning about SIP and all its protocols, specifically trying to integrate PJSIP into an iPhone application to make p2p calls.
I have a question about a peer 2 peer connection using PJSUA. I am able to
make calls perfectly to other clients on my local network by calling directly using the URI:
sip:192...*:5060
I am curious if this will work for
making direct calls to other SIP URIs that are not on the local
network without using server configuration - if not this way, is there another way of making p2p calls without server configuration?
thanks in advance,
You can make calls without server configuration, as a general principle, but something needs configuring. As mattjgalloway points out in the comments below your question, the most robust solution is a can of worms involving ICE which provides a kind of "umbrella" protocol for things like STUN.
Last time I touched this issue, I had the requirement that I couldn't use internet-based SIP servers to help. I came up with the idea of a registry of sorts: your client can define a bunch of "address spaces" with particular routing requirements. For SIP URIs in your LAN, you define no routing; for URIs in your company's VPN-accessed network, you define a route passing through your VPN connection; for everything else you define a route through your internet router.
By "define a route", I mean that when you place a call to a URI in some particular address space, you store what IP will go into a Contact header, what Route headers you might need, and so on.
Thus, the process of making a call becomes:
Look up in the set of address spaces for a match.
Ask that address space for the suitable bits needed to make a workable INVITE (appropriate Contact header details, Route headers, etc.)
Construct a normal INVITE, mutating as necessary for the previous step.
Send the INVITE as normal.
This essentially reproduces half of what ICE would give you, in a manually administrated form. "Half", because this ensures that one SIP agent can make calls such that the SIP routing all works. The missing half is you still need some kind of registrar somewhere, and each agent in your contact list needs to have the necessary setup to receive incoming calls. (If an agent's behind a NATting internet router, the router would need to either run a SIP proxy, or forward ports 5060, 5061 to a particular machine (which might be an agent, or a proxy serving the LAN's agents).
It is, indeed, a large can of worms.
The basic issue is to solve the problem of getting transport ports anywhere on the internet for multimedia traffic.
Many companies/experts have tried to solve this situation. A possible way out of is to buy a domain and setup a basic registrar using YATE or Asterisk on an address accessible from the internet and configure it to also use ICE as needed. Your iphone application at both ends could register automatically to it upon start. Then make P2P calls.
Here is my problem. I do distributed calling with 10-15 Asterisk boxes. They each have a different IP address. My provider wants me to use IP based authentication, which can be a pain (the IP's change on a frequent basis).
I was thinking of setting up one Asterisk box to relay calls from all the others. That way I'd just need to set up the SIP trunk to the provider on this one box/IP.
Can anyone tell me anything special I would need to do to set this up - either in the dial plan or otherwise? I do not want all the media to run through the central box, I merely want it to set up the calls and allow the other boxes to talk directly to the provider once the call is set up.
Thanks in advance for any suggestions.
I believe a sip proxy like openser/kamailio or opensips would fit in best here. You could set the proxy up to relay all of the sip signalling to your cluster of asterisk boxes.
Here's an example for doing this with Kamailio.
Also:
I do not want all the media to run through the central box, I merely want it to set up the calls and allow the other boxes to talk directly to the provider once the call is set up.
Make sure that's groovy with your provider. A lot of ITSPs expect to signal and send media to pre-defined IP addresses. Generally they're talking to an SBC, which is expected to anchor the media and send it elsewhere..
how can we programmatically implement, call forwarding?
I have done some google search, but have not found any good solution.
For reference, i have gone through this web page
CLick here
Suggestions are always appreciated.
I see this thread is a little old, but I’ll give you my 2 cents worth which might help you out when it comes to call forwarding.
I’ve recently released an app Ridlee+ on the Kuwait app store it has a call forwarding feature implemented and I faced the same issues you all are having.
So basically, the method described here using -[NSApplication openURL:] us correct, The problem is that apple will not allow you to pass * or # to the number programmatically, and as far as I know you need those in the dial number to interact with the call forwarding option on the telecom side. So the answer is “It’s not doable “
What I did is suggest to the telecom to create a link between the two, so I would pass call forwarding requests through TCP/IP or network connectivity to a webservice, and that system will take care of the internal config on the telecom side.
You will face issues requesting such a thing from the telecom since you get into User verification arguments, but if you implement your app correctly they would consider it. The way I did it, is have the User verified using a small reg process where the user will send a free SMS to the telecom, who will pass back to the webserver a verification code assigned to the user, the user will then enter this code in the app, which in turn verifies it with the web server, this 3 way handshake allows you to verify the user is the phone number owner. In turn allowing him to control his forwarding through the web service.
I hope this helps.
Have you tried sending the call forwarding character to the -[NSApplication openURL:] method?
A requirement for the SIP PBX I created for my company was to record all calls passing through it. I solved it by forcing all SIP message to pass through the PBX and to modify the SDP body so the stream passes through it and gets recorded. It works well.
I recently found out that this is not allowed.
Is there any other way to implement call recording and how "wrong" is this in regard to the protocol?
It sounds like you're describing a SIP proxy, more or less a Session Border Controller (SBC). A proxy can modify SDP, though it should be careful in doing so. Typically SBCs will set the media destination to themselves, and proxy the data to the destination. So this is perfectly legal spec-wise (assuming the devices are already coming to your server).
However, "Not allowed" could also mean "recording calls is legally not allowed", which varies a lot state-to-state.
A more conventional way to implement call recording would be to capture the RTP packets on the wire and put them together to create an audio file. There are quite a few tools around to do exactly that and it's even inbuilt into Wireshark.
As far as tweaking with the SDP goes it's definitely not something that is "not allowed" at least not on a technical level. A lot of SIP Proxy's are forced to mangle the IP addresses in SDP when user agents put private IP addresses in them. You'll find most SIP servers out there have some sort of capability in this regard and it's often call NAT mangling or similar.