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.  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?  It will take a
couple of years.

> >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