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.
Related
Using frameworks : React/NodeJs
I'm trying to play video streams from a video source provider that having good security. I'm handling all data and communication from my server side and sending required data for client running on browser.
there is a special request that need to execute from client side. that will enable client's ip address allowed for streaming from streaming server.
If I send this special request from my server then, the streaming server allowing only for my server ip address. So client will get '403 (Forbidden)' error when streaming on his browser.
I need a way to do this somehow. So my questions are,
1) Is there any way to send that request from client's browser (Failed because of CORS). I don't need the response. but need to send request to streaming server by client's real IP address?.
2) If I handle that request from my server side is there any way to set the requesting IP address to fake(client's) IP?(Don't need get the response)
Thanks for any idea
An IP address can not be forged in Node. Maybe there are specialists who can do it at the kernel level of the system, but it seems to me that I have mistaken IP with MAC.
You will have to do streaming through your servers.
There is such a windows application that communications with the server through https protocol, it is an auction tool and works only several hours per month. I have captured network packets (by windows network monitor) during one auction.
I am wondering whether it is possible to mimic this client, by analyzing the the packets I collected (or any packets I could collect in future auctions). I know from this wireshark artical "Secure Socket Layer (SSL)" that it should be possible (and without much effort) to descypt the entrypted messages from server, but how? And is it possible to dectrypt the messages sent by client to server, too?
So the whole reasoning behind SSL is that third party listeners who are trying to receive and decrypt packets between your client and the server won't be able to do so. The packets that your clients send will be encrypted and the server will need the appropriate key to decrypt the message which you could then analyze using wireshark. This article does a good job of explaining how HTTPS works. To answer your questions:
Is it possible to mimic the client of a https web service
Yep, this is available in a lot of different tools. A popular tool you could implement this with is called Jmeter. This article explains how you can send HTTPS requests to your server. Once you exchange the key pairs between your client (JMeter in this case) you will be able to decrypt messages on both ends which have been sent in an encrypted format over the wire.
Please let me know if you have any questions!
In an SDP message, the "Origin" ('o') attribute is defined as:
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
Where <unicast-address> has the following definition:
is the address of the machine from which the session was created.
However, I'm unclear on whether this should be the IP of the client, or the RTP server. For example, if the client is running VLC on IP 1.1.1.1, and the RTP server is serving media from 2.2.2.2, should the <unicast-address> be set to 1.1.1.1, or 2.2.2.2?
I take it to mean the machine which creates the session and actually generates the SDP message, i.e. not the RTP server (the address of the RTP endpoints are defined elsewhere in the message). That's how I've always implemented it in the past.
The unicast address is of the server thats creating the RTP session. Usually it carries the IP address but for reasons of obfuscation the IP can be switched to FQDN or even something relatively obscure that for purposes of debugging can only be understood by the application developers.
It doesn't have any significance w.r.t to SDP / RTP processing.
I want to remote dial from my pc using a simple non SIP client program which I wrote and wchich sends commands to a proprietary SIP client that accepts remote commands via a TCP connection. The proprietary SIP client will then dial the remote party using my PC's IP and port number in SDP for RTP. Is this possible in principle? Are there any opensource clients available that use this concept? Is there any documentation (IETF RFCs, blogs etc) that is available.
Appreciate any help in this matter.
Check out pjsip, it's an open-source cross-platform SIP client for all major platforms and with API in C and an API wrapper for python, whichever you prefer. There are also examples on their site. Link your TCP parsing code to pjsip and call its functions to initiate a call, you can find how to do it on their site
If I understand correctly, here is what you want to do:
TCP SIP/SDP/RTP
PC <===> SIP client <===========> softswitch
Actually, TCP between PC and SIP client will probably be accurate for signalling but not for media as RTP media stream is often sent over UDP.
In my opinion, the first step is to make sure that your softswitch will accept sending RTP packets to an IP address which is not the same as SIP client (I think most of them refuse for security reasons). If it accepts and if you have no NAT between your SIP client and your PC, you should be able to send RTP stream directly to your PC. In this case, you have to retrieve RTP packets, eventually rearrange them, decompress their payload and feed them to your speakers.
If your softswitch does not want to send RTP packets to an IP address different from SIP IP address, then you have to forward your RTP packets from your SIP client to your PC. But if you can't modify your SIP client to do this (and it's probably the case as it's a proprietary software), you're probably stuck.
To test whether your softswitch accepts sending RTP packets to an unintended IP address, you can use sipp and specify a remote media ip address different from SIP signalling IP address.
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).