Re: H.248.NATTP2P

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

 

Bruno

 

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

 

Hello Bruno,

 

thanks for that hint, well spotted!

 

Should be subject of the terminology definitions in § 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").

=> 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: [email protected] [mailto:[email protected]] 
	Sent: Mittwoch, 1. Juni 2011 10:27
	To: Schwarz, Albrecht (Albrecht); [email protected]
	Subject: 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