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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, November 29, 2012 10:40 PM
> To: Dan Wing; 'Reinaldo Penno (repenno)'; [e-mail]
> Subject: 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:[e-mail]] Envoyé : vendredi 30 novembre
> >2012 00:42 À : BOUCADAIR Mohamed OLNC/OLN; 'Reinaldo Penno (repenno)';
> >[e-mail] Objet : RE: [pcp] PCP for RTP/RTCP (was RE: PCP MoM
> >(FRIDAY, November 9, 2012))
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> >> [e-mail]
> >> Sent: Wednesday, November 28, 2012 11:18 PM
> >> To: Reinaldo Penno (repenno); [e-mail]
> >> 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 : [e-mail] [mailto:[e-mail]] De
> >la part de
> >> >Reinaldo Penno (repenno) Envoyé : lundi 26 novembre 2012 15:36 À :
> >> >[e-mail] 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.

Yeah, but I was hoping for more definitive information to help motivate
the PCP working group.

One other point in favor of your draft is that a=rtcp support is needed
on both the local and remote ends, and while a person can influence the
local end (install PCP client, PCP server, and your PCP extension), there
is effectively no influence of the remote end, where a=rtcp support is
also needed.

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

What does that network do, today?  I am guessing, but I expect that it
does latching (draft-ietf-mmusic-latching).  What problem exists on
that network today that would be solved by deploying PCP?  Are there
incentives in place to actually deploy the PCP solution and remove 
whatever RTCP solution is used today?

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

The complexity is that it continues a legacy of applications that 
rely on certain ports, when we know -- due to NAT64, NAT44, MAP (A+P),
and other IPv4 address sharing technologies -- that applications are
less and less likely to be able to acquire certain desired ports.  

That problem of acquiring a specific port was apparent a decade ago, 
when a=rtcp was published in 2003.

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

Code point assignment is done by IANA, not by the PCP working group.  
The specification required range exists for situations where a standard
is not possible or is not desired.  This may well be such a case, but
I know that I don't know enough about how and why this extension would
be used in the industry.

-d