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).
Related
I've successfully set up Asterisk on my server using the res_pjsip Hello World configuration from their wiki, and I want to be able to forward the RTP data to a Node.JS app, which can interpret RTP. I've heard about directmedia and directrtpsetup (see this stackoverflow) but I'm not sure if that's what I want. So my question is this:
Should I use directmedia / directrtpsetup to send voice data to my Node.JS app, or should I use some sort of Asterisk functionality to forward RTP packets? If the latter, how can Asterisk forward just the voice data?
I can clarify if needed, but hopefully this is more specific than my last questions. Thanks!
UPDATE: Having poked around Asterisk docs and messing with Wireshark, I think I have two options.
Figure out if there's a channel driver for Asterisk that just sends RTP, without any signaling, or
Capture the RTP stream with Wireshark or something and send the packets to the Node.JS app, and inject the return packets into the RTP stream.
Asterisk is PBX. It not suitable to "redirect rtp data"
No, there are no reason in having channel driver "without signalling". For what anyone can use it? How to determine call started if "no signaling"? It will be useless.
You can write such app in c/c++ or use other soft designed to be traffic capture: libpcap, tcpdump etc.
You also can use audio staff: libalsa, jack.
Best option however will be create or find full featured sip client and use it.
I have done a few captures with wireshark on my computer, and I see ARP messages, which are think they are coming form the the VoIP phone, which is connected to the computer(USB cable). I think they should not be there, but I wonder how I can capture and indentify VoIP traffic in my computer.
I have typed the following filters but I see none:
sip.CSeq.method eq INVITE
sip.Request-Line contains INVITE
Try to capture the traffic from the USB. See https://wiki.wireshark.org/CaptureSetup/USB how to setup such a capture.
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.
We are trying to build a SIP2RTSP gateway for one of our solutions, Where in one of SIP invite is converted to RTSP SETUP request to wowza media Server and then a PlayBack is played from the mediaServer to SipClient.
But when the setup request is sent the wowza is always binding to rtsp client address even though the destination is set in transport of SETUP request header. Here we want to tell the wowza rtsp server to bind to sip UA IP and not the rtsp client ip for the flow of RTP traffic.
RFC 2326 says
destination:
The address to which a stream will be sent. The client may
specify the multicast address with the destination parameter.
To avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD
authenticate the client and SHOULD log such attempts before
allowing the client to direct a media stream to an address not
chosen by the server. This is particularly important if RTSP
commands are issued via UDP, but implementations cannot rely
on TCP as reliable means of client identification by itself. A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
here it also tells A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
What is the use of destination field and how we can direct the media streams other than the RTSP client?
The point is that client MAY request the stream to be sent at client-chosen location. Still server should be doing this carefully, and take decision whether to allow an address which is different from RTSP client address or not using security consideration such as authentication availability etc. Because sending stream blindly to any given address, esp. via UDP, is unsafe: a malicious client might easily bring server down.
All in all, destination is where to send stream to. Servers do not guarantee that streams will be sent to locations other than RTSP client's.
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.