Subject: [Megaco] H.248.NATTP2P

From: <[email-masked]>
Date: Tue, 24 May 2011 13:34:03 +0200

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?

2) What is the relation with TCP stitching? 

Bruno

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 25 May 2011 11:00:59 +0200

My comments below inline,
Albrecht

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Dienstag, 24. Mai 2011 13:34
To: [email-masked]
Subject: [Megaco] H.248.NATTP2P

Hi,

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?

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

Bruno

---

From: <[email-masked]>
Date: Wed, 25 May 2011 11:43:30 +0200

De : Schwarz, Albrecht (Albrecht) [mailto:[email-masked]] 
Envoyé : mercredi 25 mai 2011 11:01
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
Objet : RE: H.248.NATTP2P

Albrecht

	Hi,

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

	[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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 25 May 2011 12:01:38 +0200

Bruno,
looks like that you are describing "TCP hole punching" according RFC 5128, § 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: [email-masked] [mailto:[email-masked]]
Sent: Mittwoch, 25. Mai 2011 11:44
To: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: H.248.NATTP2P

Bruno