support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 19 2008 at 4:48pm | IP Logged
|
|
|
Hi Alex,
Its good that you have identified/detected the SipReceivedRtpMediaConflict event. Its an important event to process. It will allow SIP call endpoints that are behind NAT routers or firewalls to communicate with your VOIP server without media related errors. One of our other customers not too long ago also needed this capability.
When your application receives the SipReceivedRtpMediaConflict immediate event, the media engine is asking your application for help. The event tells your application that the media engine is receiving call media from a different IP:port than what was negotiated in the SIP. If your app processes this event, it can tell the media engine to use the “media detected” IP address and port of where the “real” far end media is coming from. By doing so, far end call endpoints will not have problems exchanging media with your IVR server even if the call endpoints are behind nasty symmetrical NATs.
WARNING:
If a VOIP app wants to process this event, it can (and it should). However, to prevent media hijacking by some other RTP endpoint or hacker attack, the VOIP app should expect to see this event upon first media arrival from the TRUE far end call endpoint. This will occur on average within the first 500Ms to 1000Ms of the call once the call enters the SipInCall state. VOIP applications should ignore the SipReceivedRtpMediaConflict media engine event if it occurs after this “average” amount of time.
To ensure to a higher degree the trustworthiness of where the TRUE media is coming from, the VOIP application can also verify that the call media type in the RTP header of the RECEIVED_RTP_MEDIA_CONFLICT object is the same media type as that used by the SIP call setup.
The application can go even further to verify the trustworthiness of the TRUE media endpoint by comparing the NegotiatedFarEndMediaIpAddress and the DetectedFarEndMediaIpAddress IP addresses as reported in the RECEIVED_RTP_MEDIA_CONFLICT object. If they are the same, the application has a higher degree of certainty that the TRUE media endpoint is the real media endpoint as negotiated via SIP. If the IP addresses are the same, the far end call endpoint at least knows its public IP address (via STUN or similar protocol) and has published it in the call’s SIP.
If applications need to defend against denial-of-service type attacks, the VOIP application should maintain a “timed cache” of all IP:port addresses of where SipReceivedRtpMediaConflict errors are coming from. If the VOIP app detects that media conflicts are continually coming from the same IPport address, this may be an indication of a denial-of-service hacker attack against the VOIP server.
You >>>
Exactly how do we deal with this situation?
<<< Support
Dealing with this event is simple. When your app gets the SipReceivedRtpMediaConflict immediate event, it will get data in a VoipMediaEngine.RECEIVED_RTP_MEDIA_CONFLICT object. To ensure that the media conflict is handled, assign the “detected” IP address and port to the “New” IP address and port in the object. That’s it. The code below shows this:
Code:
case VoipMediaEngine.TELEPHONY_RETURN_VALUE.SipReceivedRtpMediaConflict:
{
// RTP packets are coming from a different IP:port than what
// was negotiated for the call.
//
VoipMediaEngine.RECEIVED_RTP_MEDIA_CONFLICT ReceivedRtpMediaConflict;
// access the event data.
ReceivedRtpMediaConflict = (VoipMediaEngine.RECEIVED_RTP_MEDIA_CONFLICT)EventData;
// just allow the media to flow.
ReceivedRtpMediaConflict.NewFarEndMediaIpAddress = ReceivedRtpMediaConflict.DetectedFarEndMediaIpAddress;
ReceivedRtpMediaConflict.NewFarEndMediaPort = ReceivedRtpMediaConflict.DetectedFarEndMediaPort;
}
break;
|
|
|
As we noted above however, you can take additional steps to ensure the media conflict is not a hacker attack.
We will update the Developer's Reference to make this more clear.
Support
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Receiving SipReceivedRtpMediaConflict
