Subject: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP : better guidance?

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 21 Aug 2007 18:50:11 +0200

All,

A comment on 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07

Section 3.2.1 symmetric RTP last paragraph currently reads:
"'Symmetric RTP' SHOULD only be used for traversal of RTP through NAT when 
one of the participants in a media session definitively knows that it is on 
the public network."

Isn't it possible to provide more accurate / concrete guidance? something 
like "an endpoint SHOULD NOT use 'Symmetric RTP' unless it can determine 
that the address received in the SDP offer/answer is not routable?"

Regards,
Jeroen 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Diego B <[email-masked]>
Date: Tue, 21 Aug 2007 20:37:40 +0300

Hi;
The problem is that sometimes a routable address on the SDP, for example 
discovered by a STUN query, is not actually the address to send RTP because
of symetric NATs etc.

Regards
Diego B

Jeroen van Bemmel wrote:
> "'Symmetric RTP' SHOULD only be used for traversal of RTP through NAT 
> when one of the participants in a media session definitively knows 
> that it is on the public network."
>  
> Isn't it possible to provide more accurate / concrete guidance? 
> something like "an endpoint SHOULD NOT use 'Symmetric RTP' unless it 
> can determine that the address received in the SDP offer/answer is not 
> routable?"
>  
> Regards,
> Jeroen
> ------------------------------------------------------------------------
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 21 Aug 2007 20:21:05 +0200

Diego,

It may be that an address does not work even though it is routable (so a 
"false positive"). However, I'm looking for wording that provides more 
concrete guidance on when to use symmetric RTP. "when one of the 
participants in a media session definitively knows that it is on the public 
network" is neither a sufficient nor a necessary condition.

For example, at home I have a NAT router (1) connected to a DSL line. My PC 
is connected to that, as well as a second NAT router (2) with wireless. A 
softclient running on my PC can exchange audio with a softclient on a 
wireless device, but it requires the softclient on the PC to use symmetric 
RTP (while the wireless client need not). NAT router 1 (192.168.1.x) has no 
route to the subnet (192.168.2.x) behind NAT router 2.

The PC client is not on the public network, yet it should use symmetric RTP 
because the address it receives in SDP ( 192.168.2.123 ) is not routable.
For the wireless client the address it receives ( 192.168.1.111 ) is 
routable. Neither have a simple way to check this though, I'm currently 
using a hack by assuming that gateways always have "x.x.x.1" as address on 
the private side, then the logic becomes:
"from.ip != sdp.ip && from.ip[3] != 0x01 ==> use symmetric RTP (i.e. send to 
from.ip:from.port)"

I haven't implemented RTCP yet, but one way of detecting routability could 
be to look for packet loss reports; 100% loss probably means 
non-routability.

Regards,
Jeroen

Diego B wrote:
> Hi;
> The problem is that sometimes a routable address on the SDP, for
> example discovered by a STUN query, is not actually the address to
> send RTP because of symetric NATs etc.
>
> Regards
> Diego B
>
> Jeroen van Bemmel wrote:
>> All,
>>
>> A comment on
>> can determine that the address received in the SDP offer/answer is
>> not routable?"
>>
>> Regards,
>> Jeroen

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 22 Aug 2007 09:07:24 +0300

> be to look for packet loss reports; 100% loss probably means

Or that the other endpoint has not implemented RTCP, such as one of your 
current implementation.

-- 
Rémi Denis-Courmont

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 22 Aug 2007 18:46:55 +0200

Rémi,

What I meant was: if the client receives a RTCP receiver report saying that 
there were no packets received, it could be an indication that there is a 
routing issue. Obviously this check would only work if the other side 
supports & sends RTCP, and such RTCP packets arrive

Regards,
Jeroen

Rémi Denis-Courmont wrote:
>> I haven't implemented RTCP yet, but one way of detecting routability
>> could be to look for packet loss reports; 100% loss probably means
>> non-routability.
>
> Or that the other endpoint has not implemented RTCP, such as one of
> your current implementation.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 23 Aug 2007 11:10:32 -0500

Actually, it's exactly the opposite of what we should do. 
 
We should say that Symmetric RTP SHOULD always be used.
 
We should point to RFC 4961 which states the following:

	There are no known cases where symmetric RTP or symmetric RTCP
are harmful.
	 
	For these reasons, it is RECOMMENDED that symmetric RTP and
symmetric RTCP always be used for bidirectional RTP media streams.

Cheers.

________________________________

	From: Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: Tuesday, August 21, 2007 09:50
	To: sipping
	Cc: [email-masked]; Gonzalo Camarillo
	Subject: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric
RTP : better guidance?

	All,
	 
	A comment on
	 
	Section 3.2.1 symmetric RTP last paragraph currently reads:
	"'Symmetric RTP' SHOULD only be used for traversal of RTP
through NAT when one of the participants in a media session definitively
knows that it is on the public network."
	 
	Isn't it possible to provide more accurate / concrete guidance?
something like "an endpoint SHOULD NOT use 'Symmetric RTP' unless it can
determine that the address received in the SDP offer/answer is not
routable?"
	 
	Regards,
	Jeroen

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 24 Aug 2007 09:07:16 +0300

> We should say that Symmetric RTP SHOULD always be used.

Yes, absolutely. I would even have gone for a MUST always be used.

In fact, the offerer will probably have to decide to use symmetric RTP before 
it knows anything about the answerer (since it needs to allocate a port 
number before formatting its SDP), so the only safe way is to always use 
symmetric RTP (and symmetric RTCP).

-- 
Rémi Denis-Courmont

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 24 Aug 2007 08:09:45 +0200

Francois,

I think there's two sides to this:
1) send/receive RTP using the same socket/port (and idem for RTCP)
2) "second guess" the IP address/port announced in SDP, assume the sender is 
doing (1) and send RTP/RTCP packets to a ip/port combination received in a 
RTP/RTCP packet

For (1) we should say: it is RECOMMENDED to do this
For (2) it is more tricky. For starters, it would be nice if the SDP carried 
some flag to indicate that (1) is the case (i.e. peer is doing symmetric 
RTP/RTCP). And then still we need to provide more guidance on when to do (2)

Regards,
Jeroen
  ----- Original Message ----- 
  From: Francois Audet
  To: Jeroen van Bemmel ; sipping ; [email-masked]
  Cc: [email-masked] ; Gonzalo Camarillo
  Sent: Thursday, August 23, 2007 6:10 PM
  Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP : 
better guidance?

  We should point to RFC 4961 which states the following:
    There are no known cases where symmetric RTP or symmetric RTCP are 
harmful.

    For these reasons, it is RECOMMENDED that symmetric RTP and symmetric 
RTCP always be used for bidirectional RTP media streams.
  Cheers.

----------------------------------------------------------------------------
    From: Jeroen van Bemmel [mailto:[email-masked]]
    Sent: Tuesday, August 21, 2007 09:50
    To: sipping
    Cc: [email-masked]; Gonzalo Camarillo
    Subject: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP : 
better guidance?

    All,

    A comment on 

    Section 3.2.1 symmetric RTP last paragraph currently reads:
    "'Symmetric RTP' SHOULD only be used for traversal of RTP through NAT 
when one of the participants in a media session definitively knows that it 
is on the public network."

    Regards,
    Jeroen

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Aug 2007 10:22:29 -0500

Ah.... I get it now.
 
Yes, I agree.
 
In fact, I'm not even sure we should even say anything about "second
guessing". We have a standards-based solution for this, and it's ICE. We
should probably stick to recommending that.
 
The fact that many devices (SBCs, etc) do second guess is just a fact of
life. We could mention that it happens, but I don't think we should
recommend doing it, or provide any guidance on when it is appropriate.
We should just say "some devices use tricks like using a media relay,
second guess the IP address and port based on symmetric RTP assumptions,
but our recommended approach is ICE.
 
My 2 cents.

	From: Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: Thursday, August 23, 2007 23:10
	To: Audet, Francois (SC100:3055); sipping; [email-masked]
	Cc: [email-masked]; Gonzalo Camarillo
	Subject: Re: [Sipping] sipping-nat-scenarios section 3.2.1
symmetric RTP : better guidance?

	Francois,
	 
	I think there's two sides to this:
	1) send/receive RTP using the same socket/port (and idem for
RTCP)
	2) "second guess" the IP address/port announced in SDP, assume
the sender is doing (1) and send RTP/RTCP packets to a ip/port
combination received in a RTP/RTCP packet
	 
	For (1) we should say: it is RECOMMENDED to do this
	For (2) it is more tricky. For starters, it would be nice if the
SDP carried some flag to indicate that (1) is the case (i.e. peer is
doing symmetric RTP/RTCP). And then still we need to provide more
guidance on when to do (2)
	 
	Regards,
	Jeroen

		----- Original Message ----- 
		From: Francois Audet <mailto:[email-masked]>  
		To: Jeroen van Bemmel <mailto:[email-masked]>  ;
sipping <mailto:[email-masked]>  ; [email-masked] 
		Cc: [email-masked] ; Gonzalo Camarillo
<mailto:[email-masked]>  
		Sent: Thursday, August 23, 2007 6:10 PM
		Subject: RE: [Sipping] sipping-nat-scenarios section
3.2.1 symmetric RTP : better guidance?

		Actually, it's exactly the opposite of what we should
do. 

			There are no known cases where symmetric RTP or
symmetric RTCP are harmful.
			 
			For these reasons, it is RECOMMENDED that
symmetric RTP and symmetric RTCP always be used for bidirectional RTP
media streams.

		Cheers.

			From: Jeroen van Bemmel
[mailto:[email-masked]] 
			Sent: Tuesday, August 21, 2007 09:50
			To: sipping
			Cc: [email-masked]; Gonzalo
Camarillo
			Subject: [Sipping] sipping-nat-scenarios section
3.2.1 symmetric RTP : better guidance?

			All,
			 
			A comment on
			 
			Section 3.2.1 symmetric RTP last paragraph
currently reads:
			"'Symmetric RTP' SHOULD only be used for
traversal of RTP through NAT when one of the participants in a media
session definitively knows that it is on the public network."
			 
			Isn't it possible to provide more accurate /
concrete guidance? something like "an endpoint SHOULD NOT use 'Symmetric
RTP' unless it can determine that the address received in the SDP
offer/answer is not routable?"
			 
			Regards,
			Jeroen