cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
905
Views
5
Helpful
5
Replies
Contributor

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

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)
      • Zone (1)
        • Name: SIP
        • Type: Local
      • Path (1)
        • Hop (1)
          • Address: 127.0.0.1
    • Destination (1)
    • 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)  
      • Zone (1)  
        • •§ Name: SIP
        • •§ Type: Local
      • Path (1)  
        • •§ Hop (1)  
          • Address: 192.168.1.50:13532
    • Destination (1)  
    • 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

Everyone's tags (3)
5 REPLIES 5
Highlighted
Engager

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

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

Highlighted
Contributor

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

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

Highlighted
Contributor

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

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

Highlighted
Engager

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

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

Highlighted
Contributor

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

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

CreatePlease to create content