Forgive me if I'am asking the wrong question. Recently I am trying to analyze some voip traffic in Wireshark. But all I could see are small UDP packets; some containing RTP streams and I can see various codec information like G.711, G.723 etc. But there is no sign of SIP or any other signaling packets. Is it possible to hide SIP or H323 signalling within UDP packets in a way which are undetectable to Wireshark? or STUN can do some encoding to hide signalling packets?
No. By default Wireshark captures SIP in standard ports, and you probably are using some other port.
You can to Edit > Preferences... > Protocols > SIP and check the ports that are being used to identify SIP traffic.
Another way to force it to parse the packets as SIP, is to create a filter by the protocol and port being used (e.g. udp.port == 5060 || tcp.port == 5060) and then select a packet, and go to Analyze > Decode as... > Transport > SIP.
Wanted to share similar experience.
Wireshark was not showing some SIP packets. I was very sure these packets were sent. I discovered something unusual with wireshark displays. It will group many packets within a single packet. This is typical if you have busy traffic. You to check each packet
Wireshark SIP Protocol Analysis,Replaying Captured VoIP Calls,Playing VoIP calls, use your filter to filer the SIP and RTP protocol, if the column is missing go to edit->Preferences->Select Column->Add column Protocol
Yes. "But there is no sign of SIP or any other signaling packets." You can encode number inside RTP packets (RTP events) using DTMF. Then SIP is only used in initial authorization, then you only use DTMF in RTP, see RFC 2833. Also there is an option to encode DTMF in Audio (in-band), but this is not "standard". SIP Info packet (third method) should be the preferred method though.
Related
I am testing a setup with one sip client (tested with sipp and a softphone) and an IMS server that auto answers (so it is a two way RTP-communication between those 2 network elements).
In RTCP, must both the two entities communicating in such a scenario send RTCP packets? I am asking that because when i use the sipphone, it sends some RTCP packets at first and then the server answers, whereas the sipp scenario doesn't send rtcp packets at all and gets no response from that protocol. Also, all the ports for RTP+RTCP are open both in the router and in the testing machine.
Can an IMS server be configured to send RTCP packets (one direction only) on an RTP flow?
Does it say anywhere in the RTCP Protocol, that a client has to send RTCP paskets to receive such packets from the server?
You need to negotiate ports for RTP and RTCP first using SIP and SDP before those messages can be sent, so if the server doesn't respond with any SIP message then something else is wrong. Please check all the IP addresses in the outgoing INVITE from SIPP.
So verify it.
As per the rtp rfc and others.
Rtcp ports are algortimthiclly chosen most times on an odd port And most times 1 after the rtp port..
just because something sends you a packet doesn't mean you have to respond.
You should be filtering packets anyways because a source could be mixing rtp and rtcp together.
I am developing STUN for VoIP behind NAT(SIP protocol)..
I have a couple of routers for use..I find that the routers are changing the SIP messages(SDP and contact field)for NAT traversal...If I disable SIP ALG in routers,then NO SIP packets are forwarded..Is there any setting so that the Routers don't put any SIP intelligence and just forward the packets and not change the sip packet.
Thanks and regards
Buy a new router. Seriously, any NAT existing in 2013 that is still trying to translate application protocols (other than FTP) and modifying message contents (beyond the IP header) should be thrown out.
Is your SIP traffic sent over TCP or UDP? Is there a SIP gateway involved? Or are you trying to do a SIP INVITE between two endpoints without a signaling server?
In any case.... the standard solution to this problem is that the SIP messages should be sent over TLS/SSL (encrypted) to the SIP gateway. Your router won't be able to interpret these messages and will just treat them as a standard TCP traffic.
If you code for both endpoints, a simpler fix is to simply base64 encode your messages
I have a network set up with 2 UACs behind a NAT (one is Jitsi and the other is my own UA coded in C with SIP support). Asterisk is set up on a public IP.
In sip.conf I have the following for both UACs: nat=yes directmedia=no
I then execute my code which calls the Jitsi client. I answer via Jitsi and everything seems great.
Asterisk provides each UAC an RTP host/port to send video to via an SDP packet which I've parsed appropriately (audio is not included in this session). Each user agent begins transmitting RTP packets.
Here's where the problem occurs:
Asterisks starts printing out
"Got RTP packet from XX.XXX.XX.XXX:XXXXX (type XX, seq XXXXX, ts XXXXXx, len XXXXXX)"
repeatedly from both UACs but never actually sends any of the RTP packets anywhere (I would expect "Send RTP ....").
I've tested my H264 RTP code through a QuickTime Broadcasting Server and the packets properly decode on the local network through various media players. My SIP call seems to have no problems connecting and Asterisk never prints out any Warnings or Errors in the console.
I cannot for the life of me figure out why Asterisk is not forwarding the RTP packets. Any help would be appreciated.
First, Asterisk doesn't "hold onto" RTP packets. There are three ways in which two SIP UAs can be bridged:
Local bridge - the RTP traffic flows through Asterisk, but is not interpreted by Asterisk. In this case, each UA directs its RTP to Asterisk, and Asterisk retransmits the RTP to each UA. A minimal amount of decoding is done.
Remote bridge - in this case, signalling is still handled between each UA and Asterisk, but Asterisk renegotiates the destination of the RTP with each UA to be the other corresponding UA. In the end, each UA sends its RTP to the other UA directly, while sending the SIP signalling information to Asterisk. This minimizes the load on Asterisk, as no RTP traffic directly goes through it.
Native bridge - similar to a local bridge, the RTP traffic from a UA flows into Asterisk. Asterisk fully decodes the RTP into audio frames and manages the transmission of the audio frames. This occurs when Asterisk has to "understand" the contents of the RTP traffic, such as when using features.conf for DTMF transfers.
The directmedia setting informs Asterisk that the UAs optimally want to send their media between each other, and bypass Asterisk. It will attempt to send the necessary re-INVITEs to set that scenario up, once the call has been established by both UAs.
Since you have directmedia enabled for both of your UAs, Asterisk will attempt to place them in a remote bridge. It may not succeed, depending on a number of factors, but in general, it will expect that it is not "in the loop" with respect to RTP being sent back and forth between the UAs. This would explain why it isn't forwarding the RTP traffic it receives from one of its UAs.
I would suspect, since Jitsi handles this setting well, that the UA you wrote is not honoring the new destination IP address in the SDP of the re-INVITE Asterisk sent to it, and is instead continuing to send the RTP to Asterisk when it should instead be sending it directly to the Jitsi UA.
It seems I needed to use STUN in order to find my public IP address.
I switched from Asterisk to FreeSWITCH. Though this did not solve my problem, I found FreeSWITCH much easier to configure and debug which helped in my search.
Turns out that neither FreeSWITCH nor Asterisk really care what IP address you provide them during a SIP session, they'll simply use the IP address/port that a packet is received on (via the IP header) for communication. This confused me because I could make a call between 2 UACs but after a call was answered the audio/video media would never arrive at the correct destination. Turns out RTP implementations will use the IP address provided in the SDP message when setting up a media stream, regardless of what IP address SIP was using for its communication.
In the end, I used STUN to discover the public IP/port for the calling UAC and inserted this correct IP/port combo into the SDP message. Subsequently when the answering UAC (Jitsi) set up its media stream it now had the correct IP/port combo to send/receive media from.
I'm trying to find a way for client to know socket server ip:port, without explicitly defining it. Generally I have a socket server running on portable device that's connect to network over DHCP (via WiFi), and ideally clients should be able to find it automaticaly.
So I guess a question is whether socket server can somehow broadcast it's address over local network? I think UPnP can do this, but I'd rather not get into it.
I'm quite sure that this question was asked on Stack lot's of times, but I could find proper keywords to search for it.
One method of doing this is via UDP broadcast packets. See beej's guide if you're using BSD sockets. And here is Microsoft's version of the same.
Assuming all the clients of the application are on the same side of a router then a broadcast address of 255.255.255.255 (or ff02::1 for IPv6) should be more than adequate.
Multicast is another option, but if this is a LAN-only thing I don't think that's necessary.
Suggestion
Pick a UDP port number (say for the sake of an example we pick 1667). The client should listen to UDP messages on 255.255.255.255:1667 (or whatever the equivalent is. e.g.: IPEndPoint(IPAddress.Any, 1667)). The server should broadcast messages on the same address.
Format Suggestion
UDP Packet: First four bytes as a magic number, next four bytes an IPv4 address (and you might want to add other things like a server name).
The magic number is just in case there is a collision with another application using the same port. Check both the length of the packet and the magic number.
Server would broadcast the packet at something like 30 second time intervals. (Alternatively you could have the server send a response only when a client sends a request via broadcast.)
Some options are:
DNS-SD (which seems to translate to "Apple Bonjour"): it has libraries on macOS, but it needs to install the Bonjour service on Windows. I don't know the Linux situation for this. So, it's multi-platform but you need external libraries.
UDP broadcast or multicast
Some other fancy things like Ethernet broadcast, raw sockets, ...
For your case (clients on a WiFi network), a UDP broadcast packet would suffice, it's multi-platform, and not too difficult to implement from the ground up.
Choosing this option, the two main algorithms are:
The server(s) send an "announce" broadcast packet, with clients listening to the broadcast address. Once clients receive the "announce" packet, they know about the server address. Now they can send UDP packets to the server (which will discover their addresses for sending a reply), or connect using TCP.
The client(s) send a "discover" broadcast packet, with the server(s) listening to the broadcast address. Once the server(s) receive the "discover" packet, it can reply directly to it with an "announce" UDP packet.
One or the other could be better for your application, it depends.
Please consider these arguments:
Servers usually listen to requests and send replies
A server that sends regular "announce" broadcast packets over a WiFi network, for a client that may arrive or not, wastes the network bandwidth, while a client knows exactly when it needs to poll for available servers, and stop once it's done.
As a mix of the two options, a server could send a "gratuitous announce" broadcast packet once it comes up, and then it can listen for "discover" broadcast requests from clients, replying directly to one of them using a regular UDP packet.
From here, the client can proceed as needed: send direct requests with UDP to the server, connect to a TCP address:port provided in the "announce" packet, ...
(this is the scheme I used in an application I am working on)
I am capturing network packets of Gtalk using Microsoft Network Monitor. Very often I see small sessions of communication where a packet with TCP payload of 37 is sent by me to dst port 5222 and I receive an ACK for it. I can't see the contents of this packet because it is encrypted using TLS. Gtalk uses XMPP protocol. Any experts know what does this small session represent? Is it part of protocol specifications? Is there any way I can see the contents of this packet?
Is this being sent periodically, like every 30s, 1m, etc? If so, it's likely one space character, after it's been (potentially compressed then) encrypted. Many XMPP endpoints will do this to keep the socket open in the face of the large number of odd middleboxes that assume that if you haven't sent data in a while, the socket is dead.