Wednesday 26 February 2014

Basics of Cisco Unified Border Element

Now a days SIP service are growing and the  service provider are providing SIP as  a service.These services can be terminated for a enterprise on a SBC/CUBE .
The CUBE has many benefit over traditional TDM circuit etc.

The benefit are

Interoperability : SIP is a protocol supported by many vendor  hence these can be deployed with different SIP solution

Demarcation Point : CUBE can be used as a demarcation point between PSTN and enterprise network

Encryption and security is also a part of  CUBE,you can use CUBE to hide the IP address of the CUCM 

To achieve the redundancy the SIP has more flexibility compared to Traditional Telephony.

CUBE can be deployed in two mode:

Media flow around : in case of media flow around  the CUBE doesn't comes into media path

Media flow through  : In case of media flow through the CUBE comes into media path

The command can be configured under dial-peer config using the command :

media flow-through|flow-around

CUBE can be used for media codec negotiation as well when the service provider link is terminated on the cube.
You can configure the media negotiation mode by configuring the below command under dial-peer
codec transparent

The above command define that the CUBE will not be part of any codec negotiation . if this command is not there then CUBE take part in codec negotiation

apart from then you need to configure allow-connection under voice service voip command

You can verify SIP calls in the CUBE using the command

show sip calls
show voice call status
show voip rtp connection
show call active voice

debug command used to debug dial peer

debug dialper voice inout

Sunday 23 February 2014

Call disconnect issue on MGCP on muted phone

Just want to share one incident with a customer and from that i came to know about this feature of MGCP gateway.
The problem we are facing is when the phone kept in mute stage for a long time it gets disconnected .

to resolve this feature put the below command in mgcp gateway and it resolved the issue .

no mgcp timer receive-rtcp

This command basically define how (method)  to detect a RTCP stream  for a MGCP call

CME configured as SRST fallback in MGCP mode

Cisco CME can be configured in SRST mode and is better option than normal SRST.CME in SRST support more feature compare to normal SRST and support less phone compared to CME as SRST

The configuration is pretty simple ..

For MGCP fallback you need to configure

ccm-manager fallback-mgcp

Then configure the below command to fallback to H323 in case of failover:

global
  service alternate DEFAULT

Then configure the SRST fallback in CME

telephony-service
srst mode auto-provision none

 srst ephone template 3  // Define the default template to be used for phone if the phone is not previously added in the configuration

srst dn template 2  // Define the dn template to be used for the phone if the phone is not previously added in the configuration

Define the dn line mode

srst dn line-mode dual

max-ephones 58
 max-dn 100
 ip source-address <CME port ip > port 2000 // Ip will be the one that phone will communicate for sccp


Verification command:

show telephony-service
show ccm-manager fallback-mgcp
debug ephone details
show telephony-service
show telephony-service ephone
ip tcp adjust-mss
session transport tcp

Tuesday 18 February 2014

Blocking calls based on time and pattern

In CME we can provision it do the call routing based on time and the pattern.
These kind of scenario came when you want to block some special pattern on out of office hour or permanently.

First you need to define out of office hour schedule and then need to define the out of office hour pattern and apply those pattern to either ephone-dn,globally in telephony-service.

The limit is 100 block pattern .

The command to configure this is "after-hours block pattern pattern-tag pattern".
This command is used to configure the pattern 1800XXXX for after hour blocking "after-hours block pattern 3 1800.... "

You can define the after hour time under the telephony-service command using the command .

"after-hours day day start-time stop-time "

"after-hours date month date start-time stop-time "

You can also define few ephone or ephone-dn an override from the after hour period so that they can dial pattern during after hour

The config would look like this  :

telephony-service
 after-hours block pattern 1 91
 after-hours block pattern 2 9011

 after-hours block pattern 3 91900 7-24
 after-hours day mon 19:00 07:00
 after-hours day tue 19:00 07:00
 after-hours day wed 19:00 07:00
 after-hours day thu 19:00 07:00
 after-hours day fri 19:00 07:00
 after-hours day sat 13:00 12:00
 after-hours day sun 12:00 07:00
!
ephone 23
 mac 00e0.8646.9242
 button 1:33
 after-hour exempt  // This will exempt  the ephone from the after-hour  config so that they can  dial during the after hour 
!
ephone 24
 mac 2234.1543.6352
 button 1:34


Sunday 16 February 2014

Survivable Remote Site Telephony ( SRST )

Survivable Remote Site Telephony (SRST) is a feature used in cisco IPT deployment to provide fallback in case the Remote site looses connectivity with the  CUCM cluster .

                     

The local voice gateway based on cisco IOS has the feature of providing local call agent functionality  once the gateway/remote site phones looses connectivity with the CUCM .


We can deploy SRST based on different protocol (MGCP,h323 and SIP).

The MGCP fallback uses h323 configuration as a default protocol
Also there are various mode of deployment of srst  like with CME as SRST or normal SRST .

Here are the various options for deployment of SRST .

1. Call-Manager-Fallback : This option is used basic deployment of SRST and have very limited feature to use. Also the use is very limited.The config of the phone are fetched using SNAP from the Phone itself

2.  Telephony-service with auto provision none : This option uses the CME router as SRST and if we used the telephony-service option with auto provision as none in that case the snap discovered the phone config and store the phone config in the ios running config .However the ephone-dn and ephone config is not visible in the router running config and hence customization cann't be done .

3. Telephony-service with auto provison dn : This is same as "Telephony-service with auto provision none " only difference is  that in this case the ephone-dn is visible in the route running config .

4.  telephony-service with auto provision all  : This is same as point number 2  and only difference is in this deployment both the ephone and ephone-dn is visible in the route ios running config .This method has more flexibility as the ephone and ephone-dn can be modified and also support maximum feature


Note : if you are using extension mobility with SRST then EM login will not work ,hence any new EM login will not be successful however existing login phone will continue to work



Friday 14 February 2014

Paging configuration in Call Manager Express

Just came across a requirement from a customer for implementing paging in Cisco Call Manager Express       ( CME )

The config is pretty much simple .

First  you need to define a ephone-dn for the paging and need to define a multicast ip address for paging.
The config will look like this  :

ephone-dn  5
 description Paging
 number 1001
 paging ip 239.0.1.20 port 2000

one u have configured the ephone-dn.
Apply the ephone-dn to the ephone you have configured in CME .

ephone  1
  paging-dn 5
!  
!
ephone  2
  paging-dn 5

Once the user dial 1001 from any phone .It will establish a one side audio to all the phone for paging.