Subject: [AVT] RTP streams Collisions

From: "Yuval Nissan" <[email-masked]>
Date: Tue, 2 Jan 2007 11:01:47 +0200

Hi,

We have encountered many times in the field the following scenario:

Few voice RTP streams are receiving in the same UDP port - only one of
them is the actual session, and the other exist because of troubles in
the network (for example there was a session before on the same port,
and the other side didn't close the stream). 

It is also important to mention that the sessions in our case are mainly
unicast.

Now, I don't think there is good way in the standards today that gives
simple answer which is the right stream (for all the different network
architectures).

SRTP for example can solve this issue, but of course it is overkill
solution. 

One suggestion that was raised by Ed in the past that can help in most
of the cases: 

http://www1.ietf.org/mail-archive/web/mmusic/current/msg01516.html

Please advice.

Yuval

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Jan 2007 11:58:33 +0000

On 2 Jan 2007, at 09:01, Yuval Nissan wrote:
> Few voice RTP streams are receiving in the same UDP port - only one  
> of them is the actual session, and the other exist because of  
> troubles in the network (for example there was a session before on  
> the same port, and the other side didn’t close the stream).
>
>
> It is also important to mention that the sessions in our case are  
> mainly unicast.
>
>
> Now, I don’t think there is good way in the standards today that  
> gives simple answer which is the right stream (for all the  
> different network architectures).
>
> One suggestion that was raised by Ed in the past that can help in  
> most of the cases:
>

Won't ICE solve this, along with similar issues due to forking?

Colin

---

From: Randell Jesup <[email-masked]>
Date: Tue, 02 Jan 2007 09:23:44 -0500

Colin Perkins <[email-masked]> writes:
>> and the other side didn’t close the stream).
>>

[Yuval suggests signalling the SSRC]

>Won't ICE solve this, along with similar issues due to forking?

ICE certainly may solve it, though the complexity of deploying ICE is
*several* orders of magnitude larger than signalling an SSRC, especially
for a unicast stream.  But when will ICE be universally (or close to)
deployed?  Will it ever be?  (Perhaps, but can we say that for sure now?)
Will it be used in all non-VoIP situations?

I strongly suspect that Yuval is looking at this from a practical aspect of
a UA that reuses ports (typical to ease NAT/firewall configurations) which
can get spoofed by RTP traffic arriving from an already-terminated session
(as per his example).  He wants to know how to determine if the incoming
RTP packets are from the current session or not.  Without SRTP with auth
(again, as he said, overkill, though it works) you can't currently tell -
even the source IP doesn't help if an SBC or NAT is involved, or if the
session is to the same IP as the last session.  (Using SRTP also kills any
use of early media, unless you go to receive-keys.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Stephen Casner <[email-masked]>
Date: Tue, 2 Jan 2007 09:58:33 -0800 (PST)

> simple answer which is the right stream (for all the different network

It is the CNAME in RTCP that is intended to provide the binding of the
SSRC identifier to a meaninful identifier for the endpoint.

For unicast sessions, RTCP timing rules are more flexible, so you can
handle the startup.

                                                        -- Steve

---

From: Randell Jesup <[email-masked]>
Date: Tue, 02 Jan 2007 17:04:48 -0500

>SSRC identifier to a meaninful identifier for the endpoint.

CNAME is not tied to the session negotiation in any useful way.  It's
useful for determining if a source changed SSRCs, and it's useful for
determining if two SSRCs are from the same source.  The "user@host" or
"host" values are a) not guaranteed unique, b) do not vary from one
session to the next, c) may in fact have serious duplication, such as due
to simple implementation on dedicated devices, especially if they
include a NAT-ed IP address as a bare host address, d) as per above,
there's no way to say that "[email-masked]" is the "correct" cname for a stream.

>For unicast sessions, RTCP timing rules are more flexible, so you can

e) RTCP doesn't always work (it can be blocked), some clients never
   transmit it, some mis-implement it, and it could be 5-10 seconds if
   you're unlucky after a session start before you receive it.  Waiting for
   RTCP to play media is even worse that blocking early media....