Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Subject Topic: Receiving SipReceivedRtpMediaConflict Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
ajdiaz
Junior
Junior


Joined: December 10 2007
Location: United States
Posts: 76
Posted: March 19 2008 at 3:12pm | IP Logged Quote ajdiaz

Hi Support,

Our application sometimes receives the SipReceivedRtpMediaConflict event, mostly seen when it is receiving a lot of inbound calls.

The documentation explains that this is happening when the MediaEngine is receiving RTP media packets from a call endpoint that is different from what was negotiated for the call. And that this event can be processed by the application to instruct the media engine on how to deal with this situation.

Exactly how do we deal with this situation? What procedures does the Media Engine provide to deal with this situation? Is there a way to re-negotiate or re-direct the media packets so that we do not lose data or the phone call?

Please help. Thanks.

-Alex

Back to Top View ajdiaz's Profile Search for other posts by ajdiaz
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: March 19 2008 at 4:48pm | IP Logged Quote support

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

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum






Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights