How to connect VOIP to PSTN? I have read a lot about VOIP to VOIP. But how is it possible to connect VOIP to PSTN? I have tried to search after this information on Google without success.
It depends on type of your PSTN lines. In short, for T1/E1 you can use big carrier-grade gateways, Cisco for example, and for 2-wire POTS lines you can use small phone adapters with FXS/FXO ports, such as Audiocodes or Linksys. They are SIP-based, so you will need to register them as SIP endpoints.
The interworking that you mention is generally performed on a SoftSwitch. These are any to any Signaling protocol conversion. So a very common scenario is what you referred to as VoIP to PSTN or vice versa. I am using SIP to ISUP as a example here.
Usually the PSTN side can be broken to Signaling Gateways and Media Gateways. While the Signaling GW converts the SIP Request / Response to equivalent Signaling message, the SDP is used to control the Media Gateway based on MEGACO or MGCP. For a normal SIP Call these shall be the conversion for the signaling message. Similar rules apply for H323 to PSTN conversion.
INVITE + SDP -> IAM 180 / 183 -> ACM / CPG 200 -> ANM / CON BYE -> REL
You can check RFC 3398 to check some of these SIP to PSTN conversion rules.
There was another mechanism ITU-Q.1912.5 where the entire ASN encoded ISUP Message body is carried as part of the MIME attachment of the SIP Message and then the message is extracted and sent to the SS7 network. This was part of IPX / GSX [Global Switching Exchange] where the messages across long hops shall be carried over VoIP and on its last mile be converted to equivalent ISUP Signaling.
Now if you are only interested in knowing how a SIP UA can be terminated on a Mobile phone you need to have a partnership with one of the VoIP carriers that provide ISUP Termination capabilities. But somewhere in there switching equipment they will be having mechanisms similar to what is explained above.
There are ATA devices that have a VOIP as well as a POTS port and can connect calls between them. Linksys SPA3102 is one such device. These things are extremely configurable and you can have them automatically answer voip calls and provide a PSTN dial tone or automatically call preset phone numbers.
Related
Let's say I use Jitsi to make VoIP conference calls using XMPP. What determines the security, is it a feature of the XMPP protocol itself or is it the account/server I am using (eg, www.jabber.org)? On the Jabber website they mention using SSL and TLS, would this be for VoIP?
What is the advantage of using ZRTP over just making a regular voice call through XMPP, assuming there is already some security with XMPP?
Is there a difference in using SIP vs. XMPP for voice calls, with or without ZRTP?
Thanks!
XMPP and SIP are known as "signalling protocols". They are designed to provide channels that allow two clients to communicate small packets of data with each other. SIP was designed primarily with just signalling as a goal, while XMPP was designed primarily with messaging and presence as a goal. Over time both have gradually extended into each others' realm though :)
However neither SIP nor XMPP technically carry the actual voice/video data. This is left up to other protocols, such as RTP, ZRTP, etc., which the clients use the signalling protocol to negotiate (e.g. they need to exchange IP addresses and port information, and keys for ZRTP).
This means that running your XMPP over SSL is essential for security, but it only protects the signalling part (the clients negotiating the media channel). The voice/video does not go over the XMPP channel, and must be separately protected, by using ZRTP.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
Can anyone please tell me if it is possible to publish the voice from an IP based telephone to a RTP based media server - like a Wowza Media Server or Flash Media Server?
Thanks
You probably need to give more info if you want a more specific answer, but a quick response is that yes it is possible.
If the IP phones is something you are building or can modify then you can simply send any outgoing RTP packets both to the other end of the call and the media server, and forward any received RTP packets to the media server.
If you are not able to modify the phone, then you may still be able to achieve what you are looking for by 'mirroring' the RTP packets that are sent to and received from the IP phone, to the RTP media server (see http://en.wikipedia.org/wiki/Port_mirroring for an overview of port mirroring, and www.audiocodes.com/filehandler.ashx?fileid=43289 for some specific discussion on 'tapping' phone calls).
Note, that you need to be aware of the law if this is to record or 'tap' live calls. Even if they are your own calls on your own phone, different countries have different laws about what can and cannot be recorded and what notification you have to give the parties involved in the call (this is why calls to call centers etc often start with a message that the call may be recorded for training or other purposes).
Is it possible to have a j2me app on a mobile to act as a "SMS gateway" that will handle incommming messages, do a query on a database via GPRS and reply the user back?
This is entirely possible on any J2ME handset that supports JSR 120 (i.e.: most of them). However as Wonil said, you can't just process ANY incoming SMS message. It has to be an SMS sent to a port number on which your app is listening (using a server connection as Wonil explained).
It wouldn't be automatic unless the app was signed (as confirmation is generally required for sending SMS and network access).
Another approach is to tether your phone to a PC using a USB cable/bluetooth/IR, open a serial connection using the phone as a modem, and write a program to listen for new SMSs using AT+CGML as described here. This would allow ANY incoming SMS to be processed (no port number required), and without any annoying confirmation prompts.
HTH
I think you should check about JSR-120 documentation to confirm.
But, in my thought it might be impossible. If you want to receive message by using JSR-120, you should assign specific end point(port number) to listen as like below:
serverConn = (MessageConnection)Connector.open("sms://:5000");
So, you can't catch all SMS messages. It can't be a gateway then.
It probably depends if your phone supports it. Have a look at the J2ME Wireless Messaging API:
The Wireless Messaging API (WMA) is an optional package for the Java 2
Platform, Mobile Edition (J2ME) that
provides platform-independent access
to wireless communication resources
like Short Message Service (SMS).
http://java.sun.com/products/wma/overview.html
This article has some examples which can probably serve as a starting point for what you want to achieve: http://www.ibm.com/developerworks/wireless/library/wi-extendj2me/
Edit: as others have pointed out, you might not be able to receive all messages.
Please let me know what architecture do VoIP applications use, P2P or Client-Server?
Thank you.
Some of each in general. There are three protocols involved, usually. One of them, for example SIP, is used to establish the connection. you need a server for that because someone has to establish the original connection; that means advertising availability and such. The other two are essentially always RTP and RTCP -- "real time protocol" and "real time control protocol", and those are better P2P, because you want fast transmission with no intermediate bottleneck.
There's a nice article on the whole discussion here.
There's usually some kind of "presense server": devices register ("I exist here!") and calls are established via the server (when you say "I want to connect to device (555) 555-1234" that connection request is routed via presence servers).
After the call is established and the real-time voice/media is streaming, that traffic is usually peer-to-peer (bypassing any central server), except if there's a complication like both devices being behind firewalls.