Re: H.248.NATTP2P

Bruno,
we are preparing currently contributions for Draft H.248.NATTP2P for the July 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 later SDP O/A cycles during a SIP session (e.g., in case of re-INVITEs)).
* ...

--Albrecht




________________________________
From: [email protected] [mailto:[email protected]]
Sent: Dienstag, 7. Juni 2011 10:58
To: Schwarz, Albrecht (Albrecht); [email protected]
Subject: 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