[cisco-voip] RTP arriving early generating ICMP unreachable

[Wes Sisk]

Even Cisco endpoints see this occasionally, see the closed defect 
CSCsv00222 for example.

Consider the client behavior that causes this.  Assumptions:
* In most VOIP protocols the client provides a port number to use for RTP.
* It is best practice to make that port number dynamic. 
* For a dynamic port number the client application must request a 
dynamic port from the client operating system.
* In most operating systems that requires opening the port. 
* RTP uses UDP.  Allocating UDP ports is lighter weight than allocating 
TCP ports in most operating systems.  Allocating a UDP port usually 
means opening the port. I know of no operating system where that allows 
reserving the port without opening the port.

So the client must allocate the port and signal the port to peer 
device.  Allocating should coincide with opening.  If the clients has 
allocated and signaled a port it has had reasonable window of 
opportunity to open the port and await traffic. Conditions are very much 
in favor of the client having the port open in advance of the first 
packets coming over the network.

There are 2 scenarios that come to mind:
1. reusing port numbers.  We've seen applications that do this.  The 
peer client may assume reuse of the same port and begin streaming before 
proper signaling is completed.  This is clearly undesirable in this 
scenario and for many other reasons.
2. a firewall or inspection engine.  I say engine because it could be an 
appliance in the network or a component of any network device including 
the endpoint.  These same engines tend to be hyper sensitive to packet 
flows so unidirectional streams are frowned upon. They tend to only 
allow symmetrical streams, or at least signaled symmetric streams.  In 
SCCP terms the engine may not permit packets until it sees both 
OpenRecieveChannel and StartMediaTransmission.  I call this 
hypersensitve because unidirectional streams are perfectly valid both in 
RFC and in practice.  Example:
http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/UC5.0.2/release_notes/rnipt502.html#wp1279992
Multicast Music-On-Hold not supported by SIP gateway (CSCsc30731)

There is also a configuration in CM to force allocation of bidrectional 
port allocation for CM especially for Music on Hold call flows that 
traverse firewalls.  This is another pointer to the potential 
intervention of "firewall or inspection engines".

ICMP is important in the RTP stream as it can be used to detect when a 
remote client becomes unreachable even in scenarios where the signaling 
channel is also lost.  This is critical for endpoints to notify call 
agents to properly clear a call. Example:
http://www.cisco.com/en/US/docs/ios/12_3t/voice/command/reference/vrht_m2_ps5207_TSD_Products_Command_Reference_Chapter.html#wp1362166


IOS Voice gateways and IOS Media Termination Points are also susceptible 
to this as they depend on ICMP similarly to avoid abandoned streams.

In general it is always possible for call control to go down and it is 
highly desirable to preserve audio between connected endpoints in that 
case.  Upon accepting this reality it becomes necessary to depend on 
methods such as ICMP to identify and clear unmanaged, unsolicited 
streams.  Unfortunately that generates a bit of domain conflict where 
ICMP can be used for other purposes (administratively prohibited?).

In general a client that offers a port should be listening on that 
port.  Leniency grants a small grace period of ICMP before abandoning 
the stream (CSCse88435 enhancement to SW MTP to allow a "grace period" 
of ICMP errors before determinging that end-point is rejecting TX packets).

At the start of an RTP burst ICMP is more indicative of a misbehaving 
client.  This would be a client advertising but not opening a port. 

At the end of RTP burst ICMP is more indicative of a signaling issue.  
One device elected to terminate the stream but the other device was not 
accurately notified.

/Wes


On Monday, May 17, 2010 5:49:11 PM, Dale Shaw 
<dale.shaw+cisco-voip at gmail.com> wrote:
> Hi,
>
> Disclaimer: The scenario I describe below is not present in a Cisco
> deployment -- at the moment I'm just trying to get a feel from this
> audience for how normal (or not) this behaviour is in other voice over
> IP environments.
>
> I'm investigating a situation at the moment where IP phones are
> generating an ICMP unreachable (destination port unreachable) packet
> on receipt of the first RTP packet during voice mail access.
>
> To me, it indicates a signalling timing/sequencing problem -- the
> phone is indicating it wasn't yet ready to process RTP and effectively
> wasn't listening. A very short time later, RTP begins flowing
> bi-directionally and everything is OK.
>
> Is there a generic explanation for this behaviour? Is it 'normal'? If
> you saw this in your network, would you investigate and tune?
>
> cheers,
> Dale
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>