Re: H.248.NATTP2P

<[email protected]> Wed, 25 May 2011 11:43:30 +0200
Newsgroups gmane.ietf.megaco
Message-ID <9ECCF01B52E7AB408A7EB8535264214102E44575@ftrdmel0.rd.francetelecom.fr>
 

 

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