Activating SIP protocol with Codian 3241 Gateway.

[juriss]

We have several Codian Gateways that are running the new 2.2 software.

This software now includes direct SIP protocol capability.

My question is HOW do I configure the GW...

I'm very familar with how it works with H.323.... (Prefix refgistration)

There are only 3 options under the setting on the web interface.... and the help is not very much help

SIP call settings
Outbound address
Outbound domain
Outgoing transport	UDPTCP

I looked at the documentation page under the Configuration and Programming guides and there was nothing that helps...

Is the a plain engish guide on how to set this up with examples...

I would like my SIP only endpoints to be able to make GW calls without the complexity associated with a Traversal SIP to H.323 transcoding.

If someone had done this or if thre is a document on the Cisco site that I missed, I would appreciate the help.

Thanks

[Martin Koch]

Hi Steven, how are you?

As you write prefix registration and traversal calls I assume you use a deployment with vcs?

Guess the main intention of having the sip software is to use it with CUCM.

For future postings, always post some more information about how your

deployment looks like (like here which call control in which relese version you use,

what kind of endpoints are involved, what kind of calls you do, ...

The more verbose the better :-)

Btw, if I look at your screenshot it looks like you are lacknig the encryption key,

as long as you do not live in an export resticted country I would recomend you

get your self the (free) option key, as that will enhance security at least on the IP side.

Where do you see the complexity on traversal calls? I am not sure where your VCS and

your endpoints are registered, many deployments I have seen most often used it for

voice calls and rarely for isdn video and if its often max 384 or 512 kbit and the isdn gw

is then often anyhow registered to a local vcs.

As the VCSC has 100 traversal call licenses I saw many were even happy that

its a traversal call, but thats just a side note.

What you simply do is to set up a neibor zone of your VCS pointing to the sip port of

your ISDN GW (in this case 5060 TCP and you need to add a search rule to match the

called number pointing it to that zone.

you could use a pregex or prefix strip that and only send the numbers you need to dial towards the

ISDN GW.

One remark, besides the dialplan there is no ip based security, means if sip is enabled every device

pointing to the right number@ip can dial out!

So better disable sip or put a firewall upfront so only your call control can reach it.

Please rate the postings and set the thread to answered if it is!

[juriss]

Martin

Thanks for the reply

In regard to our VTC Infrastructure:

TMS 13.2.2. running Provisioning Extension

(2) VCS-Controls in a cluster (X7.2)

(2) VCS-Expressways in a cluster (X7.1)

Traversal zones created between all VCS-Cs and VCS-Es

MSE8000 with a Gateway Blade

8341 stand alone gateway

Thanks we will look into the Encry Key

Is there a Cisco document that breaks it down stepo be step like below?

OK so the basic steps are...

#1 - In the 3241 for "outbound address" enter the Cluster name for the VCS-C cluster ?

#2 - in the 3241 for the "outbound domain" enter "@mycompany.com"

#3 - In the 3241 - If we have the Encry key we would select TLS, without it we would leaver it at TCP

#4 - In the VCS-C - Create a new Zone called "SIP Gateway Calls" and select Neighbor type

#5 - In the VCS-C - Populate the SIP section of the new zone

#6 - In the VCS-C - Create a search rule based on the prefix selected for SIP calls (e.g. 009) and point it to the new zone

#7 - In the 3241 setup dial plan rule to strip the prefix

I am very concerned about the security and hacker calls.... our VCS Expressways get hammered all the time

We have done things to prevent the calls from going anywhere, but we still see them

We get calls "Stuck" in the active call status with no "Route"

We want to upgrade the VCS-Expressways to X7.2 so we can use the Firewall feature to block attemps at the IP level

Thanks Martin

[Martin Koch]

Thanks for the thx, even better is if you use the stars below each posting, thats what me and

many people here motivates :-)

I do not see how the firewall functionality really helps. Its the VCS-E and you want to have

public connectivity. To get rid of most scans it can be handy to disable SIP/5060/UDP on the VCS

as most scans are hitting you by UDP.

Also if you have a VCS-E besides a local firewall I would always recommend also to block it via a

firewall in a DMZ.

Besides that the calls should be blocked via a combination of zones, search rules, CPLs

and authentication on the VCS.

Like I said as the ISDN GW is quite open you really should to have it behind a firewall if you allow outbound calls.

Thats also one thing, if you do not really really need outbound calls and you can get people to only

use inbound ISDN calls that can be helpful here as well. On our ISDN GW I simply do not allow

outbound calls at all.

I assume your ISDN GW is registered to the VCS-C, so you can also think of at least

blocking all calls from the traversal zone to the ISDN GW and I would block it on the VCS-E

as well as on the VCS-C.

The search rules became very powerfully I am not sure if that was recorded as a feature request

but what I would like to see is also a way to respond on a sucessfull match with an error code,

I made ma a CPL service as a workaround, but it could be quite easy to say, search rule answer:

reject: 403 Forbidden, ..

Depending on the software version there are some bugs where the vcs calls might not show

the zone or the destination, but thats most likely a bug and must not be a hacker attempt. :-)

Maybe a feature request for more security features and alerts by the isdn gw would be handy in addition.

[Martin Koch]

Thx for rating (if it was you - which made my yellow forum ranking star blue :-)

And +5 for you, especially as you gave some basic steps!

[juriss]

Replys have been rated......

I agree on the SIP UDP disable..... I see that tip often

Have you heard of trouble with receiving adhoc from other VTC systems after disabling SIP/UDP.

I think its safe to assume that all the Cisco stuff including Jabber would be fine.

Yes, our VCS-S sit in the DMZ (FW between the Internet and a 2nd FW between the Companies inside network)

Getting the FW rules changes is a long and slow process...  not sure if it practical to add IPs to block

Yes we definitly need the ability to do outbound calls.... we do it today for H323... need to have that for SIP also

OK, I see ypour point.... we should not allow any calls that come from the Traversal Zone to the new SIP GW zone

What is the easist way to program that restriction?

Thanks

[Martin Koch]

SIP UDP is mostly used for telephony systems.

The INVITE of a TelePresence call are way bigger causing it being >1500bytes

so it would have to be split in multiple UDP packets, which themselves often

keep haning in firewalls.

Its a decision what you want to do, we have many customers not using udp and

not complaining at all, or better did before about the 100@ip calls, ...

You have to make the decision: absolute reachability vs. scan attempts.

Regards sip, where do you really see the benefit or better the problems with the interworking?

If you do not have a firewall upfront the isdn gw I would not do it, there is always the chance

of missuse (we have even seen hacked mxp systems trying to dial out via multisite, ...

Also check for looping calls through a auto attended, which allow a dial out again, like on the MCU,

IPGW, ISDNGW, ...

As I do not know your deployment its hard to say what the easiest is. Its always the combination of all

and depends on the software versions running (like you said with the firewall option for example, or

the additional search rule capabilities, ...)

If you have the chance check with your Cisco partner or an external consultant to help you on a review.

Most of the time besides the security there will be something found which can be optimized in addition.