Re: Action item from yesterday's meeting

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.




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