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

On 11/29/12 6:41 PM, "Dan Wing (dwing)" <dwing@cisco.com> wrote:

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

It has been several years since a=rtcp has been defined and in the live
deployments that we have
seen, it is rarely used. I don¹t see that rapidly changing in the next
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.

Do we know what that workaround is? That can be helpful.

Thanks
Senthil
>
>
>> >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
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp