Re: Action item from yesterday's meeting

Hi Cullen,

--On Montag, 29. November 2004 14:21 Uhr -0800 Cullen Jennings 
<[email protected]> wrote:

|
| Ok, I think I understand - combining Juergen's and Martin's emails - just
| to make sure I have this right, in the case with an outbound call (so UA1
| called UA2) and UA1 controls NAT.
|
|                                   +-----+
|                                   |  M  |
|                                   |  I  |
|                                   |  I  |
|                                   |  D  |
|             UA1                   |  L  |                     UA2
|         +------+                  |  E  |                  +------+
|         |SIP UA+------------------+  B  +------------------+SIP UA|
|         |MIDCOM|                  |  O  |                  |  EXT |
|         |AGENT +..................+  X  +..................+      |
|         +------+                  +-----+                  +------+
|          A0                    A1        A2                 A3
|
|
| UA1 contacts NAT with a PER for (A0/port0, */*) direction inbound and the
| NAT returns A2/port2. UA1 sends A2/port2 in offer SDP. UA2 starts sending
| early media to A2/port2 this which gets forwarded to A0/port0. Then UA2
| sends answer with A3/port3 to UA1. UA1 tells NAT to create
| (A0/port0,A3/port3) outbound and NAT returns A1/port1 then UA1 starts
| sending media to A1/port1 and NAT forwards to A3/port3. UA2 answers and
| sends 200 which UA1 accepts then UA1 changes the (A0/port0,*/*) inbound
| mapping to be a (A0/port0,A3/port3) inbound mapping.
|
| Did I get this right? I think I understand now - thanks for the
| clarification.

Yes, you got this right!.  Your text describes exactly the way how it works
if UA1 is calling UA2.

  Martin

|
|
|
|
| On 11/29/04 5:25 AM, "Juergen Quittek" <[email protected]> wrote:
|
|> Cullen,
|>
|> --On 27.11.2004 15:12 h -0800 Cullen Jennings wrote:
|>
|>> I don't think I fully understand the issue yet
|>>
|>> Let's ignore FTP for a second but consider any protocol that has
|>> separated control and media channels. For example, if SIP was used to
|>> set of a MSRP IM session - it seems like this problem would happen. Am
|>> I confused? Actually I can answer that, I am confused, let me restate
|>> the questions - Can you straighten me out on how this all works? I am
|>> particularly interested in the case of SIP setting up a session of RTP
|>> and TCP sessions between endpoints.
|>>
|>> For simplicity sake, lets imagine that internal endpoint A0 is also a
|>> SIP UA that can control the middle box.
|>
|> This case, which is one of the core scenarios of the MIDCOM WG.
|> It is fully supported by the current semantics as well as by the
|> semantics Suresh suggested even in case of a twice-NAT.
|>
|> Let's assume that the SIP UA operates behind a NAT and that it has
|> already established NAT binding and session that allows communication
|> with other SIP UAs and servers across the twice NAT using the SIP
|> protocol.  Then SIP signaling itself is not the problem.
|>
|> In case of an INVITE message issues by the local terminal,
|> the SIP UA could operate as follows:
|>
|>    1. scan the SDP payload and extract the local terminal's address
|>       parameters A0 (IP address, port number)
|>    2. request address translation of these local address parameters
|>       at the NAT using the MIDCOM protocol.
|>       Here both semantics under discussion are similar.
|>       The only input you have is the local terminal address A0.
|>       This is sent to the NAT as input parameter
|>       The NAT returns the translated external parameters A2.
|>       If you want to apply a more tight security policy, you use
|>       the Policy Reserve Rule (PRR) transaction  that does not yet
|>       enable NAT service for the address and that may block early
|>       media. Otherwise you would use the Policy Enable Rule (PER)
|>       that immediately enables the NAT service.
|>    3. Then the original invite message needs to be patched replacing
|>       the original address parameters A0 with the parameters A2 returned
|>       by the NAT. The patched message if forwarded following SIP routing
|>       rules.
|>    4. On receipt of an OK message, the UA scans the SDP payload and
|>       extracts the other terminal's address parameters A3.
|>    5. Now a mapping for the reverse direction need to be established
|>       using the MIDCOM protocol again.  According to the current
|>       semantics, the SIP UA sends A0 and A3, the terminal's address
|>       parameters, with Suresh's semantics it would be A2 and A3.
|>
|> For the reverse direction (incoming call, the procedure is similar.
|>
|> This all works for RTP, RTSP, TCP, etc.
|>
|> Thanks,
|>
|>     Juergen
|
|