PIX troubles H.323 even with fixup disabled

Discussion in 'Cisco' started by Tilman Schmidt, Aug 15, 2007.

  1. We have some problems with H.323 videoconferencing in a private
    network segmented by various PIXen running OS version 6.3.
    Clients are Polycom PVX running on Windoze PCs, and the problem we
    are seeing is that clients in one of the segments cannot connect to
    those in any other segment. More precisely, the call is signalled but
    when the called party clicks on "accept" the call is not connected
    and the caller gets a "refused" message. This seems to be the normal
    behaviour if the connection traverses a PIX which still has the
    default "fixup protocol h323" settings in place, but we have double
    checked that all the PIXen in this network have
    no fixup protocol h323 h225 1720
    no fixup protocol h323 ras 1718-1719
    in their configuration, and with that, video connections work fine
    now, except for that one segment.

    Any ideas how to troubleshoot this? (Without the trouble shooting
    back, if possible. ;-)

    aTdHvAaNnKcSe
    Tilman

    --
    Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...
     
    Tilman Schmidt, Aug 15, 2007
    #1
    1. Advertising

  2. Tilman Schmidt

    Guest

    On Aug 15, 9:12 am, Tilman Schmidt <> wrote:
    > We have some problems with H.323 videoconferencing in a private
    > network segmented by various PIXen running OS version 6.3.
    > Clients are Polycom PVX running on Windoze PCs, and the problem we
    > are seeing is that clients in one of the segments cannot connect to
    > those in any other segment. More precisely, the call is signalled but
    > when the called party clicks on "accept" the call is not connected
    > and the caller gets a "refused" message. This seems to be the normal
    > behaviour if the connection traverses a PIX which still has the
    > default "fixup protocol h323" settings in place, but we have double
    > checked that all the PIXen in this network have
    > no fixup protocol h323 h225 1720
    > no fixup protocol h323 ras 1718-1719
    > in their configuration, and with that, video connections work fine
    > now, except for that one segment.
    >
    > Any ideas how to troubleshoot this? (Without the trouble shooting
    > back, if possible. ;-)
    >
    > aTdHvAaNnKcSe
    > Tilman
    >
    > --
    > Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...


    I hope this will help, but it seems as though messages from this one
    particular segment are being blocked somewhere along the line or, the
    messages are getting modified somehow. run ethereal on the Polycom
    PVX system where videoconfencing works fine on and then run ethereal
    on a system from the network that is experiencing problems and compare
    the packets.

    -Chana Atar
     
    , Aug 17, 2007
    #2
    1. Advertising

  3. Tilman Schmidt

    Arthur Brain Guest

    Are you sure it's not just the destination ports that need to be
    opened?

    As it happens, I have today been playing with Polycom VC stations
    across a WAN link, and it is clear that the documented ports are
    WRONG.

    This is where I was at with my access lists (before I decided to use
    other means to filter this traffic):

    permit tcp any any eq 1720
    permit tcp any any range 3230 3237
    permit udp any any range 3230 3237
    permit udp any any range 2438 2445
    permit udp any any eq 1719
    permit tcp any any range 5555 5574
    permit udp any any range 2326 2405
    permit udp any any range 2478 2480

    This range seemed to work fine initially,
    permit udp any any range 3230 3237

    But then I connected in some Tandberg VC stations, and the Polycoms
    started using more and more ports, different for each new call.
    The doco the software came with was useless.
     
    Arthur Brain, Aug 17, 2007
    #3
  4. Arthur Brain schrieb:
    > Are you sure it's not just the destination ports that need to be
    > opened?


    Reasonably sure, because:
    - The PIX is configured not to block anything between these two
    networks.
    - The behaviour is completely different from what I observe when
    ports are blocked. (Blocked ports tend to result in timeouts,
    ie. a long wait before the connection fails. Here the connection
    errors out the very moment the called party clicks "accept".)
    - The behaviour is very similar to what I observed in the past
    if the h323 fixups were active in a PIX the connection had to
    pass.

    > As it happens, I have today been playing with Polycom VC stations
    > across a WAN link, and it is clear that the documented ports are
    > WRONG.


    Yeah. That's why I usually determine the ports I have to open from
    the PIX logs, not from the app docs.

    --
    Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...
     
    Tilman Schmidt, Aug 20, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Masud Reza
    Replies:
    1
    Views:
    3,058
    Walter Roberson
    Jan 3, 2004
  2. David K
    Replies:
    2
    Views:
    10,381
    David K
    Jan 9, 2004
  3. Brian V
    Replies:
    4
    Views:
    1,746
    Lutz Donnerhacke
    Oct 9, 2006
  4. Replies:
    2
    Views:
    820
    Walter Roberson
    Mar 3, 2007
  5. Christophe Pin

    Pix 506 - Fixup SMTP

    Christophe Pin, Aug 26, 2008, in forum: Cisco
    Replies:
    5
    Views:
    851
    Walter Roberson
    Aug 26, 2008
Loading...

Share This Page