Re: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, November 9, 2012))

Hi Dan,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Dan Wing [mailto:dwing@cisco.com] 
>Envoyé : vendredi 30 novembre 2012 00:42
>À : BOUCADAIR Mohamed OLNC/OLN; 'Reinaldo Penno (repenno)'; 
>pcp@ietf.org
>Objet : RE: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, 
>November 9, 2012))
>
>> -----Original Message-----
>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
>> mohamed.boucadair@orange.com
>> Sent: Wednesday, November 28, 2012 11:18 PM
>> To: Reinaldo Penno (repenno); pcp@ietf.org
>> Subject: [pcp] PCP for RTP/RTCP (was RE: PCP MoM (FRIDAY, November 9,
>> 2012))
>> 
>> Dear all,
>> 
>> Below some answers for the questions raised for this draft.
>> 
>> 
>> >-----Message d'origine-----
>> >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De 
>la part de
>> >Reinaldo Penno (repenno) Envoyé : lundi 26 novembre 2012 15:36 À :
>> >pcp@ietf.org Objet : [pcp] PCP MoM (FRIDAY, November 9, 2012)
>> >
>> >FRI 1120-1330 (note new end time) =================================
>> >
>> >
>> >Reserving N and N+1 Ports with PCP: Preserving Parity & Contiguity
>> >draft-boucadair-pcp-rtp-rtcp                          (10, Jaqueline
>> >Queiroz)
>> >
>> >Stuart Cheshire: This seems wrong for PCP to take on additional
>> >responsibility for the sake of a single legacy protocol
>> >
>> >Dan Wing: We should ask the SIP WG what they think.
>> 
>> Med: The procedure is not specific to SIP/SDP, it is even 
>valid for non-
>> sdp protocols. Are you suggesting we send a message to mmusic WG for
>> instance?
>
>The port adjacency is (was) a need of RTP (RFC1889, RFC3550) which
>is now owned by AVTCORE.  
>
>A survey of endpoints that support a=rtcp (RFC3605) or send their RTP
>and RTCP over the same port (as being pursued by RTCWEB) would be
>valuable. 

Med: I checked https://www.sipit.net/SIPit29_summary and seems there is no data for a=rtcp attribute. Real SIP deployments I'm aware of does not make use of this atribute. This is why we mentioned in the draft the following:

   [RFC3605] defines an explicit "a=RTCP" SDP attribute for some
   applications using a distinct port than RTP+1.  Even though [RFC3605]
   defines a new attribute for explicitly specifying the RTCP attribute
   for the SDP based applications, but since it is not a MUST to use
   this attribute, there are still applications that are not compliant
   with this RFC.  

 The question comes down to:  does the industry still need
>port adjacency, or by the time PCP standardizes this functionality
>and it gets deployed will it be relevant any more?

Med: One of the major SIP-based deployment in Europe relies on a SIP agent in the CPE + The CPE is beining controlled by the same provider. Integrating this option does require change only at the CPE side; no change is required at the service side. This option is more for legacy deplopyments.

  It will take a
>couple of years.

Med: Perhpas, but this option is IMHO trivial. Integrating it to an existing SIP UA is simple + there are already existing PCP servers which handle this option. All what we need is an official codepoint.

PCP-base says:

   Additional PCP Option codes in the ranges 4-63 and 128-191 can be
   created via Standards Action [RFC5226], the ranges 64-95 and 192-223
   are for Specification Required [RFC5226] 

Why it is an issue to assign a codepoint in the 192-223 range for this option? 

>
>> >Stuart Cheshire: NAT-PMP and IGD don't do this today, so how
>> >"essential"
>> >can it
>> >be?
>> 
>> Med: Is this really a reason to not do it for PCP?
>
>It does demonstrate that there seems little _requirement_ for
>this functionality - or else it would have been implemented
>or been a must-have requirement.  That is, there are some sort
>of workaround/workarounds the industry is currently using today.
>
>
>> >How do even/odd SIP devices work today? Why is it
>> >"essential" that PCP
>> >give
>> >them something new, which they currently manage without?
>> 
>> Med: What we are proposing in this draft is very very simple.
>>
>> If this
>> option is not supported, we will continue with current 
>practices (which
>> have many drawbacks):
>> 
>> * enable an ALG in the NAT (I'm more concerned about the CGN case)
>> * or enabled some mechanism in the service side (e.g., SBC, Proxy
>> Server)
>>
>> The proposed PCP option allows
>> 
>> * to remove any service-specific ALG handling RTP/RTCP traversal from
>> the CGN/NAT
>> * Simplify the service access point (e.g., SBC): no need for 
>hosted nat
>> traversal
>
>Would SBCs be de-installed if this feature is added to PCP?
>
>> * For the SIP case, there is even no need to use symmetric SIP,
>> Symmetric RTP, etc.
>> * No issue with unidirectional media sessions
>
>Those benefits are beyond what was presented at the PCP meeting.  They
>are pretty interesting / valuable.
>
>Can the SIP and/or AVTCORE working groups help convince PCP that this
>is necessary / helpful / useful?
>
>-d
>
>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>
>