Subject: Re: [dispatch] PCP for SIP Deployments

From: <[email-masked]>
Date: Mon, 2 Mar 2015 16:26:07 +0000

Hi Partha,

Many thanks for the review and the comments.

I integrated almost all your suggestion, except the one about the ICE discussion. The reason for that is ICE is not deployed in the managed context; as such I'm afraid there is no value in having such discussion in the I-D.

Please check the diff and let me know if you have further comments.

URL:            http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.txt

Status:         https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/

Htmlized:       http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04

Diff:           http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-sip-ipv6-04

Thank you.

Cheers,
Med

De : Parthasarathi R [mailto:[email-masked]]
Envoyé : vendredi 27 février 2015 23:47
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [dispatch] PCP for SIP Deployments

Hi Med,

It is a interesting draft. The current writing provides PCP advantages in SIP managed network and particularly cellular. The following information has to be added to provide more clarity about this work:

1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP server

2)      Basic callflow to show how the dialog is established in case P2P is used

3)      The draft title mentions IPv6. My understanding is that this shall be used for IPv4 network as well.

4)      Add more details about how SIP, PCP, ICE interworking happens as the current reference is related to PCP with rtcweb only.

5)      Security implication w.r.t SIP usage of PCP has to be mentioned.

6)      Advantage of using PCP over TURN in SIP network shall be provided in the introduction section for better comparison.

Regards
Partha

From: dispatch [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, February 26, 2015 3:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dispatch] PCP for SIP Deployments

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<http://tools.ietf.org/html/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<http://tools.ietf.org/html/rfc4961>].

   o  Not require symmetric SIP to work (i.e., rport [RFC3581<http://tools.ietf.org/html/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

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 5 Mar 2015 05:51:24 +0530

Hi Med,

Thanks for incorporating the comments. 

ICE is used in the context of SIP over WebSocket (RFC 7118) & WebRTC SDP
profile within managed networks. TURN has its own limitation in traversing
NAT/FW using UDP transport in case of managed networks. PCP server in NAT
&FW resolves these issues. Of course, the current implementations (WebRTC
devices) have challenges in using ICE + PCP but IMO, it is good have for
future works.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 02, 2015 9:56 PM
To: Parthasarathi R; [email-masked]
Subject: RE: [dispatch] PCP for SIP Deployments

Hi Partha,

I integrated almost all your suggestion, except the one about the ICE
discussion. The reason for that is ICE is not deployed in the managed
context; as such I’m afraid there is no value in having such discussion in
the I-D. 

URL:
<http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.txt>
http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.txt

Status:
<https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/>
https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/

Htmlized:
<http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04>
http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04

Diff:
<http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-sip-ipv6-04>
http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-sip-ipv6-04

Thank you.

Cheers,

Med

Hi Med,

It is a interesting draft. The current writing provides PCP advantages in
SIP managed network and particularly cellular. The following information has
to be added to provide more clarity about this work:

1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client,
PCP server

2)      Basic callflow to show how the dialog is established in case P2P is
used

3)      The draft title mentions IPv6. My understanding is that this shall
be used for IPv4 network as well.

4)      Add more details about how SIP, PCP, ICE interworking happens as the
current reference is related to PCP with rtcweb only.

6)      Advantage of using PCP over TURN in SIP network shall be provided in
the introduction section for better comparison.

Regards

Partha

From: dispatch [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, February 26, 2015 3:02 PM
To: [email-masked]
Subject: [dispatch] PCP for SIP Deployments

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:

   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., [
<http://tools.ietf.org/html/rfc7362> 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 [
<http://tools.ietf.org/html/rfc4961> RFC4961].
   o  Not require symmetric SIP to work (i.e., rport [
<http://tools.ietf.org/html/rfc3581> 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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 Mar 2015 08:34:59 -0600

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, [email-masked] wrote:
> 
> Hi all,
>  
>    o  Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to
>    o  Work without requiring symmetric RTP/RTCP [RFC4961].
>    o  Not require symmetric SIP to work (i.e., rport [RFC3581]).
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 11 Mar 2015 06:19:36 +0530

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:[email-masked]] On Behalf Of Cullen
> Jennings
> Sent: Monday, March 09, 2015 8:05 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> 
> 
> 
> > 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:
> > 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

---

From: <[email-masked]>
Date: Wed, 11 Mar 2015 07:05:31 +0000

Dear Cullen,

Thank you for the comment. 

I agree with you it is more robust to use PCP along with other mechanisms for the generic case. In such case, PCP offer other functionalities that are not listed in this I-D, e.g., NAT detect. 

I also agree that if the SIP UA does not use the PCP response to build its messages, then relying on rport and outbound will be needed even if PCP is used to instantiate the requested mappings. What we are suggesting in this draft is that we can disable those features if the SIP UA relies on the returned external IP Address, external port number, the pair(s) of ports that preserve parity to build an offer/answer.

We had this text in the I-D: 

   In deployments where ICE [RFC5245] is required, PCP can be of great
   help as discussed in [I-D.penno-rtcweb-pcp] for the WebRTC case.  ICE
   can be used in the context of SIP over WebSocket [RFC7118] and WebRTC
   when deployed within managed networks.  Because TURN suffers from
   limitations in traversing NAT and firewalls over UDP, PCP is a
   promising solution that can complement ICE in those deployment
   contexts to soften the experienced high failure rate [ICEFailure].

The point is that this draft was initially scoped to cover the very specific case of SIP service delivery in managed networks. In those networks, PCP proxies and/or IGD/PCP Inetworking functions can be enabled if needed and justified. E.g.,
* Deliver SIP service to a DS-Lite serviced customer: there is only one level of NAT that is in the network side. The CPE does not include any NAT. The SIP endpoint can be embedded in the CPE itself or be located behind.  
* Access to an IPv4 SIP service platform via a NAT64: Only one level of NAT will be experienced. This is more for the ongoing IPv6-only deployments in mobile networks. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Cullen Jennings [mailto:[email-masked]]
> Envoyé : lundi 9 mars 2015 15:35
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : Re: [dispatch] PCP for SIP Deployments
> 
> 
> 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.
> 
> 
> 
> 
> > 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: