Video from alternate IP - how to confirm it?

Discussion related to the ITU-T Recommendation H.323
Post Reply
Posts: 2
Joined: Wed Mar 07, 2012 8:57 pm

Video from alternate IP - how to confirm it?

Post by mmagliaro » Wed Mar 07, 2012 9:05 pm

When an H.323 call sets up between two endpoints A, B, they exchange channel information
and A stats sending video to B at the address and port that B specified (in the HG.245 openLogicalChannelAck message, for example).

What if B wants to validate that the video is really coming from A? That is, B knows what
address it is in conference with. Let's say A is But it sends its
video to me from Some systems (most notably
recent-generation MCUs like the Polycom RMX or the ZTE systems) will send their video
from a second IP address, not the one that set up the call.

Suppose I am station B, and I see video coming at me from this other IP, and I want to make
sure it's not some rogue sending me improper video? Is there something in the H.245 message exchange that should have told me to expect the video to come from this other IP address? Is there a standard
for handling this, or allowing it? Or am I suppose to just ignore the sender's address and play
whatever video shows up on my port?

User avatar
Posts: 522
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA

Re: Video from alternate IP - how to confirm it?

Post by paulej » Thu Mar 08, 2012 5:34 am

There is nothing in the H.245 spec for that. The situation you describe is an artifact of using UDP for media transmission.

Now, if you detect packets coming from an IP address other than what was advertised in the OLC or OLCAck messages, you could treat those as suspect. Unless, that is, you're working through NAT/FW devices. (See H.460.23 and H.460.24 on that.)

Still, somebody could forge the IP address and port in bogus UDP packets.

The proper solution to address this problem is to use security, like SRTP or DTLS. In that way, media that is from a rogue endpoint would be detected as invalid and discarded.

Without a proper security solution, then you could get rogue packets. If you get an entire flow of valid-looking packets, it would be hard to detect without security in place. If you get a packet here and there, that could be detected and just discarded. If the call is in progress and you start receiving a new flow from a different IP address than the current flow, one of the two is invalid and you could just elect to ignore the newer flow. You could check the PT value, perform some basic sanity checks, etc. But, this is really just a security problem and no amount of "workaround" will truly address a security problem.

How much of this is an issue in reality? Hard to say. I've been working in voice/video over IP area for, ahem, 16 years now and I've never heard of this as being a problem. A lot has to do with use of VLANs and other means of controlling the network. Somebody would have to be in a position to "attack" in the way you describe (e.g., being in a position where one could inject bogus packets). What you describe could happen, but I've never heard of anybody doing this in practice.

I have heard of something related to this, though. There have been instances where people were using SIP and UDP for signaling and "rogue" entities would send a BYE message and cause the calls to drop. So, these kinds of things could certainly happen.

Posts: 2
Joined: Wed Mar 07, 2012 8:57 pm

Re: Video from alternate IP - how to confirm it?

Post by mmagliaro » Thu Mar 08, 2012 4:53 pm

Thank you Paul. I agree that without security or encryption, you never really have a secure video stream.
I just wanted to know if there was some message in H.245 that I was ignorantly overlooking.

On thing... the source address of the media changing due to NAT has not really been a problem.
Most H.323 systems I test for interop with our product change the embedded addresses in the H.245 messages
so they are the correct ones (either the endpoint itself does it, or they call through an "H.323 aware" firewall that does it. And endpoint can usually determine pretty easily if it's behind a NAT (or the user can enter that information manually), so it can "fix" the addresses.

Thank you for a prompt and thoughtful reply.

Post Reply