Re: [dispatch] PCP for SIP Deployments

I read the draft and it seems like one of the issues is that you don't know if the PCP nat is the only nat or firewall in path. So it seems like a more robust solutions is to use PCP along with existing solutions. So for SIP, one does the PCP to get a port but still relies on things like rport and outbound to correctly set the return address (IE use the PCP to open a pin whole but still use private address in contact). Similarly with the RTP use PCP to get a address on the outside of the NAT but just add that in as one of the ICE candidates. 

> On Feb 26, 2015, at 2:31 AM, mohamed.boucadair@orange.com wrote:
> 
> Hi all,
>  
> I would like to share with this group a short document that explains how PCP can be of great use in the context SIP-based services:
> http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03
>  
> As indicated in the I-D, the main benefits include (but not limited to):
>  
>    o  Avoid embedding an ALG in the middleboxes.  Note, ALGs are not
>       recommended since the evolution of the service would depend on the
>       ALG maintenance.
>    o  Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to
>       be embedded in the SIP server.  Intermediate NATs and firewalls
>       are transparent to the SIP service platform.
>    o  Avoid overloading the network with keepalive message to maintain
>       the mapping in intermediate middleboxes.
>    o  Work without requiring symmetric RTP/RTCP [RFC4961].
>    o  Not require symmetric SIP to work (i.e., rport [RFC3581]).
>    o  Easily support unidirectional sessions.
>  
> When this document was first presented in the PCP WG, I was suggested that it is better to publish it in RAI with a review from the PCP WG. Hence, this message to the list. 
>  
> Cheers,
> Med
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch