A search rule on a VCS works when using "Locate" tool, but NOT d

Chris Swinney · ‎04-29-2013

Hi All,

I have been struggling to write this question so bear with me. We have tried many different types of searching through using a single default zone with transforms, to using multiple subzone and specific search rules, however, I cannot seem to get one specific search to function properly.

Essentially, we have Jabber Video clients, H.323 endpoints (using E.164), and several SIP based clients (specifically Cisco 7960 IP Phones running a SIP image) all registering to a VCS Control. There is also A VCS Expressway with traversal zone to the VCS-C.

I can get most call types and searches working except for local Jabber clients calling the SIP IP phones. The Jabber clients register in the format name@domain, whilst the 7960 SIP based phone register as number@IP_Address_VCS-C.

As the Jabber client register with the @domian, and the IP phones register with an @ip_Address_VCS-C, we use a regex to strip off the domain name, then (in this case) the search rule add in the @ip_Address_VCS-C. As mentioned, we have tried many combinations, but all show similar results.

When I use the Locate tool on the VCS (Maintenance --> Tools --> Locate), the search works correctly - the endpoint is found as I would expect. I have conducted the search as I would expect to see it conducted during a call by specifying the correct alias', source zone, authentication and protocol. (Note - I have altered IP addresses, URI, and E.164 numbers, but kept the same format)

Search completed.

Search (8)
- State: Completed
- Found: True
- Type: SIP (OPTIONS)
- CallRouted: True
- CallSerial Number: 66aa8e90-b0ef-11e2-adde-0010f31ed960
- Tag: 66aa9048-b0ef-11e2-80c3-0010f31ed960
- Source (1)
  - Authenticated: True
  - Aliases (1)
    - Alias (1)
      - Type: Url
      - Origin: Unknown
      - Value: name@domain.com
  - Zone (1)
    - Name: SIP
    - Type: Local
  - Path (1)
    - Hop (1)
      - Address: 127.0.0.1
- Destination (1)
  - Alias (1)
    - Type: Url
    - Origin: Unknown
    - Value: sip:123456100@domain.com
- StartTime: 2013-04-29 18:08:24
- Duration: 0
- SubSearch (1)
  - Type: Transforms
  - Action: Transformed
  - ResultAlias (1)
    - Type: E164
    - Origin: Unknown
    - Value: 123456100
  - SubSearch (1)
    - Type: Admin Policy
    - Action: Proxy
    - ResultAlias (1)
      - Type: E164
      - Origin: Unknown
      - Value: 123456100
    - SubSearch (1)
      - Type: FindMe
      - Action: Proxy
      - ResultAlias (1)
        Type: E164
        Origin: Unknown
        Value: 123456100
      - SubSearch (1)
        Type: Search Rules
        SearchRule (1)
        Name: IP Phone from Jabber
        Zone (1)
        Name: LocalZone
        Type: Local
        Protocol: SIP
        Found: True
        StartTime: 2013-04-29 18:08:24
        Duration: 0
        Gatekeeper (1)
        Address: 192.168.1.2:0
        Alias (1)

Type: H323Id
Origin: Unknown
Value: 123456100@192.168.1.2

However, when I actually make a call, I get a "Request Timed Out" error on the same search rule. As mentioned, I have tried this many different ways, but all paths seem to lead to the same result.

Search (503)
- State: Completed
- Found: False
- Reason: Not Found
- Info: Policy Response
- Type: SIP (INVITE)
- CallSerial Number: 6f6d7e04-b0f2-11e2-bfb4-0010f31ed960
- Tag: 6f6d7fc6-b0f2-11e2-9154-0010f31ed960
- Source (1)
  - Authenticated: True
  - Aliases (1)
    - •§ Alias (1)
      - Type: Url
      - Origin: Unknown
      - Value: name@domain.com
  - Zone (1)
    - •§ Name: SIP
    - •§ Type: Local
  - Path (1)
    - •§ Hop (1)
      - Address: 192.168.1.50:13532
- Destination (1)
  - Alias (1)
    - •§ Type: Url
    - •§ Origin: Unknown
    - •§ Value: sip:123456100@domain.com
- StartTime: 2013-04-29 18:30:07
- Duration: 32.01
- SubSearch (1)
  - Type: Transforms
  - Action: Transformed
  - ResultAlias (1)
    - •§ Type: E164
    - •§ Origin: Unknown
    - •§ Value: 123456100
  - SubSearch (1)
    - •§ Type: Admin Policy
    - •§ Action: Proxy
    - •§ ResultAlias (1)
      - Type: E164
      - Origin: Unknown
      - Value: 123456100
    - •§ SubSearch (1)
      - Type: FindMe
      - Action: Proxy
      - ResultAlias (1)
        Type: E164
        Origin: Unknown
        Value: 123456100
      - SubSearch (1)
        Type: Search           Rules
        SearchRule (1)
        Name: IP Phone from Jabber
        Zone (1)
        •§Name: LocalZone
        •§Type: Local
        •§Protocol: SIP
        •§Found: False
        •§Reason: Request Timeout
        •§StartTime: 2013-04-29 18:30:07
        •§Duration: 32.01
        •§Gatekeeper (1)
        Address: 192.168.1.2:0
        Alias (1)
        Type: H323Id
        Origin: Unknown
        Value: 123456100@192.168.1.2
        Zone (2)
        •§Name: LocalZone
        •§Type: Local
        •§Protocol: H323
        •§Found: False
        •§Reason: Not Found
        •§StartTime: 2013-04-29 18:30:39
        •§Duration: 0
        •§Gatekeeper (1)
        Address: 192.168.1.2:0
        Alias (1)
        
        Type: H323Id
        Origin: Unknown
        Value: 123456100@192.168.1.2

Now, the search works fine with an external client dialling in over the Traversal zone. In fact, the only way I have been able to get this to work is to if I allow the search to continue and get the alias to be passed back up the traversal zone (i.e. to the VCS-E) which then returns the call back down the traversal zone, and to the endpoint. This creates two traversal calls on both the VCS-C and VCS-E in addition to a 30 second wait whilst the endpoints connect, and essentially has to interwork the call from SIP --> H.323 --> SIP - everything I wish to avoid.

All endpoints register in the correct subzones.

The VCSs are using x7.2.2 (but other versions of 7.x have been tried with no difference).

Has anyone got any ideas?

Chris

Message was edited by: Chris Swinney Updated formatting on search results

Message was edited by: Chris Swinney More formatting

Martin Koch · ‎04-29-2013

If you look at the status messages, the search uses OPTION and the call an INVITE which times out.

It can be the SDP or the INVITE itself, that might be the reason why it works through the traversal zone

making it an interworked call.

I never tried to register such a phone to the VCS, but it might be that its not supported or that the phone

does not like the invite from the other side (or that you have an other problem like some ALG/L3, ...)

Did you try to register the phone to CUCM and zone up the VCS&CUCM? Or use an other registrar

which works (think Asterisk should do the trick)?

Please remember to rate helpful responses and identify

Chris Swinney · ‎04-30-2013

Cheers Martin. CUCM is not an option for us at this moment in time as we simply don't own a licence. The closest we will come will be a trial version I will be setting up to run through the Cisco Voice and and Video track certifications - when I can get the time! All the VCS's we manage are done so through TMS. I'm betting the Cisco will eventually merge the functionally of TMS with CUCM and so we will have to change our setup, but this is probably way down the line.

We originally used the 7960 phones on the default Skinny image (many, many moons back) that registered to a very old Call Manager (version 5 or 6 I think), but due to the nature of the SCCP protocol, the way call manager worked with registrations, and the nature of our supported endpoints, it never really worked for us.

The primary use of the IP Phones are to provide a secondary audio conference which runs parallel to a videoconference in order that we can provide a live audio translation. However, they are also useful to call from a Jabber client - but NOT necessary. The nature of the beast is that these IP phones are located in various institutions behind firewalls and NAT, and would register to a local VCS Control - hence the updating of the phones image to SIP. Unfortunately, this SIP image on these phones is not even a Cisco supported option, so I don't hold out too much hope, and at the worst we will just have to leave it as is. The 7960 SIP image doesn't seem to allow for domain name to be added to the device registration name (from what I remember), and so the phones are always registered with the IP address of the local VCS control as the domain part of the URI.

Given the "non supported" nature of the Cisco stuff, it maybe that we simply junk the phone is the future an move a headless software SIP based client. After all, the audio out put feeds a seperate system linked to wireless headsets and the input (if required) is via a sperate microphone. Again, this is unlikely to happen any time soon.

Chris

Chris Swinney · ‎05-03-2013

Hey Martin/All,

It appears that no matter how I configure the zone/search rule, I cannot make a SIP --> SIP no traversal call to the 7960 IP Phones. So, can you tell me what the differnce is between a SIP (Options) and SIP (Invite) search?

Cheers,

Chris

Martin Koch · ‎05-03-2013

Hi Chris

You find many web sites and RFCs giving you more detailed info.

like:

http://www.voip-info.org/wiki/view/SIP+method+options

http://www.voip-info.org/wiki/view/SIP+method+invite

http://www.ietf.org/rfc/rfc3261.txt

and so on.

In short, the OPTION method queries a remote site about their capabilities.

The INVITE is an actual establishment of a session, for example a call.

So in short, something like might happen here:

VCS: Can you hande it

Phone: Sure

VCS: here is the call

Phone: silence (D'oh!)

Out of curiosity, can two phones call each other?

Even if that works it would not help you with your problem.

I guess I would check out if an other registrar / b2bua can handle

the calls, or better replace the phones.

Chris: please rate ansers here in the forum with the stars below,

this is what motivates me to write here! ;-)

Please remember to rate helpful responses and identify

Chris Swinney · ‎05-07-2013

Hi Martin,

That was extremely helpful (and has been rated accordingly ). I like the "out of curiosity" option and am always willing to test out something. I need to look back at how the the call search occurs when we do get a connection (as said previously, I think this get interworked from SIP --> H.323 (from VCSc to VCSe) then back again), and I need to check out if its possible to make direct inbound SIP calls.

In an ideal world - the phone would get replaced. Problem is as a not for profit organisation, we simply don't have the funds to go about replacing 100 or so IP Phones. I have thought about the possibility of using a simple headless PC type system (even the Raspberry Pi - which I have sitting on my desk) and get a software client connected as these systems don't really need to be a hardware phone), but I haven't even got out of the starting gate yet.

Chris

A search rule on a VCS works when using "Locate" tool, but NOT during an actual call - Why?