Subject: [MMUSIC] 3GPP/IMTC and Pipelining

From: "Mike Severa" <[email-masked]>
Date: Thu, 16 Apr 2009 15:52:49 -0700

Hi. Earlier this year IMTC held a F2F interop and had two issues arise
related to pipelining that 3GPP felt this group should be aware of.
These are not issues with the design of the feature but simply
limitations on the environments in which it may apply, and as such may
already be understood. Note that 3GPP PSS Rel7 has defined the same
Pipelined-Requests header as is found in RTSP 2.0 because it still
references 1.0. 3GPP was made aware of these issues and suggested
raising them with this group.

The first issue was an incorrect port mapping by an RTSP-aware NAT that
was between the client and the server. The client pipelined two SETUPs
and a PLAY request. The NAT remapped the client_port (RTSP 1.0 client)
in the SETUPs to the ports exposed by the NAT to the server, which of
course meant that the server's SETUP responses contained these remapped
values. However, when forwarding these responses to the client, the NAT
correctly unmapped the client_port value in the first SETUP response,
but left the server's response value in the second SETUP response. This
only happened when the requests were pipelined. There appeared to be a
broken or no binding on the NAT for the second RTP channel as the media
for that track never arrived at the client. No extensive investigation
was done. 

While this is clearly a NAT implementation issue, it is useful to
understand that such issues may arise as a result of using the
pipelining mechanism.

The second issue was the inability to rely on so-called firewall packets
in conjunction with pipelining. These packets are used by many 3GPP
clients to open holes in a firewall by sending empty RTP packets to the
server's ports. The value of these ports, however, is only found in the
SETUP responses. If a PLAY has been pipelined with the SETUPs, the
server may process the PLAY and begin sending packets before the client
receives the SETUP responses (before which it cannot issue firewall
packets). The result being that the initial RTP packets may be blocked
by the firewall until the client has a chance to issue its firewall
packets. 

On one hand, it should be clear that not all features are always useful
in every environment, however NATs are very prevalent, and 3GPP
obviously has some stake in the pipelined feature and is concerned about
the impact of this.

It does not appear there is a solution using the existing design that
doesn't sacrifice some of the potential gain, e.g., simply not
pipelining the PLAY. However, there may be ways to expand the meaning of
"RTSP-awareness" in one of the NAT related RFCs. Alternatively there may
be ways to extend the existing design to address this limitation.
However, this email was only intended to make the group aware of the
issues. 

Thanks,

Mike