Re: [dispatch] PCP for SIP Deployments

Hi Cullen,

In case of PCP+ICE for media (RTP), adding one candidate will serve the
purpose as the ICE connectivity check will ensure whether the port is
reachable or not. There is no need of extra mechanism.  Correct?

Regards
Partha

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen
> Jennings
> Sent: Monday, March 09, 2015 8:05 PM
> To: mohamed.boucadair@orange.com
> Cc: dispatch@ietf.org
> Subject: 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
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch