[cisco-voip] RTP arriving early generating ICMP unreachable

[Nick Matthews]

A similar scenario that I can think of:

In a SIP conversation one endpoint may not open the socket for UDP
until their SDP has been confirmed.  They may do this for security
purposes, to prevent unnecessary open sockets; I'm not sure.  They can
exchange media with a 200 OK but the socket wouldn't open until they
receive an ACK.  By the time the other side receives the 200 OK they
send both an ACK and the RTP stream together.  The ACK takes longer
because it's not a direct path, and you get one packet in before the
ACK is received.

-nick

On Mon, May 17, 2010 at 6:49 PM, Wes Sisk <wsisk at cisco.com> wrote:
> 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
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>