FreeSWITCH Version: 1.10.3
I was hoping that someone maybe able to help me.
Intermittently on inbound calls from the our sip provider we are sending a empty RTP packet back to the provider. After doing some investigation, it happens when FreeSWITCH receives RTCP from another FreeSWITCH instance.
<SIP Provider> <----> <FreeSWITCH 1> <----> <FreeSWITCH 2>
FreeSWITCH 1 receives an inbound call from an external caller and is acting as a B2BUA in front of FreeSWITCH 2. Once the call is answered by FreeSWITCH 2 the RTP streams are setup and work in both directions.
FreeSWITCH 2 sends all the RTP packets to FreeSWITCH 1 but FreeSWITCH 1 is sending a RTP packet with an empty payload to the SIP provider, on either side of this empty RTP packet there is RTP with the MARKER bit set.
Adjusting the below RTCP timers on FreeSWITCH 2 affects the frequency of the problem on FreeSWITCH 1.
<!-- enable rtcp on every channel also can be done per leg basis
with rtcp_audio_interval_msec variable set to passthru to pass
it across a call -->
<param name="rtcp-audio-interval-msec" value="5000"/>
<param name="rtcp-video-interval-msec" value="5000"/>
Honestly, I am having a real hard time wrapping my head around why this is happening and only for incoming calls, I am not sure if this is bug or if haven't set something correctly.
If anyone is able to help or point me in the right direction that would be amazing?
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'm writing simple SIP-proxy application which stands between Astreisk and SIP client (any softphone). The purpose of the application is to calculate the duration of the call.
Below is example of regular flow:
Client sends INVITE to SIP-Proxy, SIP-Proxy resends INVITE to Asterisk
Asterisk answers with 200 OK, SIP-Proxy resends 200 OK to client.
Client answers with ACK, SIP-Proxy resends ACK to Asterisk
Whenever one of the parties sends BYE, conversation should be finished.
On step 2 I assumes that call is started (e.g. rtp media flow is started). Then I wait for BYE message to calculate duration of the call. However I noticed that some clients never goes to step 3 and 4. No call end notification received from any parties after step 2. And duration of such call is infinitely.
What is the best way to find out start/stop time of the SIP call without sniffing RTP flow ? Should I wait for step 3 to mark the start of the call ? What if client omit ACK or what if UDP datagram with ACK is missed in the network ?
For now I used to think there is no reliable way to figure out that SIP call is started. Maybe I should use Astrisk channels API instead to track active calls.
Another option is to generate a RE-INVITE to test the existence of the Session. Dont have to negotiate a timer or anything. Just using re-invite could help. Reuse the SDP to ensure that no media changes happen. But then your application is moving out of being a Proxy in the path of the call to being a application server.
Also the duration can only be capped to nearest interval for this re-invite request and not necessarily the exact time the call was released.
Your problem seems to be at SIP level, because your proxy does not add itself into the message path using a Route header. This process is called Record Routing. If doing so, all subsequent requests in your dialog will also traverse it (ACKs and BYEs included).
You should not reinvent the wheel by writing a SIP proxy. For example, you could use a open-source, flexible, powerful and completely customizable SIP Proxy in order to build any possible scenario you could think of: OpenSIPS!
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.
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.
UDP doesnot sends any ack back, but will it send any response?
I have set up client server UDP program. If I give client to send data to non existent server then will client receive any response?
My assumption is as;
Client -->Broadcast server address (ARP)
Server --> Reply to client with its mac address(ARP)
Client sends data to server (UDP)
In any case Client will only receive ARP response. If server exists or not it will not get any UDP response?
Client is using sendto function to send data. We can get error information after sendto call.
So my question is how this info is available when client doesn't get any response.
Error code can be get from WSAGetLastError.
I tried to send data to non existent host and sendto call succeeded . As per documentation it should fail with return value SOCKET_ERROR.
Any thoughts??
You can never receive an error, or notice for a UDP packet that did not reach destination.
The sendto call didn't fail. The datagram was sent to the destination.
The recipient of the datagram or some router on the way to it might return an error response (host unreachable, port unreachable, TTL exceeded). But the sendto call will be history by the time your system receives it. Some operating systems do provide a way to find out this occurred, often with a getsockopt call. But since you can't rely on getting an error reply anyway since it depends on network conditions you have no control over, it's generally best to ignore it.
Sensible protocols layered on top of UDP use replies. If you don't get a reply, then either the other end didn't get your datagram or the reply didn't make it back to you.
"UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information."
The machine to which you're sending packets may reply with an ICMP UDP port unreachable message.
The UDP protocol is implemented on top of IP. You send UDP packets to hosts identified by IP addresses, not MAC addresses.
And as pointed out, UDP itself will not send a reply, you will have to add code to do that yourself. Then you will have to add code to expect the reply, and take the proper action if the response is lost (typically resend on a timer, until you decide the other end is "dead"), and so on.
If you need reliable UDP as in ordering or verification such that TCP/IP will give you take a look at RUDP or Reliable UDP. Sometimes you do need verification but a mixture of UDP and TCP can be held up on the TCP reliability causing a bottleneck.
For most large scale MMO's for isntance UDP and Reliablity UDP are the means of communication and reliability. All RUDP does is add a smaller portion of TCP/IP to validate and order certain messages but not all.
A common game development networking library is Raknet which has this built in.
RUDP
http://www.javvin.com/protocolRUDP.html
An example of RUDP using Raknet and Python
http://pyraknet.slowchop.com/