Cannot connect to a system behind VCS-E that has a leading Zero

John Shur · ‎10-23-2013

Hi All - I have a Cisco infrastructure with VCS-E, and usually have no trouble dialing anyone. One of our clients, though - has a system behind a VCS-VCS-E that has no DNS records, but I should be able to dial them using alias@IPaddress. However, the alias is 0921@custIP. When I dial it - everything on my end shows that as the destination etc, but when they see it at their expressway they see just 921@custIP and reject as unknown. They showed me asearch result of another system outside their network calling in that shows 0921@CustIP completing the call, so they don't think they are stripping off the zero. Our network logs on the VCS-E show:

H.225 setup….:

},
        destinationAddress
        {
          h323-ID : "0921@x.x.x.x"
        },
        destCallSignalAddress ipAddress :
        {
          ip '0A141409'H,
          port 1720
        },

So I don't think we are removing zero - any ideas on where else to look?

BTW - I can dial another endpoint at this same customer that does NOT have a leading zero.....

Thanks!

-John

Yan Simkin · ‎10-23-2013

John,

Did you try to run a Locate command? (Maintenance -> Tools -> Locate)

What's the result?

John Shur · ‎10-23-2013

Locate works:

Search (1)
- State: Completed
- Found: True
- Type: H323 (LRQ)
- CallRouted: True
- CallSerial Number: 109f985a-3bfb-11e3-8c49-0010f321e6ee
- Tag: 109f9990-3bfb-11e3-8d67-0010f321e6ee
- Source (1)
- - Authenticated: True
- - Aliases (1)
  - - Alias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: xcom-locate
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
- Destination (1)
- - Alias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: 047161@74.62.118.65
- StartTime: 2013-10-23 11:52:05
- Duration: 0.01
- SubSearch (1)
- - Type: Transforms
- - Action: Transformed
- - ResultAlias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: sip:047161@74.62.118.65
- - SubSearch (1)
  - - Type: Admin Policy
  - - Action: Proxy
  - - ResultAlias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: sip:047161@74.62.118.65
  - - SubSearch (1)
    - - Type: FindMe
    - - Action: Proxy
    - - ResultAlias (1)
      - Type: H323Id
      - Origin: Unknown
      - Value: 047161@74.62.118.65
    - - SubSearch (1)
      - Type: Search Rules
      - CallsToUnknownIPAddresses (3)
        Mode: Direct
      - SearchRule (1)
        Name: LocalZoneMatch
        Zone (1)
        Name: LocalZone
        Type: Local
        Protocol: H323
        Found: True
        StartTime: 2013-10-23 11:52:05
        Duration: 0
        Gatekeeper (1)
        Address: 10.20.7.7:0
        Alias (1)
        Type: H323Id
        Origin: Unknown
        
        Value: 047161@74.62.118.65

Its the setup where it fails:

earch (351)
- State: Completed
- Found: False
- Reason: Normal call clearing - Unknown reason
- Type: H323 (Setup)
- CallSerial Number: bfee68a0-3be1-11e3-91da-0010f321e6ee
- Tag: bfee69ea-3be1-11e3-a417-0010f321e6ee
- Source (1)
- - Authenticated: False
- - Aliases (1)
  - - Alias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: OEGateway3
- - Zone (1)
  - - Name: LocalZone
  - - Type: Local
- Destination (1)
- - Alias (1)
  - - Type: Url
  - - Origin: Unknown
  - - Value: 047161@74.62.118.65
- StartTime: 2013-10-23 08:50:52
- Duration: 0.05
- SubSearch (1)
- - Type: Transforms
- - Action: Transformed
- - ResultAlias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: sip:047161@74.62.118.65
- - SubSearch (1)
  - - Type: Admin Policy
  - - Action: Proxy
  - - ResultAlias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: sip:047161@74.62.118.65
  - - SubSearch (1)
    - - Type: FindMe
    - - Action: Proxy
    - - ResultAlias (1)
      - Type: H323Id
      - Origin: Unknown
      - Value: 047161@74.62.118.65
    - - SubSearch (1)
      - Type: Search Rules
      - CallsToUnknownIPAddresses (3)
        Mode: Direct
      - SearchRule (1)
        Name: LocalZoneMatch
        Zone (1)
        Name: LocalZone
        Type: Local
        Protocol: H323
        Found: False
        Reason: Normal call clearing - Unknown reason
        StartTime: 2013-10-23 08:50:52
        Duration: 0.03
        Gatekeeper (1)
        Address: 10.20.7.7:0
        Alias (1)
        Type: H323Id
        Origin: Unknown
        Value: 047161@74.62.118.65

Search (1)
- State: Completed
- Found: True
- Type: H323 (LRQ)
- CallRouted: True
- CallSerial Number: 109f985a-3bfb-11e3-8c49-0010f321e6ee
- Tag: 109f9990-3bfb-11e3-8d67-0010f321e6ee
- Source (1)
- - Authenticated: True
- - Aliases (1)
  - - Alias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: xcom-locate
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
- Destination (1)
- - Alias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: 047161@74.62.118.65
- StartTime: 2013-10-23 11:52:05
- Duration: 0.01
- SubSearch (1)
- - Type: Transforms
- - Action: Transformed
- - ResultAlias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: sip:047161@74.62.118.65
- - SubSearch (1)
  - - Type: Admin Policy
  - - Action: Proxy
  - - ResultAlias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: sip:047161@74.62.118.65
  - - SubSearch (1)
    - - Type: FindMe
    - - Action: Proxy
    - - ResultAlias (1)
      - Type: H323Id
      - Origin: Unknown
      - Value: 047161@74.62.118.65
    - - SubSearch (1)
      - Type: Search Rules
      - CallsToUnknownIPAddresses (3)
        Mode: Direct
      - SearchRule (1)
        Name: LocalZoneMatch
        Zone (1)
        Name: LocalZone
        Type: Local
        Protocol: H323
        Found: True
        StartTime: 2013-10-23 11:52:05
        Duration: 0
        Gatekeeper (1)
        Address: 10.20.7.7:0
        Alias (1)
        Type: H323Id
        Origin: Unknown
        Value: 047161@74.62.118.65

Search (1)
- State: Completed
- Found: True
- Type: H323 (LRQ)
- CallRouted: True
- CallSerial Number: 109f985a-3bfb-11e3-8c49-0010f321e6ee
- Tag: 109f9990-3bfb-11e3-8d67-0010f321e6ee
- Source (1)
- - Authenticated: True
- - Aliases (1)
  - - Alias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: xcom-locate
- - Zone (1)
  - - Name: DefaultZone
  - - Type: Default
- Destination (1)
- - Alias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: 047161@74.62.118.65
- StartTime: 2013-10-23 11:52:05
- Duration: 0.01
- SubSearch (1)
- - Type: Transforms
- - Action: Transformed
- - ResultAlias (1)
  - - Type: H323Id
  - - Origin: Unknown
  - - Value: sip:047161@74.62.118.65
- - SubSearch (1)
  - - Type: Admin Policy
  - - Action: Proxy
  - - ResultAlias (1)
    - - Type: H323Id
    - - Origin: Unknown
    - - Value: sip:047161@74.62.118.65
  - - SubSearch (1)
    - - Type: FindMe
    - - Action: Proxy
    - - ResultAlias (1)
      - Type: H323Id
      - Origin: Unknown
      - Value: 047161@74.62.118.65
    - - SubSearch (1)
      - Type: Search Rules
      - CallsToUnknownIPAddresses (3)
        Mode: Direct
      - SearchRule (1)
        Name: LocalZoneMatch
        Zone (1)
        Name: LocalZone
        Type: Local
        Protocol: H323
        Found: True
        StartTime: 2013-10-23 11:52:05
        Duration: 0
        Gatekeeper (1)
        Address: 10.20.7.7:0
        Alias (1)
        Type: H323Id
        Origin: Unknown
        Value: 047161@74.62.118.65

Yan Simkin · ‎10-23-2013

Can you check the Expressway log messages and filter them by a call tag? This will give better representation of the sequence.

John Shur · ‎10-23-2013

Hi Guys - the 10.20.20.14 is internal address of our MCU -not sure why it shows up as DestSignal call address - maybe I cut/pasted wrong. Anyway - theses are real.

The transfor IS done to take any dial strings in the format of alias@IPaddress and prepend the sip: - this was the only way I was able to get these to route to "calls to unknown IP addresses". See a previous post by me - never did open a TAC case, upgrade to 7.2.2 didn't solve. But that transform worked . I will do the logging as suggested and post. Thanks!

Martin Koch · ‎10-23-2013

That all sounds quite fishy to me.

You don't happen to have a mcu or gateway prefix registration or some search rule matching locally on uris starting with 0?

If you use any kind of prefix registration and dumb match all local zone matches that can cause issues.

In general you should have ip dialing to indirect, have search ip rules from your VCS-C to the VCS-E.

The VCS-E then in direct ip call mode and this is it. Check out the basic deployment guide for it, maybe you

get some better ideas regards setup and search rules.

Such a workaround hack search / transforms might mask some of the symptoms but it does not cure the cause.

I would recommend that you get yourself somebody on site to check your deployment!

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

John Shur · ‎10-24-2013

Hi Martin - I think you have it - we have a Vidyo Gateway (vidyo->H.323) that is somhow registering to the VCS-E with a 01, 02, 03 prefix - why I don't know - the only configuration of the Gateway is "Gatekeeper IP address". You are correct that there are a fair bit of fishy/workarounds - mostly because we only have VCS-E -no VCS-C. None of the deployment guides cover that! No way to have VCS-C indirect/VCS-E direct routing mode. Is there a way to disable prefix registrations?

Yan Simkin · ‎10-24-2013

John,

The prefixes with which the Vidyo GW registers are called "Services" in Vidyo-tongue. Get into the Vidyo GW WEB and click on Services link in the top menu. There you have them.

Reconfigure these prefixes and try to dial that customer again. (Get rid of that fishy transform too )

John Shur · ‎10-24-2013

Ahh - I found we had several "services" set up for "from Legacy" - even though we only dial out. I will delete them and see what happens. BTW - the fishy transform is only needed because of the Vidyo GW - I could dial a call using alias@ipaddress format from Movi, from our MCU, but not from the VidyoGW. For some reason the VidyoGW would call the alias a URL instead of a H.323Id as the cisco systems did, and it would search DNS zone instead of "calls to unknown IP address" direct routing. Until I created the "fishy" transform.

Thanks!!

Martin Koch · ‎10-23-2013

Is any of the mentioned information real or all mock up values?

Some things are a bit strange here, some thoughts:

destCallSignalAddress ipAddress :

{

ip '0A141409'H,

This looks like an internal ip: 10.20.20.14



SubSearch (1)


Type: Transforms




Action: Transformed


ResultAlias (1)


Type: H323Id




Origin: Unknown




Value: sip:047161@74.62.118.65

What kind of transform do you do there? The search at least shows that one is done and

that the alias gets a prefixed "sip:"

So if you could share some more light on your transforms and search rules.

Like Yan mentioned, some more info from the remote site like how does the registration look like,

how does the search rule look like, how does the search details look like and what is shown in a debug trace.

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

Yan Simkin · ‎10-23-2013

Maybe you should just create a special search rule for this customer and that's it. It's hard to tell without seeing the configuration.

Cannot connect to a system behind VCS-E that has a leading Zero in alias