Re: H.248.NATTP2P

No this is different. RFC 5128, § 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:[email protected]] 
Envoyé : mercredi 25 mai 2011 12:02
À : CHATRAS Bruno RD-CORE-ISS; [email protected]
Objet : RE: H.248.NATTP2P

 

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 protected] [mailto:[email protected]] 
	Sent: Mittwoch, 25. Mai 2011 11:44
	To: Schwarz, Albrecht (Albrecht); [email protected]
	Subject: RE: H.248.NATTP2P

	 

	 

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

	 

	My comments below inline,

	Albrecht

		 

		
________________________________


		From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
		Sent: Dienstag, 24. Mai 2011 13:34
		To: [email protected]
		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

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco