Subject: [MMUSIC] draft-ietf-mmusic-media-path-middleboxes-00.txt: Comments

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 07 Apr 2008 12:49:23 +0200

Hi all, 

a few weeks ago I forwarded comments from Thomas Belling but unfortunately they got lost somewhere. So, here is another try: 

This is the beginning of Section 5:

-----------------------------------

5.  NAT Traversal

   One NAT traversal technique that is being used is based on media
   relay.  As shown in Figure 1 the MIDCOM agent that is being co-
   located with the SIP ALG functionality interacts with the middlebox
   that is also a NAT in order to request and allocate NAT bindings.  A
   side effect of the interaction with a (double) NAT is that the media
   traffic is forced to traverse a certain NAT in both directions (also
   called media anchoring).

   This architecture could be compared with a STUN relay
   [I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent
   rather than the end point itself.  The motivation why this technique
   is being used in favor to other NAT traversal techniques is that
   clients do not have to support anything beyond RFC 3261 [RFC3261] and
   network administrators can control and apply local policy to the
   relay binding process in a centralized manner.

-----------------------------------

Thomas suggest to rewrite the section to something like:

-----------------------------------

5.  NAT Traversal

Two distinct types of NAT traversal can be supported by MIDCOM agent and connected middlebox:

1. The MIDCOM agent and attached middlebox acts as session border controller at the border of an operator´s network to protect this network and to perform the IP address and port conversion which is frequently required because private address spaces are used within the network, or because IPv4 and IPv6 address realms are interfacing. For this use case, the middlebox itself performs functions similar to a NAT and is deployed instead of a NAT at a network border.

2. The MIDCOM agent and attached middlebox support the traversal of a residential NAT (also termed costumer premise equipment), which is typically located at the users side of an access network, for instance within an DSL router. The middlebox acts as kind of media relay.

Both functions can be combined by the same MIDCOM agent and connected middlebox, for instance by a TISPAN C-BGF.

   As shown in Figure 1 the MIDCOM agent that is being co-
   located with the SIP ALG functionality interacts with the middlebox
   that is also a NAT in order to request and allocate NAT bindings and then modifies the SDP offer and answer within SIP to insert the IP addresses and port allocated by the NAT as destination for the media in both directions.  A
   consequence of the interaction with a (double) NAT is that the media
   traffic is forced to traverse a certain NAT in both directions (also
   called media anchoring). The opening of pinholes through the middlebox is only done on request of the MIDCOM agent, and not triggered by the detection of outbound media flows. Such middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP IMS Access Gateway.

The functionality and control of the middlebox becomes comparable to media gateway and TISPAN standardized the usage of the H.248 /MEGACO protocol for the control of the middlebox by the midcom MIDCOM agent.

----------------------------------

Then, Thomas suggests a number of changes to Section 5.1. Here is the current text followed by his suggestion:

----------------------------------

5.1.  Protocol Interaction

   The MIDCOM agent's role is to inspect call control signaling and
   update media address and port values based upon media relay binding
   information allocated with the middlebox/media relay.  For SIP, this
   minimally involves updating the c= and m= lines in the SDP, although
   some implementations may update other elements of the SDP for various
   reasons.

   Because the endpoints may not be able to gather a server reflexive
   address for their media streams, the MIDCOM agent employs the
   following algorithm to ensure that media can flow to the given
   endpoint:

   1.  Give the corresponding endpoint an address and port on the
       middlebox for them to send media to for the endpoint served by
       the MIDCOM agent.

   2.  Give the served endpoint a different address and/or port on the
       middlebox for it to send media to for the corresponding endpoint.

   3.  Use the address and port the corresponding endpoint supplies for
       media streams as the destination for packets sent to the
       middlebox by the served endpoint.

   4.  Use the address and port of the first packet received from the
       served endpoint at the middlebox as the destination for packets
       sent to the middlebox by the corresponding endpoint.

   An example of this algorithm is shown in Figure 4 using SIP and SDP.
   In this example the UAC is the endpoint served by the MIDCOM agent,
   which is also acting as a local outbound proxy, and the UAS is the
   corresponding endpoint.

                 Media Relay   MIDCOM Agent and
     UAC         Middlebox     Outbound Proxy                    UAS
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |             |               |                             |
      | (1)  INVITE + SDP Offer     |                             |
      |---------------------------->|                             |
      |    c=IN IP4 10.0.0.1        |                             |
      |    m=audio 49170 RTP/AVP 0  |                             |
      |    a=sendrecv               |                             |
      |             |               |                             |
      |             | (2) Allocate  |                             |
      |             |<------------- |                             |
      |             |               |                             |
      |             | (3) Response  |                             |
      |             |-------------->|                             |
      |             | In: 47.0.0.3  | (4)  INVITE + SDP Offer     |
      |             |     50000     |---------------------------->|
      |             | Out: 47.0.0.4 |    c=IN IP4 47.0.0.3        |
      |             |     50002     |    m=audio 50002 RTP/AVP 0  |
      |             |               |    a=sendrecv               |
      |             |               |                             |
      |             |               |     (5) 180 + SDP Answer    |
      |             | (6) Update    |<----------------------------|
      |             |<--------------|    c=IN IP4 47.0.0.2        |
      |             | Peer: 47.0.0.2|    m=audio 36220 RTP/AVP 0  |
      |             |       36220   |    a=sendrecv               |
      |  (7)  180 + SDP Answer      |                             |
      |<----------------------------|                             |
      |  c=IN IP4 47.0.0.4          |                             |
      |  m=audio 50002 RTP/AVP 0    |                             |
      |  a=sendrecv                 |                             |
      |             |               |                             |
      |    (8)    200 OK            |     (8)    200 OK           |
      |<----------------------------|<----------------------------|
      |             |               |                             |
      |    (9)     ACK              |     (9)     ACK             |
      |---------------------------->|---------------------------->|
      |             |               |                             |
      |             |               |     (10)  UAS-RTP           |
      |             X<============================================|
      |             |               |   Source: 47.0.0.2:36220    |
      | (11) UAC-RTP|               |   Dest:   47.0.0.3:50000    |
      |============>|               |                             |
      | Source: 47.0.0.100:48650    |                             |
      | Dest: 47.0.0.4:50002        |                             |
      |             |               |     (12)  UAC-RTP           |
      |             |============================================>|
      |             |               |   Source: 47.0.0.3:50000    |
      | (13) UAS-RTP                |   Dest:   47.0.0.2:36220    |
      |<============|               |                             |
      | Source: 47.0.0.4:50002      |                             |
      | Dest:   47.0.0.100:48650    |                             |
      |             |               |                             |

                    Figure 4: Call Flow with SIP + SDP

   1.   UAC sends INVITE to local outbound proxy, which is also a MIDCOM
        agent, with an SDP offer.

   2.   The MIDCOM agent looks at the signaling and determines that a
        NAT may be present (Via header address mismatch with observed
        source address, etc.).  It asks the middlebox to allocate a
        media relay binding.

   3.   The middlebox responds with a media relay binding that consists
        of an inbound address/port for media from the UAS, and an
        outbound address/port for media from the UAC.

   4.   The MIDCOM agent updates the addresses in the SDP offer with the
        inbound address/port information from the middlebox/media relay
        binding response.

   5.   The UAS responds with a 180 containing an SDP answer.

   6.   The MIDCOM agent interacts with the middlebox to update the
        destination address/port information from the SDP answer for
        media to be sent to the UAS, and changes the addresses/ports in
        the SDP answer to the UAC with the outbound address/port
        information from the middlebox binding from step 3.  Media can
        now flow to the UAS from the UAC at the middlebox/media relay.

   7.   The UAC receives the SDP answer containing the media relay
        outbound address/port information.

   8.   The UAS answers the INVITE with a 200 OK.

   9.   The UAC acknowledges with an ACK.

   10.  RTP for the UAS (which may have begun flowing prior to answer)
        flows to the middlebox, but the middlebox has no reliable
        address to relay the media to for the UAC yet.  Media will
        typically be dropped.

   11.  RTP arrives at the media relay on the inbound address/port from
        the UAC.  The middlebox observes the source address and port of
        the arriving packet and completes the binding process.  The
        source address and port of the media from the UAC is now the
        destination address/port for media arriving on the outbound port
        of the middlebox/media relay from the UAS.

   12.  Media from the UAC is relayed to the UAS.

   13.  Media from the UAS is relayed to the UAC.  It is up to local
        policy at the media relay as to whether or not packets that had
        arrived from the UAS for the UAC are queued or dropped prior to
        the UAC's address/port information being updated in step 11.

----------------------------------

5.1.  Protocol Interaction

   The MIDCOM agent's role is to inspect call control signaling and
   update media address and port values based upon media relay binding
   information allocated with the middlebox/media relay.  For SIP, this
   minimally involves updating the c= and m= lines in the SDP, although
   some implementations may also update other elements of the SDP for various
   reasons.

   Because the endpoints may not be able to gather a server reflexive
   address for their media streams, the MIDCOM agent employs the
   following algorithm to ensure that media can flow to the given
   endpoint:

   1.  When receiving an initial SDP offer, the MIDCOM agent
+ requests resources for a new connection at the middlebox,
+ configures the middlebox for this connection to send media towards the offerer towards the destination address and port as received in the incoming SDP offer,
+ requests the middlebox to reserve a local IP address and port,
+ and exchanges the destination address and port from the incoming offer with that middlebox IP address and port in the forwarded offer.

   2.  When receiving an initial SDP answer, the MIDCOM agent
+ configures the middlebox for the corresponding connection to send media towards the answerer towards the destination address and port as received in the incoming SDP answer,
+ request the middlebox to reserve a local IP address and port,
+ and exchange the destination address and port from the incoming answer with that middlebox IP address and port in the forwarded answer.

	3. If the middlebox support the traversal of residential NATs, it applies a techniche called "media latching": The destination of IP packets forwarded by the middlebox is derived from the source of received IP packets. This overrides a destination address possibly configured by the MIDCOM agent.

   An example of this algorithm is shown in Figure 4 using SIP and SDP.
   In this example the UAC is the endpoint served by the MIDCOM agent,
   which is also acting as a local outbound proxy, and the UAS is the
   corresponding endpoint. In TISPAN, the H.248 /MEGACO protocol is used 
between MIDCOM agent and middlebox. The example Figure 4 also uses related terminology,

                 Media Relay   MIDCOM Agent and
     UAC         Middlebox     Outbound Proxy                    UAS
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |             |               |                             |
      | (1)  INVITE + SDP Offer     |                             |
      |    c=IN IP4 10.0.0.1        |                             |
      |    m=audio 491   RTP/AVP 0  |                             |
      |    a=sendrecv               |                             |
      |---------------------------->|                             |
      |             |               |                             |
      |             | (2) Add       |                             |
      |             |Connection= ?  |                             |
      |             |Termination1=? |                             |
      |             | (remote=      |                             |
      |             |  10.0.0.1:491,|                             |
      |             |  local=?)     |                             |
      |             |Termination2=? |                             |
      |             | (local=?)     |                             |
      |             |<------------- |                             |
      |             |               |                             |
      |             | (3) Response  |                             |
      |             |Connection=c1  |                             |
      |             |Termination1=t1|                             |
      |             | (local=       |                             |
      |             |  47.0.0.4:502)|                             |
      |             |Termination2=t2|                             |
      |             | (local=       |                             |
      |             |  47.0.0.3:500)|                             |
      |             |-------------->|                             |
      |             |               | (4)  INVITE + SDP Offer     |
      |             |               |---------------------------->|
      |             |               |    c=IN IP4 47.0.0.3        |
      |             |               |    m=audio 500 RTP/AVP 0    |
      |             |               |    a=sendrecv               |
      |             |               |                             |
      |             |               |     (5) 180 + SDP Answer    |
      |             |               |    c=IN IP4 47.0.0.2        |
      |             |               |    m=audio 362   RTP/AVP 0  |
      |             |               |    a=sendrecv               |
      |             | (6) Modify    |<----------------------------|
      |             |Connection=c1  |                             |
      |             |Termination2=t2|                             |
      |             | (remote=      |                             |
      |             |  47.0.0.2:362)|                             |
      |             |<--------------|                             |
      |             |               |                             |
      |  (7)  180 + SDP Answer      |                             |
      |  c=IN IP4 47.0.0.4          |                             |
      |  m=audio 500 RTP/AVP 0      |                             |
      |  a=sendrecv                 |                             |
      |<----------------------------|                             |
      |             |               |                             |
      |    (8)    200 OK            |     (8)    200 OK           |
      |<----------------------------|<----------------------------|
      |             |               |                             |
      |    (9)     ACK              |     (9)     ACK             |
      |             |               |                             |
      |             |               |     (10)  UAS-RTP           |
      |             X<============================================|
      |             |               |   Source: 47.0.0.2:362      |
      | (11) UAC-RTP|               |   Dest:   47.0.0.3:500      |
      |============>|               |                             |
      | Source: 47.0.0.100:48650    |                             |
      | Dest: 47.0.0.4:502          |                             |
      |             |               |     (12)  UAC-RTP           |
      |             |============================================>|
      |             |               |   Source: 47.0.0.3:500      |
      |             |               |   Dest:   47.0.0.2:362      |
      |             |               |                             |
      |             |               |     (13)  UAS-RTP           |
      |             X<============================================|
      |             |               |   Source: 47.0.0.2:362      |
      | (14) UAC-RTP|               |   Dest:   47.0.0.3:500      |
      |<============|               |                             |
      | Source: 47.0.0.4:502        |                             |
      | Dest:   47.0.0.100:48650    |                             |
      |             |               |                             |

                    Figure 4: Call Flow with SIP + SDP

   1.   UAC sends INVITE to local outbound proxy, which is also a MIDCOM
        agent, with an SDP offer.

   2.   The MIDCOM agent looks at the signaling and determines that a
        NAT may be present (Via header address mismatch with observed
        source address, etc.).  It asks the middlebox to allocate a
        media relay binding.

   3.   The middlebox responds with a media relay binding that consists
        of an inbound address/port for media from the UAS, and an
        outbound address/port for media from the UAC.

   4.   The MIDCOM agent updates the addresses in the SDP offer with the
        inbound address/port information from the middlebox/media relay
        binding response.

   5.   The UAS responds with a 180 containing an SDP answer.

   6.   The MIDCOM agent interacts with the middlebox to update the
        destination address/port information from the SDP answer for
        media to be sent to the UAS, and changes the addresses/ports in
        the SDP answer to the UAC with the outbound address/port
        information from the middlebox binding from step 3.  Media can
        now flow to the UAS from the UAC at the middlebox/media relay.

   7.   The UAC receives the SDP answer containing the media relay
        outbound address/port information.

   8.   The UAS answers the INVITE with a 200 OK.

   9.   The UAC acknowledges with an ACK.

   10.  RTP for the UAS (which may have begun flowing prior to answer)
        flows to the middlebox. If the middlebox applies latching,  the
        middlebox assumes that UAS is behind a residential NAT (which is
        not depicted in the flow) and the
        destination information in the SDP offer (step 1) reflects the 
        destination at UAC rather than at the residential NAT.
        Thus the middlebox has no reliable
        address to relay the media to for the UAC yet.  Media will
        typically be dropped.
        If the middlebox does not apply latching, it will forward the media
        towards the destination configured in step 2.

   11.  RTP arrives at the media relay on the inbound address/port from
        the UAC.  If the middlebox applies latching, it observes the source
        address and port of
        the arriving packet and completes the binding process.  The
        source address and port of the media from the UAC is now the
        destination address/port for media arriving on the outbound port
        of the middlebox/media relay from the UAS.

   12.  Media from the UAC is relayed to the UAS.

   13-14.  Media from the UAS is relayed to the UAC.  It is up to local
        policy at the media relay as to whether or not packets that had
        arrived from the UAS for the UAC are queued or dropped prior to
        the UAC's address/port information being updated in step 11.

Thoughts? 

Ciao
Hannes
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic