VCS regular expression

[rfrome]

Does anyone have an example of a regular expression for the following pattern to be dialed from an internal video endpoint on the VCSc that will route to the internet.

My customer has a busines partner that wants them to connect to their bridge dialing:  IP Address##7digit conf bridge.

Like this:

123.123.123.123##1234567

thanks,

rf

[Jens Didriksen]

That's Polycom proprietary "URI dialling", you can use transform on VCS-E to allow this for incoming calls from the internet, which is transforming a non-standard based address to a standard based addres, but it won't work the other way around.

What they should be using is H323 Annex O which is the standard; 1234567@123.123.123.123

Other option would be to dial their auto-attendant and select the relevant conference.

/jens

Sent from Cisco Technical Support Android App

[gubadman]

I guess the reflex you would want is along the lines of match:

(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})##(\d+)

Replace with:
\2@\1

I have no idea if this will work in practice though as I've never tried dialling that kit.

Sent from Cisco Technical Support iPad App

[Jens Didriksen]

You can also use

(.*)##(.*)

Replace

\2@domain

for incoming calls from the internet which will allow Polycom systems to connect to systems behind a VCS, using their proprietary format, but it won't work outbound since Cisco/TANDBERG does not support this format - and rightly so.

If anything, they would have to dial out using Annex O and then transform this to PLCM proprietary format, but again, if nothing has changed since last time I experimented with this back in x6.0, then it ain't gonna work.

I guess another option would be to create a zone for this MCU if possible, and dial using only the alias.

/jens

[Paul Woelfel]

I use a simmilar expression like Guy suggested  for a Transform. We have some Lifesize Endpoints, which do not send digits@ip to vcs, but try to reach it directly. All other URIs work fine though. So we use the ip#digits format to send is URI to VCS and transform it to a correct URI, so the Expressway can work with it.

I also created a transform for SIP clients, if some one tries to dial the same format in Jabber:

(sip:)?((\d+\.){3}\d+)(%23)+(\d+).*

\5@\2

[Jens Didriksen]

Yes, I can see how that works for incoming calls to end-points behind a VCS  since I am doing that myself, however I cannot see how it will work for outbound calls, which is what is wanted.

So to make sure there's no misunderstandings; you dial Annex O, which is Alias@domain, or Alias@IP_address, from the end-point which is registered to the VCS-C, then transform this to IP_address##Alias to a destination beyond the VCS-E?

This is something I've never been able to get to work, but if you say that's what you're doing, then I'll give it another try.

/jens

[Paul Woelfel]

Hi Jens,

no, I'm doing it the other way round. We are dialing IP_Address#Alias which is transformed on the VCS to Annex O Alias@IP_Address.

[Jens Didriksen]

Thanks Paul,

that's what I expected, how I read your transforms - and is also what I am doing, but I wanted it confirmed so we're on the same page.

My understanding is the original question was how to transform to IP_address#Alias for a call coming from an end-point registered to a VCS-C in order to connect ; i.e

Endpoint (alias@domain or IP address) --->VCS--->MCU (IP_address##Alias)

and that can't be done, at least not at the present time.

Not sure if  creating a neighbour zone targeting the IP address of the MCU will work, but it would be worth trying.

If it works, great - then only the alias, (might be an idea to use a prefix), needs to be dialled.

If it doesn't work, no harm done.

Would also be interesting to know if the MCU is registered to a GK, VBP or something similar, in which case Alias@domain can be used as long as the far-end kit has been configured correctly.

/jens

[Martin Koch]

Jens:

In which scenario / what kind of MCU would you want to use that?

The IP_Address##Alias is a helper to map a e164 number to a given ip address,

and that works with the vcs on h323 out of the box.

And sure with a neigbor zone it would work fine.

If you want a h323 id to be in that format you could just make a search rule,

but sure in case for example of our MSE8510 that syntax is not supported,

but still it get nicely signalled :-)

• • Zone (2)
  • • Name: MCU-HD
  • • Type: Neighbor
  • • Protocol: H323
  • • Found: False
  • • Reason: In conf
  • • Gatekeeper (1)
    • • Address: 192.168.1.2:1720
    • • Alias (1)
      • • Type: H323Id
      • • Origin: Unknown
      • • Value: 192.168.1.2##4321

And I would not want to exclude that a search rule adding the destination ip##number@ip would also

do what you want, but like I said, this is in general nothing you would really want ;-)

[Jens Didriksen]

Hi Martin,

Wasn't me who wanted to use this - see the original question.

Try dialling IP_address##Alias from any TANDBERG/Cisco end-point without creating zones/search rules for each every neighbouring zone requiring this address format etc, and see what happens, now compare that to Annex O. One is proprietary, the other is not.

/jens

[rodolfo.davila]

Hi Jens,

You mentioned this before: 

"Yes, I can see how that works for incoming calls to end-points behind a VCS since I am doing that myself, however I cannot see how it will work for outbound calls, which is what is wanted.

So to make sure there's no misunderstandings; you dial Annex O, which is Alias@domain, or Alias@IP_address, from the end-point which is registered to the VCS-C, then transform this to IP_address##Alias to a destination beyond the VCS-E?

This is something I've never been able to get to work, but if you say that's what you're doing, then I'll give it another try.

/jens"

I'm trying to do the same (outbound calls) from an Cisco SX20 endpoint registered to VCSC---->VCSE---->Polycom Gateway(remote company)---->Polycom endpoint (all this without good results).

I believe that the logic of this case is this:

The SX20 dials alias@ip_address format, the VCSControl send it to the VCSE via traversal Zone, VCSE transforms it to IP_address##Alias and send it to the NeighborZone of the remote company

Is that correct?

Have you been able to get it work?

Thank you,

/Rodolfo

[Paulo Souza]

Hi Rodolfo,

I have been able to get it working sometime ago. I did exactly as you described, translating the number and sending it to the destination via neighbor zone.

I think that the dial plan is not the great issue here, you can try to send the full URI with ## or send only the number. Normally, the issue is related to how to stablish a neighbor zone, because, the zone configuration may really be different depending upon the kind of device you have in the remote side (endpoints, gateway, MCU ans so son).

Maybe you will have to experience some different neighbor zone profiles until you get the correct one.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Jens Didriksen]

See Paulos post here:

https://supportforums.cisco.com/message/3550694#3550694

which is the only solution I've seen which will work.

/jens

[Martin Koch]

rf:

I would assume that the remote site just does not know what capabilities their systems have,

at least that would not be the first time that this would have happened  :-p

So either I would just simply see that ip dialing works and then try to dial

1234567@123.123.123.123 instead of the 123.123.123.123##1234567

Jens:

As it is called Annex O its quite obvious that it was not in h.323 from the beginning :-)

To understand more I would say we need to look deeper into h323 and its signaling

capabilities. From what I see dial a given number at a given ip address (gk) is nothing new,

and if I see it further right that is what the ## is trying to archive.

Annex O itself is more about URI dialing itself, so that name@dns would be possible.

But I guess its worth spending the time more looking into sip then this :-p

If the strange system really needs a h323-id formed as  123.123.123.123##1234567

I would either just add one static mapping (if its just that one meeting room to dial up)

like 666@localdomain locally would become:

123.123.123.123##1234567@123.123.123.123

[Jens Didriksen]

Yes, of course it was not in H.323 from the beginning, there was no URI dialling back then - but it was added as a "standard", whereas IP##Alias was never a "standard".

Polycom even uses this today, in 2013, as the preferred address format for connecting to a Polycom system behind a VBP or whatever. (It's not that long since I received an e-mail from a Polycom rep who had only that address format in his signature.)

I otherwise agree wholeheartedly with you.

/jens