From bruno.chatras@orange-ftgroup.com Wed Jun 1 01:27:21 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD29E074E for ; Wed, 1 Jun 2011 01:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P373ojiJT8UD for ; Wed, 1 Jun 2011 01:27:21 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 621ACE0718 for ; Wed, 1 Jun 2011 01:27:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 623D58B8040; Wed, 1 Jun 2011 10:28:00 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 49C178B8004; Wed, 1 Jun 2011 10:28:00 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 10:27:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2035.B83E467F" Date: Wed, 1 Jun 2011 10:27:18 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102EB815C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVAAAOHlwAFcgoEQ References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> From: To: , X-OriginalArrivalTime: 01 Jun 2011 08:27:19.0161 (UTC) FILETIME=[B8BC5E90:01CC2035] Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:27:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2035.B83E467F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No this is different. RFC 5128, =A7 3.4 describes a solution where both = endpoints simultaneously send SYN messages. There is no intermediate = network node converting SYN messages into SYN-ACK messages. Bruno =20 =20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 12:02 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 Bruno, looks like that you are describing "TCP hole punching" according RFC = 5128, =A7 3.4, right? That solution is in scope of H.248.NATTP2P ("In scope of this document = are NAT-T techniques according [IETF RFC 5128].") ... and RFC 5128 is about NATT for P2P. =20 =20 =20 =09 ________________________________ From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Mittwoch, 25. Mai 2011 11:44 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P =20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 My comments below inline, Albrecht =20 =09 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, =20 I have two questions about H.248.NATTP2P =20 1) The scope description suggests that this recommendation applies to = P2P networks. My understanding is that it also applies to any terminal = to terminal traffic within a managed network without application-level = intermediary. Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P = scenario. The draft does not yet provide a link to the applied P2P = definition in clause 3. More important in my opinion is the reference to = the considered e2e model by Fig. 1. Side question: what's the definition of an application-level = intermediary? Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an = application-level intermediary =20 2) What is the relation with TCP stitching?=20 [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP = stitching", guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple = interim H.248 IP-IP MGs, which lead to the requirement in assigning = different role behaviours to the MGs, whereas your referred proprietary = technology aims perhaps just a single NAT traversal entity in the bearer = path. But I don't know ... =20 [BC] My understanding of TCP stitching is that both endpoints initiate = a TCP connection towards the MG and the MG joins both connections = together. This requires the MG to convert TCP SYN on one side to = TCP-SYN-ACK on the other side, which means that the MGC has to request = the MG to perform that trick, presumably by setting a termination or = context property to a specific value. So, the purpose of my question was = to know whether this kind of mechanism was covered or will be covered by = H.248.NATTP2P =20 =20 Bruno =20 ------_=_NextPart_001_01CC2035.B83E467F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No this is different. RFC 5128, =A7 3.4 describes a solution where both = endpoints simultaneously send SYN messages. There is no intermediate network node converting SYN messages into SYN-ACK messages.

Bruno

 

 

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 12:02
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

Bruno,

looks like that you are describing "TCP hole = punching" according RFC 5128, =A7 3.4, right?

That solution is in scope of H.248.NATTP2P = ("In scope of this document are NAT-T techniques according = [IETF RFC 5128].")

... and RFC 5128 is about NATT for P2P.

 

 

 

From:= bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 25. Mai 2011 11:44
To: Schwarz, Albrecht (Albrecht); megaco@ietf.org
Subject: RE: H.248.NATTP2P

 

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

My comments below inline,

Albrecht

 

From:= megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 2011 13:34
To: megaco@ietf.org
Subject: [Megaco] H.248.NATTP2P

Hi,

 

I have two questions about = H.248.NATTP2P

 

1) The scope description = suggests that this recommendation applies to P2P networks. My understanding is that it also applies to any terminal to terminal traffic within a managed network = without application-level intermediary. Is that correct?
[[Schwarz, Albrecht]] Perhaps yes, because that might = be also a P2P scenario. The draft does not yet provide a link to the = applied P2P definition in clause 3. More important in my opinion is the = reference to the considered e2e model by Fig. 1.

Side question: what's the definition of an = application-level intermediary? Or what kind of specific functios do you have in = mind?

[BC] An MSRP relay for example is what I would call an application-level = intermediary

 

2) What is the relation with TCP = stitching?
[[Schwarz, Albrecht]] I'm not aware of any definition = for "TCP stitching", guess this is a marketing term used by a = particular vendor.

Thus, I may just speculate:

Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim H.248 IP-IP MGs, which lead to the requirement in assigning different role behaviours to the MGs, whereas your referred proprietary technology aims perhaps just a single NAT traversal = entity in the bearer path. But I don't know ...  

[BC] My understanding of TCP stitching is that both endpoints initiate a TCP = connection towards the MG and the MG joins both connections together. This requires = the MG to convert TCP SYN on one side to TCP-SYN-ACK on the other side, which = means that the MGC has to request the MG to perform that trick, presumably by = setting a termination or context property to a specific value. So, the purpose = of my question was to know whether this kind of mechanism was covered or will = be covered by H.248.NATTP2P

 

 

Bruno

 

------_=_NextPart_001_01CC2035.B83E467F-- From albrecht.schwarz@alcatel-lucent.com Wed Jun 1 02:31:38 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168E1E06BD for ; Wed, 1 Jun 2011 02:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFN-ZsHngfph for ; Wed, 1 Jun 2011 02:31:37 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55DE06AF for ; Wed, 1 Jun 2011 02:31:36 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p519QIY6009442 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Jun 2011 11:31:29 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 1 Jun 2011 11:31:18 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 1 Jun 2011 11:31:16 +0200 Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVAAAOHlwAFcgoEQAAIsWAA= Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B451B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102EB815C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102EB815C@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B451BFRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 09:31:38 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B451BFRMRSSXCHMBSD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bruno, thanks for that hint, well spotted! Should be subject of the terminology definitions in =A7 3.1 of Draft H.248.= NATTP2P, there we got still placeholders. Concerning NATT, there are then two methods (just from H.248 IP-IP MG persp= ective) how RFC 5128 P2P frameworks may be realized with interim H.248 gate= ways. Dependent on the LOCATION of the "TCP connection merge point" (TCMP; i.e., = the entity resolving the two TCP connection establishment attempts to a sin= gle e2e TCP connection): 1st TCMPs located in TCP endpoints (compliant to RFC 793; thus support of "= Simultaneous TCP Open"). =3D> H.248 MG must configured for "transparently forwarding TCP connection = establishment request messages, in BOTH directions" 2nd single TCMP, located in an interim H.248 MG (scenario as e.g. indicated= by AVD-3984) Regards, Albrecht ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 1. Juni 2011 10:27 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P No this is different. RFC 5128, =A7 3.4 describes a solution where both end= points simultaneously send SYN messages. There is no intermediate network n= ode converting SYN messages into SYN-ACK messages. Bruno De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 12:02 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P Bruno, looks like that you are describing "TCP hole punching" according RFC 5128, = =A7 3.4, right? That solution is in scope of H.248.NATTP2P ("In scope of this document are = NAT-T techniques according [IETF RFC 5128].") ... and RFC 5128 is about NATT for P2P. ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 25. Mai 2011 11:44 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P My comments below inline, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, I have two questions about H.248.NATTP2P 1) The scope description suggests that this recommendation applies to P2P n= etworks. My understanding is that it also applies to any terminal to termin= al traffic within a managed network without application-level intermediary.= Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P scenari= o. The draft does not yet provide a link to the applied P2P definition in c= lause 3. More important in my opinion is the reference to the considered e2= e model by Fig. 1. Side question: what's the definition of an application-level intermediary? = Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an application-level in= termediary 2) What is the relation with TCP stitching? [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP stitching", = guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim = H.248 IP-IP MGs, which lead to the requirement in assigning different role = behaviours to the MGs, whereas your referred proprietary technology aims pe= rhaps just a single NAT traversal entity in the bearer path. But I don't kn= ow ... [BC] My understanding of TCP stitching is that both endpoints initiate a TC= P connection towards the MG and the MG joins both connections together. Thi= s requires the MG to convert TCP SYN on one side to TCP-SYN-ACK on the othe= r side, which means that the MGC has to request the MG to perform that tric= k, presumably by setting a termination or context property to a specific va= lue. So, the purpose of my question was to know whether this kind of mechan= ism was covered or will be covered by H.248.NATTP2P Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B451BFRMRSSXCHMBSD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Bruno,
 
thanks for that hint, well spotted!
 
Should be subject of the terminology defini= tions=20 in =A7 3.1 of Draft H.248.NATTP2P, there we got still=20 placeholders.
 
Concerning NATT, there are then two methods (jus= t from=20 H.248 IP-IP MG perspective) how RFC 5128 P2P frameworks may be realized wit= h=20 interim H.248 gateways.
Dependent on the LOCATION of the "TCP connection= merge=20 point" (TCMP; i.e., the entity resolving the two TCP connection establishme= nt=20 attempts to a single e2e TCP connection):
 
1st TCMPs located in TCP endpoints (compliant to= RFC=20 793; thus support of "Simultaneous TCP Open").
=3D> H.248 MG must configured for "transparen= tly=20 forwarding TCP connection establishment request messages, in BOTH=20 directions"
 
2nd single TCMP, located in an interim H.248 MG= =20 (scenario as e.g. indicated by AVD-3984)
 
Regards,
Albrecht

From: bruno.chatras@orange-ftgroup.co= m=20 [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 1. J= uni=20 2011 10:27
To: Schwarz, Albrecht (Albrecht);=20 megaco@ietf.org
Subject: RE: H.248.NATTP2P

No this is differen= t. RFC=20 5128, =A7 3.4 describes a solution where both endpoints simultaneously se= nd SYN=20 messages. There is no intermediate network node converting SYN messages i= nto=20 SYN-ACK messages.

Bruno

 

 

 

De : Schwarz, A= lbrecht=20 (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 12:02
=C0 : CHATRAS=20 Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:=20 H.248.NATTP2P

 

Brun= o,

look= s like=20 that you are describing "TCP hole punching" according RFC 5128, =A7 3.4,= =20 right?

That= =20 solution is in scope of H.248.NATTP2P ("In=20 scope of this document are NAT-T techniques according [IETF RFC=20 5128].")

... = and RFC=20 5128 is about NATT for P2P.

 <= o:p>

 <= o:p>

=  

From:=20 bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup.c= om]=20
Sent: Mittwoch, 25. Mai 2011 11:44
To: Schwarz,=20 Albrecht (Albrecht); megaco@ietf.org
Subject: RE:=20 H.248.NATTP2P=

 

 

De := Schwarz,= =20 Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 :<= /B>=20 CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:=20 H.248.NATTP2P

 

My= =20 comments below inline,=

Al= brecht=

 

From:=20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf= Of=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Ma= i=20 2011 13:34
To: megaco@ietf.org
Subject: [Megaco]= =20 H.248.NATTP2P

Hi,

 

I have two questions about=20 H.248.NATTP2P

 

1) The scope description sugg= ests that=20 this recommendation applies to P2P networks. My understanding is that= it=20 also applies to any terminal to terminal traffic within a managed net= work=20 without application-level intermediary. Is that correct?
= [[Schwarz,=20 Albrecht]] Perhaps yes, because that might be also a P2P=20 scenario. The draft does not yet provide a link to the applied P= 2P=20 definition in clause 3. More important in my opinion is the refe= rence=20 to the considered e2e model by Fig. 1.

= Side=20 question: what's the definition of an application-level intermediary?= Or=20 what kind of specific functios do you have in mind?

 

2) What is the relation with = TCP=20 stitching?
= [[Schwarz,=20 Albrecht]] I'm not aware of any definition for "TCP stitching", = guess=20 this is a marketing term used by a particular=20 vendor.

= Thus, I=20 may just speculate:

= Draft=20 H.248.NATTP2P considers e2e scenarios with possible multiple interim = H.248=20 IP-IP MGs, which lead to the requirement in assigning different = role=20 behaviours to the MGs, whereas your referred proprietary=20 technology aims perhaps just a single NAT traversal entity in th= e=20 bearer path. But I don't know ...  

 

 

Bruno

 

--_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B451BFRMRSSXCHMBSD_-- From bruno.chatras@orange-ftgroup.com Tue Jun 7 01:58:32 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986321F85E8 for ; Tue, 7 Jun 2011 01:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYqUsRNYpdg5 for ; Tue, 7 Jun 2011 01:58:31 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD021F85B5 for ; Tue, 7 Jun 2011 01:58:30 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40CE46C8003; Tue, 7 Jun 2011 10:59:46 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2AEAF6D800F; Tue, 7 Jun 2011 10:59:46 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Jun 2011 10:58:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC24F1.112C9665" Date: Tue, 7 Jun 2011 10:58:27 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102EE633F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B451B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVAAAOHlwAFcgoEQAAIsWAABLOGk8A== References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102EB815C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B451B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> From: To: , X-OriginalArrivalTime: 07 Jun 2011 08:58:29.0485 (UTC) FILETIME=[1203A9D0:01CC24F1] Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 08:58:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC24F1.112C9665 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Albrecht, =20 The call flow described in figure 3 in AVD-3984 is indeed equivalent to = what I was referring to when talking about tcp stitching. From your = previous messages I understand that this scenario falls in the scope of = H.248.NATTP2P. The, I have a subsequent question. How does the MGC = control this behavior: new termination property or context property to = be defined in H.248.NATTP2P? New value of the napt parameter of the = latch signal defined in H.248.37?=20 =20 Bruno =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 1 juin 2011 11:31 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 Hello Bruno, =20 thanks for that hint, well spotted! =20 Should be subject of the terminology definitions in =A7 3.1 of Draft = H.248.NATTP2P, there we got still placeholders. =20 Concerning NATT, there are then two methods (just from H.248 IP-IP MG = perspective) how RFC 5128 P2P frameworks may be realized with interim = H.248 gateways. Dependent on the LOCATION of the "TCP connection merge point" (TCMP; = i.e., the entity resolving the two TCP connection establishment attempts = to a single e2e TCP connection): =20 1st TCMPs located in TCP endpoints (compliant to RFC 793; thus support = of "Simultaneous TCP Open"). =3D> H.248 MG must configured for "transparently forwarding TCP = connection establishment request messages, in BOTH directions" =20 2nd single TCMP, located in an interim H.248 MG (scenario as e.g. = indicated by AVD-3984) =20 Regards, Albrecht =20 =09 ________________________________ From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Mittwoch, 1. Juni 2011 10:27 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P No this is different. RFC 5128, =A7 3.4 describes a solution where both = endpoints simultaneously send SYN messages. There is no intermediate = network node converting SYN messages into SYN-ACK messages. Bruno =20 =20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 12:02 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 Bruno, looks like that you are describing "TCP hole punching" according RFC = 5128, =A7 3.4, right? That solution is in scope of H.248.NATTP2P ("In scope of this document = are NAT-T techniques according [IETF RFC 5128].") ... and RFC 5128 is about NATT for P2P. =20 =20 =20 =09 ________________________________ From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Mittwoch, 25. Mai 2011 11:44 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P =20 =20 De : Schwarz, Albrecht (Albrecht) = [mailto:albrecht.schwarz@alcatel-lucent.com]=20 Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P =20 My comments below inline, Albrecht =20 =09 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, =20 I have two questions about H.248.NATTP2P =20 1) The scope description suggests that this recommendation applies to = P2P networks. My understanding is that it also applies to any terminal = to terminal traffic within a managed network without application-level = intermediary. Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P = scenario. The draft does not yet provide a link to the applied P2P = definition in clause 3. More important in my opinion is the reference to = the considered e2e model by Fig. 1. Side question: what's the definition of an application-level = intermediary? Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an = application-level intermediary =20 2) What is the relation with TCP stitching?=20 [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP = stitching", guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple = interim H.248 IP-IP MGs, which lead to the requirement in assigning = different role behaviours to the MGs, whereas your referred proprietary = technology aims perhaps just a single NAT traversal entity in the bearer = path. But I don't know ... =20 [BC] My understanding of TCP stitching is that both endpoints = initiate a TCP connection towards the MG and the MG joins both = connections together. This requires the MG to convert TCP SYN on one = side to TCP-SYN-ACK on the other side, which means that the MGC has to = request the MG to perform that trick, presumably by setting a = termination or context property to a specific value. So, the purpose of = my question was to know whether this kind of mechanism was covered or = will be covered by H.248.NATTP2P =20 =20 Bruno =20 ------_=_NextPart_001_01CC24F1.112C9665 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Albrecht,

 

The call = flow described in figure 3 in AVD-3984 is indeed equivalent to what I was referring to = when talking about tcp stitching. =A0From your previous messages I understand = that this scenario falls in the scope of H.248.NATTP2P.=A0 The, I have a = subsequent question. How does the MGC control this behavior: new termination = property or context property to be defined in H.248.NATTP2P? New value of the napt parameter = of the latch signal defined in H.248.37?

 

Bruno

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 1 juin 2011 11:31
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

Hello Bruno,

 

thanks for that hint, well spotted!

 

Should be subject of the terminology definitions in = =A7 3.1 of Draft H.248.NATTP2P, there we got still placeholders.

 

Concerning NATT, there are then two methods (just from = H.248 IP-IP MG perspective) how RFC 5128 P2P frameworks may be realized with = interim H.248 gateways.

Dependent on the LOCATION of the "TCP connection = merge point" (TCMP; i.e., the entity resolving the two TCP connection establishment attempts to a single e2e TCP connection):

 

1st TCMPs located in TCP endpoints (compliant to RFC 793; = thus support of "Simultaneous TCP Open").

=3D> H.248 MG must configured for "transparently = forwarding TCP connection establishment request messages, in BOTH = directions"

 

2nd single TCMP, located in an interim H.248 MG (scenario = as e.g. indicated by AVD-3984)

 

Regards,

Albrecht

 

From:= bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 1. Juni 2011 10:27
To: Schwarz, Albrecht (Albrecht); megaco@ietf.org
Subject: RE: H.248.NATTP2P

No this is different. RFC 5128, =A7 3.4 describes a solution where both = endpoints simultaneously send SYN messages. There is no intermediate network node converting SYN messages into SYN-ACK messages.

Bruno

 

 

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 12:02
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

Bruno,

looks like that you are describing "TCP hole = punching" according RFC 5128, =A7 3.4, right?

That solution is in scope of H.248.NATTP2P = ("In scope of this document are NAT-T techniques according = [IETF RFC 5128].")

... and RFC 5128 is about NATT for P2P.

 

 

 

From:= bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Mittwoch, 25. Mai 2011 11:44
To: Schwarz, Albrecht (Albrecht); megaco@ietf.org
Subject: RE: H.248.NATTP2P

 

 

De : Schwarz, = Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE: H.248.NATTP2P

 

My comments below inline,

Albrecht

 

From:= megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of = bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. Mai 2011 13:34
To: megaco@ietf.org
Subject: [Megaco] H.248.NATTP2P

Hi,

 

I have two questions about = H.248.NATTP2P

 

1) The scope description = suggests that this recommendation applies to P2P networks. My understanding is that it also applies to any terminal to terminal traffic within a managed network = without application-level intermediary. Is that correct?
[[Schwarz, Albrecht]] Perhaps yes, because that might = be also a P2P scenario. The draft does not yet provide a link to the = applied P2P definition in clause 3. More important in my opinion is the = reference to the considered e2e model by Fig. 1.

Side question: what's the definition of an = application-level intermediary? Or what kind of specific functios do you have in = mind?

[BC] An MSRP relay for example is what I would call an application-level = intermediary

 

2) What is the relation with TCP = stitching?
[[Schwarz, Albrecht]] I'm not aware of any definition = for "TCP stitching", guess this is a marketing term used by a = particular vendor.

Thus, I may just speculate:

Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim H.248 IP-IP MGs, which lead to the requirement in assigning different role behaviours to the MGs, whereas your referred proprietary technology aims perhaps just a single NAT traversal = entity in the bearer path. But I don't know ...  

[BC] My understanding of TCP stitching is that both endpoints initiate a TCP = connection towards the MG and the MG joins both connections together. This requires = the MG to convert TCP SYN on one side to TCP-SYN-ACK on the other side, which = means that the MGC has to request the MG to perform that trick, presumably by = setting a termination or context property to a specific value. So, the purpose = of my question was to know whether this kind of mechanism was covered or will = be covered by H.248.NATTP2P

 

 

Bruno

 

------_=_NextPart_001_01CC24F1.112C9665-- From albrecht.schwarz@alcatel-lucent.com Tue Jun 7 23:49:17 2011 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702F311E809F for ; Tue, 7 Jun 2011 23:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.171 X-Spam-Level: X-Spam-Status: No, score=-4.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqjKBXITmQe9 for ; Tue, 7 Jun 2011 23:49:16 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2411E807E for ; Tue, 7 Jun 2011 23:49:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p586nCtc010155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Jun 2011 08:49:12 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 8 Jun 2011 08:49:12 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "bruno.chatras@orange-ftgroup.com" , "megaco@ietf.org" Date: Wed, 8 Jun 2011 08:49:11 +0200 Thread-Topic: H.248.NATTP2P Thread-Index: AcwaBnv1LiNr3hExQYSxJAS8ImtMqQAslbvQAAFbTVAAAOHlwAFcgoEQAAIsWAABLOGk8AAtwT3w Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620BA7B49B8@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <9ECCF01B52E7AB408A7EB8535264214102E44020@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3CD7@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B3D12@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102EB815C@ftrdmel0.rd.francetelecom.fr> <5F7BCCF5541B7444830A2288ABBEBC9620BA7B451B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <9ECCF01B52E7AB408A7EB8535264214102EE633F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102EE633F@ftrdmel0.rd.francetelecom.fr> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B49B8FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] H.248.NATTP2P X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:49:17 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B49B8FRMRSSXCHMBSD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno, we are preparing currently contributions for Draft H.248.NATTP2P for the Ju= ly WP2/16 meeting. Just a few indications: * proposal primarily based on LD/RD-embedded SDP attributes * however, + package for (at least) one statistic related to TCP connection= establishment * +/- H.248.37 may depend whether the H.248 MG should provide a local NA(P)= T or not (i.e., NAT-full vs NAT-less mode) * TCP mode of a H.248 Context is not always static (i.e., the same for the = entire duration of the Context lifetime), may change (e.g., in case of late= r SDP O/A cycles during a SIP session (e.g., in case of re-INVITEs)). * ... --Albrecht ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Dienstag, 7. Juni 2011 10:58 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P Albrecht, The call flow described in figure 3 in AVD-3984 is indeed equivalent to wha= t I was referring to when talking about tcp stitching. From your previous = messages I understand that this scenario falls in the scope of H.248.NATTP2= P. The, I have a subsequent question. How does the MGC control this behavi= or: new termination property or context property to be defined in H.248.NAT= TP2P? New value of the napt parameter of the latch signal defined in H.248.= 37? Bruno De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 1 juin 2011 11:31 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P Hello Bruno, thanks for that hint, well spotted! Should be subject of the terminology definitions in =A7 3.1 of Draft H.248.= NATTP2P, there we got still placeholders. Concerning NATT, there are then two methods (just from H.248 IP-IP MG persp= ective) how RFC 5128 P2P frameworks may be realized with interim H.248 gate= ways. Dependent on the LOCATION of the "TCP connection merge point" (TCMP; i.e., = the entity resolving the two TCP connection establishment attempts to a sin= gle e2e TCP connection): 1st TCMPs located in TCP endpoints (compliant to RFC 793; thus support of "= Simultaneous TCP Open"). =3D> H.248 MG must configured for "transparently forwarding TCP connection = establishment request messages, in BOTH directions" 2nd single TCMP, located in an interim H.248 MG (scenario as e.g. indicated= by AVD-3984) Regards, Albrecht ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 1. Juni 2011 10:27 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P No this is different. RFC 5128, =A7 3.4 describes a solution where both end= points simultaneously send SYN messages. There is no intermediate network n= ode converting SYN messages into SYN-ACK messages. Bruno De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 12:02 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P Bruno, looks like that you are describing "TCP hole punching" according RFC 5128, = =A7 3.4, right? That solution is in scope of H.248.NATTP2P ("In scope of this document are = NAT-T techniques according [IETF RFC 5128].") ... and RFC 5128 is about NATT for P2P. ________________________________ From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com] Sent: Mittwoch, 25. Mai 2011 11:44 To: Schwarz, Albrecht (Albrecht); megaco@ietf.org Subject: RE: H.248.NATTP2P De : Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om] Envoy=E9 : mercredi 25 mai 2011 11:01 =C0 : CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org Objet : RE: H.248.NATTP2P My comments below inline, Albrecht ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= bruno.chatras@orange-ftgroup.com Sent: Dienstag, 24. Mai 2011 13:34 To: megaco@ietf.org Subject: [Megaco] H.248.NATTP2P Hi, I have two questions about H.248.NATTP2P 1) The scope description suggests that this recommendation applies to P2P n= etworks. My understanding is that it also applies to any terminal to termin= al traffic within a managed network without application-level intermediary.= Is that correct? [[Schwarz, Albrecht]] Perhaps yes, because that might be also a P2P scenari= o. The draft does not yet provide a link to the applied P2P definition in c= lause 3. More important in my opinion is the reference to the considered e2= e model by Fig. 1. Side question: what's the definition of an application-level intermediary? = Or what kind of specific functios do you have in mind? [BC] An MSRP relay for example is what I would call an application-level in= termediary 2) What is the relation with TCP stitching? [[Schwarz, Albrecht]] I'm not aware of any definition for "TCP stitching", = guess this is a marketing term used by a particular vendor. Thus, I may just speculate: Draft H.248.NATTP2P considers e2e scenarios with possible multiple interim = H.248 IP-IP MGs, which lead to the requirement in assigning different role = behaviours to the MGs, whereas your referred proprietary technology aims pe= rhaps just a single NAT traversal entity in the bearer path. But I don't kn= ow ... [BC] My understanding of TCP stitching is that both endpoints initiate a TC= P connection towards the MG and the MG joins both connections together. Thi= s requires the MG to convert TCP SYN on one side to TCP-SYN-ACK on the othe= r side, which means that the MGC has to request the MG to perform that tric= k, presumably by setting a termination or context property to a specific va= lue. So, the purpose of my question was to know whether this kind of mechan= ism was covered or will be covered by H.248.NATTP2P Bruno --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B49B8FRMRSSXCHMBSD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bruno,
we are preparing currently contributions for Draft= =20 H.248.NATTP2P for the July WP2/16 meeting.
Just a few indications:
* proposal primarily based on LD/RD-embedded SDP=20 attributes
* however, + package for (at least) one stati= stic=20 related to TCP connection establishment
* +/- H.248.37 may depend whether the H.248 M= G should=20 provide a local NA(P)T or not (i.e., NAT-full vs NAT-less=20 mode)
* TCP mode of a H.248 Context is not always static= (i.e.,=20 the same for the entire duration of the Context lifetime), may change (e.g.= , in=20 case of later SDP O/A cycles during a SIP session (e.g., in case of=20 re-INVITEs)).
* ...
 
--Albrecht
 
 
 

From: bruno.chatras@orange-ftgroup.co= m=20 [mailto:bruno.chatras@orange-ftgroup.com]
Sent: Dienstag, 7. J= uni=20 2011 10:58
To: Schwarz, Albrecht (Albrecht);=20 megaco@ietf.org
Subject: RE: H.248.NATTP2P

Albrecht,

 

The call= flow=20 described in figure 3 in AVD-3984 is indeed equivalent to what I was refe= rring=20 to when talking about tcp stitching.  From your previous messages I= =20 understand that this scenario falls in the scope of H.248.NATTP2P.  = The,=20 I have a subsequent question. How does the MGC control this behavior: new= =20 termination property or context property to be defined in H.248.NATTP2P? = New=20 value of the napt parameter of the latch signal defined in H.248.37?=20

 

Bruno

 

De : Schwarz, A= lbrecht=20 (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 1 juin 2011 11:31
=C0 : CHATRAS=20 Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:=20 H.248.NATTP2P

 

Hell= o=20 Bruno,

 <= o:p>

than= ks for=20 that hint, well spotted!

 <= o:p>

Shou= ld be=20 subject of the terminology definitions in =A7 3.1 of Draft H.248.NAT= TP2P,=20 there we got still placeholders.

 <= o:p>

Conc= erning=20 NATT, there are then two methods (just from H.248 IP-IP MG perspective) h= ow=20 RFC 5128 P2P frameworks may be realized with interim H.248=20 gateways.

Depe= ndent=20 on the LOCATION of the "TCP connection merge point" (TCMP; i.e., the enti= ty=20 resolving the two TCP connection establishment attempts to a single e2e T= CP=20 connection):

 <= o:p>

1st = TCMPs=20 located in TCP endpoints (compliant to RFC 793; thus support of "Simultan= eous=20 TCP Open").

=3D&= gt; H.248=20 MG must configured for "transparently forwarding TCP connection establish= ment=20 request messages, in BOTH directions"

 <= o:p>

2nd = single=20 TCMP, located in an interim H.248 MG (scenario as e.g. indicated by=20 AVD-3984)

 <= o:p>

Rega= rds,

Albr= echt

=  

From:=20 bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup.c= om]=20
Sent: Mittwoch, 1. Juni 2011 10:27
To: Schwarz,=20 Albrecht (Albrecht); megaco@ietf.org
Subject: RE:=20 H.248.NATTP2P=

No this is differ= ent.=20 RFC 5128, =A7 3.4 describes a solution where both endpoints simultaneou= sly=20 send SYN messages. There is no intermediate network node converting SYN= =20 messages into SYN-ACK messages.

Bruno<= /SPAN>

 

 

 

De := Schwarz,= =20 Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 12:02
=C0 :<= /B>=20 CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:=20 H.248.NATTP2P

 

Br= uno,=

lo= oks=20 like that you are describing "TCP hole punching" according RFC 5128, = =A7 3.4,=20 right?=

Th= at=20 solution is in scope of H.248.NATTP2P ("In=20 scope of this document are NAT-T techniques according [IETF RFC=20 5128].")= =

..= . and=20 RFC 5128 is about NATT for P2P.=

 = ;

 = ;

 

From:=20 bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange-ftgroup= .com]=20
Sent: Mittwoch, 25. Mai 2011 11:44
To: Schwarz,= =20 Albrecht (Albrecht); megaco@ietf.org
Subject: RE:=20 H.248.NATTP2P

 

 

De = ;: Schwar= z,=20 Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]=20
Envoy=E9 : mercredi 25 mai 2011 11:01
=C0 = :=20 CHATRAS Bruno RD-CORE-ISS; megaco@ietf.org
Objet : RE:= =20 H.248.NATTP2P

 

= My=20 comments below inline,

= Albrecht

<= o:p> 

=

From:= =20 megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Beha= lf Of=20 bruno.chatras@orange-ftgroup.com
Sent: Dienstag, 24. = Mai=20 2011 13:34
To: megaco@ietf.org
Subject: [Megaco= ]=20 H.248.NATTP2P<= o:p>

Hi,

 

I have two questions about= =20 H.248.NATTP2P

 

1) The scope description su= ggests=20 that this recommendation applies to P2P networks. My understanding = is=20 that it also applies to any terminal to terminal traffic within a=20 managed network without application-level intermediary. Is that=20 correct?

[BC] An=20 MSRP relay for example is what I would call an application-level=20 intermediary

 

2) What is the relation wit= h TCP=20 stitching?

[BC] My=20 understanding of TCP stitching is that both endpoints initiate a TC= P=20 connection towards the MG and the MG joins both connections togethe= r.=20 This requires the MG to convert TCP SYN on one side to TCP-SYN-ACK = on=20 the other side, which means that the MGC has to request the MG to=20 perform that trick, presumably by setting a termination or context= =20 property to a specific value. So, the purpose of my question was to= know=20 whether this kind of mechanism was covered or will be covered by=20 H.248.NATTP2P

 

 

Bruno

 

= --_000_5F7BCCF5541B7444830A2288ABBEBC9620BA7B49B8FRMRSSXCHMBSD_--