Someone always gets bit on this. There are times when you just have to go add a route-pattern into the call routing table. I know I have. A lot of new guys to Cisco CUCM don't realize that when you add a route-pattern to the call routing table, the connection to the gateway gets reset. It doesn't matter if its a SIP, MGCP, or H323 (I have done this with MGCP and H323). That means that if people are on a call, that call will get dropped. It does this so that the route-pattern you added in can become active.
With that said, keep in mind, this only affects the gateways OR route lists that are being affected. Meaning, if you have a gateway that the route-pattern will not be involved with, the connection will not be reset to that gateway. Only gateways that are involved will be affected by the addition. This is verified by this message:
With that said, you certainly do not want to do this during a busy time of the day. In fact, I would prefer doing this at night if possible.
This is the retired Shane Killen personal blog, an IT technical blog about configs and topics related to the Network and Security Engineer working with Cisco, Brocade, Check Point, and Palo Alto and Sonicwall. I hope this blog serves you well. -- May The Lord bless you and keep you. May He shine His face upon you, and bring you peace.
Monday, October 28, 2013
Friday, October 25, 2013
ACME Packet: How To Change The System Clock/Time On A 4250 ACME Packet Net-Net Device
Why is this important? The main reason I can think of is when you take a packet capture and you need to line up your time with something you are doing. For example, I've been making test phone calls out an ACME gateway, and when I've been troubleshooting some SIP calls, its been important that I have the correct time stamp on the log I'm taking. If the time isn't off, sure you can figure it out, but it just takes more time. If you have the clock set correctly on the ACME in the first place, you don't have to worry about figuring out what the system time is on the ACME and then lining up your time stamps.
Here is how you set the clock on the ACME:
ACME01# show clock
05:25:13 UTC THU OCT 22 2013
ACME01#
ACME01# systime-set
Date YYYY MM DD: 2013 10 24
Time HH MM: 08 04
WARNING: Changing the time can have an adverse
effect on session processing
Do you want to continue [y/n]?: y
Setting time to: THU OCT 24 08:04:00 2013
ACME01# save-config
Here is how you set the clock on the ACME:
ACME01# show clock
05:25:13 UTC THU OCT 22 2013
ACME01#
ACME01# systime-set
Date YYYY MM DD: 2013 10 24
Time HH MM: 08 04
WARNING: Changing the time can have an adverse
effect on session processing
Do you want to continue [y/n]?: y
Setting time to: THU OCT 24 08:04:00 2013
ACME01# save-config
Monday, October 21, 2013
ACME Packet 4250 Net-Net: How do you take a capture from an ACME 4250 Net-Net device?
Ive been troublehshooting a call routing problem on a small project Im working on, and I have
had the need to figure out what the ACME in my environment is doing to my call. I have found
out, through these captures, that my call is being forwarded out the wrong ISP. So how do I
get this capture, so I can tell for sure what Im seeing?
To turn logging on, do the following:
ACME4250# notify sipd debug
ACME4250#
enabled SIP Debugging
ACME4250# notify sipd siplog
ACME4250#
To turn logging off, do the following:
ACME4250# notify sipd nodebug
ACME4250#
disabled SIP Debugging
ACME4250# notify sipd nosiplog
ACME4250#
Now you have to get the logs. You will need to FTP into the ACME box and get the logs, like
this:
C:\Users\shane>ftp 10.1.1.1
Connected to 10.1.1.1.
220 ACME4250 FTP server (VxWorks 6.4) ready.
User (10.1.1.1:(none)): shane
331 Password required for user.
Password: password
230 User user logged in.
ftp> cd /ramdrv/logs
250 CWD command successful.
ftp> asc
200 Type set to A.
ftp> get sipmsg.log
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/sipmsg.log' (131546 bytes).
226 Transfer complete.
ftp: 135087 bytes received in 0.23Seconds 577.29Kbytes/sec.
ftp> get log.sipd
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/log.sipd' (625802 bytes).
226 Transfer complete.
ftp: 634808 bytes received in 0.39Seconds 1627.71Kbytes/sec.
ftp> bye
221 Goodbye.
C:\Users\shane>
That is how you get the logs. Now just review to find out what you problems are.
had the need to figure out what the ACME in my environment is doing to my call. I have found
out, through these captures, that my call is being forwarded out the wrong ISP. So how do I
get this capture, so I can tell for sure what Im seeing?
To turn logging on, do the following:
ACME4250# notify sipd debug
ACME4250#
enabled SIP Debugging
ACME4250# notify sipd siplog
ACME4250#
To turn logging off, do the following:
ACME4250# notify sipd nodebug
ACME4250#
disabled SIP Debugging
ACME4250# notify sipd nosiplog
ACME4250#
Now you have to get the logs. You will need to FTP into the ACME box and get the logs, like
this:
C:\Users\shane>ftp 10.1.1.1
Connected to 10.1.1.1.
220 ACME4250 FTP server (VxWorks 6.4) ready.
User (10.1.1.1:(none)): shane
331 Password required for user.
Password: password
230 User user logged in.
ftp> cd /ramdrv/logs
250 CWD command successful.
ftp> asc
200 Type set to A.
ftp> get sipmsg.log
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/sipmsg.log' (131546 bytes).
226 Transfer complete.
ftp: 135087 bytes received in 0.23Seconds 577.29Kbytes/sec.
ftp> get log.sipd
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/log.sipd' (625802 bytes).
226 Transfer complete.
ftp: 634808 bytes received in 0.39Seconds 1627.71Kbytes/sec.
ftp> bye
221 Goodbye.
C:\Users\shane>
That is how you get the logs. Now just review to find out what you problems are.
Friday, October 18, 2013
SIP Conversation: T38 Does Not Negotiate For A Successful Fax
WE had this fax problem that when the customer tried to dial any toll free numbers with a fax machine, the fax would not go through. The customer would complain that the call would connect, then end with an error. Here is what the Telco found below. They said that we were sending an "Bye" back to them. Hmm, from below, it does look like they are correct.
Topology:
Topology:
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:46:352 10.10.10.1 10.20.30.2 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:46:354 10.20.30.2 10.10.10.1 Status 100 Trying
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:48:576 10.20.30.2 10.10.10.1 Status 183 SessnProgrss
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:54:384 10.20.30.2 10.10.10.1 Status 200 OK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:54:499 10.10.10.1 10.20.30.2 ACK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:04:00:707 10.10.10.1 10.20.30.2 BYE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:04:00:771 10.20.30.2 10.10.10.1 Status 200 OK
So one of the engineers I work with found the problem. He found that when the Telco sent the negotiations for codec, it did not negotiate correctly, causing the failure above. However, when he moved, in our CUCM, the search order of the codec (I think he put g729 over g711), then the call would negotiate correctly with the Telco and the fax worked correctly, as seen below.
Here is what the SIP conversation looks like now:
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:43:055 10.10.10.1 10.20.30.2 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:43:056 10.20.30.2 10.10.10.1 Status 100 Trying
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:45:200 10.20.30.2 10.10.10.1 Status 183 SessnProgrss
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:51:001 10.20.30.2 10.10.10.1 Status 200 OK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:51:116 10.10.10.1 10.20.30.2 ACK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:52:919 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:53:420 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:54:421 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:421 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:799 10.10.10.1 10.20.30.2 Status 200 OK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:942 10.20.30.2 10.10.10.1 ACK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:964 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:57:465 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:58:467 10.20.30.2 10.10.10.1 INVITE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:59:513 10.10.10.1 10.20.30.2 Status 200 OK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:59:651 10.20.30.2 10.10.10.1 ACK
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:15:34:550 10.10.10.1 10.20.30.2 BYE
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:15:34:614 10.20.30.2 10.10.10.1 Status 200 OK
Wednesday, October 16, 2013
Cisco CUCM: Caller-ID Shows As The Hunt Group Instead Of The Caller-ID Of The Original Caller
One of the guys came to our department and was saying that the caller-ID number on an incoming call (to a call center) was the number that was actually dialed by the caller (which is directly to a hunt group). So what happens is that on a DID coming in, it hits a hunt group, which then comes to several callers who wait to answer the phone. To the internal guys, the caller-ID is the hunt group, until someone answers the phone. When the phone is answered and the call is connected, THEN the actual caller's caller-ID shows up correctly. Well, no one wants that. They, in this case, want the actual caller-ID of the caller, not the hunt group.
So I did some research and found that from CUCM version 8.X and up, the default behavior IS to show the caller-ID of the hunt group, if one is hit on its way to the users. I found this here:
CSCth95017 - Configurable parameter on how callingparty is displayed for hunt groups
To stop that, here is where you go:
Go to System --> Service Parameters
Select the Publisher --> Cisco CallManager
Select 'Advanced'
So I did some research and found that from CUCM version 8.X and up, the default behavior IS to show the caller-ID of the hunt group, if one is hit on its way to the users. I found this here:
CSCth95017 - Configurable parameter on how callingparty is displayed for hunt groups
To stop that, here is where you go:
Go to System --> Service Parameters
Select the Publisher --> Cisco CallManager
Select 'Advanced'
Monday, October 14, 2013
SIP: Anatomy Of A Good Call Setup Of A SIP Phone Call
Im doing more with SIP these days, so I wanted to post what a good, successful SIP call looks like. Here are some things I came up with when looking at this in real time:
In one of my translators:
In another one:
Here is the actual capture:
47894366.001 |09:10:21.888 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 817 from 10.10.90.25:[5060]:
[19287418,NET]
INVITE sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml,application/sdp,multipart/mixed
Supported:
Max-Forwards: 68
Content-Type: application/sdp
Content-Length: 203
v=0
o=BroadWorks 2978824933 1 IN IP4 10.10.90.25
s=-
c=IN IP4 10.10.90.25
t=0 0
m=audio 7176 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no Source Filename: SDL005_100_000390.txt
47894370.001 |09:10:21.889 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287419,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow-Events: presence
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47894443.001 |09:10:21.903 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287420,NET]
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47895448.001 |09:10:23.125 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287452,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Type: application/sdp
Content-Length: 259
v=0
o=CiscoSystemsCCM-SIP 4185150 1 IN IP4 10.10.90.23
s=SIP Call
c=IN IP4 10.110.135.61
b=TIAS:8000
b=AS:8
t=0 0
m=audio 27318 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 Source Filename: SDL005_100_000390.txt
47895496.001 |09:10:23.331 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 487 from 10.10.90.25:[5060]:
[19287453,NET]
ACK sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bKgjit49107ofg7j08i4s1.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 ACK
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Max-Forwards: 68
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47899066.001 |09:10:29.980 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287561,NET]
BYE sip:2052343232@10.10.90.25:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Date: Mon, 07 Oct 2013 14:10:23 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47899077.001 |09:10:30.044 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 368 from 10.10.90.25:[5060]:
[19287562,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 101 BYE
Content-Length: 0
Source Filename: SDL005_100_000390.txt
In one of my translators:
In another one:
Here is the actual capture:
47894366.001 |09:10:21.888 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 817 from 10.10.90.25:[5060]:
[19287418,NET]
INVITE sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml,application/sdp,multipart/mixed
Supported:
Max-Forwards: 68
Content-Type: application/sdp
Content-Length: 203
v=0
o=BroadWorks 2978824933 1 IN IP4 10.10.90.25
s=-
c=IN IP4 10.10.90.25
t=0 0
m=audio 7176 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no Source Filename: SDL005_100_000390.txt
47894370.001 |09:10:21.889 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287419,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow-Events: presence
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47894443.001 |09:10:21.903 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287420,NET]
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47895448.001 |09:10:23.125 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287452,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Type: application/sdp
Content-Length: 259
v=0
o=CiscoSystemsCCM-SIP 4185150 1 IN IP4 10.10.90.23
s=SIP Call
c=IN IP4 10.110.135.61
b=TIAS:8000
b=AS:8
t=0 0
m=audio 27318 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 Source Filename: SDL005_100_000390.txt
47895496.001 |09:10:23.331 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 487 from 10.10.90.25:[5060]:
[19287453,NET]
ACK sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bKgjit49107ofg7j08i4s1.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 ACK
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Max-Forwards: 68
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47899066.001 |09:10:29.980 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287561,NET]
BYE sip:2052343232@10.10.90.25:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Date: Mon, 07 Oct 2013 14:10:23 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0
Source Filename: SDL005_100_000390.txt
47899077.001 |09:10:30.044 |AppInfo |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 368 from 10.10.90.25:[5060]:
[19287562,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 101 BYE
Content-Length: 0
Source Filename: SDL005_100_000390.txt
Saturday, October 12, 2013
Cisco Router: Where Is The CF Flash Card In A 2900 Router
I had to find this for a CME I was doing on a 2901 Cisco router. Its a little different than just visually seeing it and pushing the push button in to eject the card. See below where to find this card. There are two slots, but circled below is the first slot for the flash card.
Use a screwdriver or something to push toward cover, as below.
Then, just eject.
Use a screwdriver or something to push toward cover, as below.
Then, just eject.
Wednesday, October 9, 2013
Palo Alto: How To See The Update Progress
I went to do a "demo" Palo here recently. I really do like this firewall. In getting this firewall ready, my colleague got the license ready on the Palo site (Thanks Jim) and I did the config and downloaded the license and updates. In trying to figure out where the download and install process was at in the GUI (which you cant), I thought I would find this out in CLI.
So go into CLI and here is the command you will run to see the progress for the updates:
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 10%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
You will notice the second job being updated and its progress. See below. Its better than sitting in the GUI and wondering where its all on the process.
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 45%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 55%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
So go into CLI and here is the command you will run to see the progress for the updates:
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 10%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
You will notice the second job being updated and its progress. See below. Its better than sitting in the GUI and wondering where its all on the process.
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 45%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
admin@PA-500>show jobs all
Enqueued ID Type Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43 7 Install PEND PEND Still Pending
2013/09/25 11:10:57 6 Content ACT PEND 55%
2013/09/25 11:10:19 5 Downld FIN OK 11:11:28
2013/09/25 11:07:17 4 Install FIN OK 11:10:58
2013/09/25 11:05:56 3 Downld FIN OK 11:06:09
2013/09/25 11:03:27 2 Commit FIN OK 11:04:19
2013/09/25 10:48:07 1 AutoCom FIN OK 10:49:32
Monday, October 7, 2013
Mono-alphabetic in Java -- by Babak Hoseini
Today I have another special guest post. Babak Hoseini has been happy to write about encryption. He has written a cool little source code that will do some encryption for you. Thank you Babak for writing a guest post for me. As always, I appreciate your input. --Shane Killen
Mono-alphabetic in Java -- by Babak Hoseini
A mono-alphabetic cipher is a simple substitution cipher wherein each letter of the plaintext is replaced by another letter in the ciphertext. An example of a mono-alphabetic cipher key follows:
Mono-alphabetic in Java -- by Babak Hoseini
A mono-alphabetic cipher is a simple substitution cipher wherein each letter of the plaintext is replaced by another letter in the ciphertext. An example of a mono-alphabetic cipher key follows:
Plain : A B C D E F G H I J K L M N O P Q R S T U V
W X Y Z
Cipher
: z y x w v u t s r q p o n m l k j i h g f e d c b a
This key means that any 'M' in the plaintext will be
replaced by a 'n' in the ciphertext, any 'P' in the plaintext will be replaced
by a 'k' in the ciphertext, and so on.
For instance, plaintext is : “meet
me at the party” and after
encrypt you get “nvvg1nv1zg1gsv1kzigb”
I wrote the program below in Java that will encrypt plaintext to ciphertext:
package encryption;
public class Encryption {
public static void main(String[] args) {
// TODO Auto-generated method stub
String plaintext = "meet me at the party";
char[] myarr = plaintext.toCharArray();
for(int count=0 ; count < myarr.length ; count++){
char cipher = myarr[count];
switch (cipher) {
case 'a':
System.out.print("z");
break;
case 'b':
System.out.print("y");
break;
case 'c':
System.out.print("x");
break;
case 'd':
System.out.print("w");
break;
case 'e':
System.out.print("v");
break;
case 'f':
System.out.print("u");
break;
case 'g':
System.out.print("t");
break;
case 'h':
System.out.print("s");
break;
case 'i':
System.out.print("r");
break;
case 'j':
System.out.print("q");
break;
case 'k':
System.out.print("p");
break;
case 'l':
System.out.print("o");
break;
case 'm':
System.out.print("n");
break;
case 'n':
System.out.print("m");
break;
case 'o':
System.out.print("l");
break;
case 'p':
System.out.print("k");
break;
case 'q':
System.out.print("j");
break;
case 'r':
System.out.print("i");
break;
case 's':
System.out.print("h");
break;
case 't':
System.out.print("g");
break;
case 'u':
System.out.print("f");
break;
case 'v':
System.out.print("e");
break;
case 'w':
System.out.print("d");
break;
case 'x':
System.out.print("c");
break;
case 'y':
System.out.print("b");
break;
case 'z':
System.out.print("a");
break;
case ' ':
System.out.print("1");
break;
case '1':
System.out.print(" ");
}
}
}
}
Sunday, October 6, 2013
Thursday, October 3, 2013
Cisco ASA: How Can You Tell How Many User Licenses Is Being Used On The ASA
Have you ever had a site where you had an ASA with 10 or 50 user licenses, and they were really close to the user license count? I have, several times. You get some users who cant 'get on the Internet'. This IP phone doesnt work anymore (cant stay registered). Any number of things you could hear.
So how do you know for sure if you are over that license limit? Good question.
Do the following command below, and keep in mind that this is concurrent connections.
.5505# sho local-host
Detected interface 'outside' as the Internet interface. Host limit applies to all other interfaces.
Current host count: 48, towards licensed host limit of: 50
Interface outside: 44 active, 209 maximum active, 0 denied
local host: <111.221.74.13>,
TCP flow count/limit = 0/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 1/unlimited
Conn:
UDP outside 111.221.74.13:40016 inside 192.168.104.28:15197, idle 0:01:41, bytes 170, flags -
local host: <91.190.216.61>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited
... the rest is deleted for brevity...
This helps to know where you are in the user usage. No one wants to count devices.
And, if you are close and need to run the timer down from the default 3 hours, you can do the following (if people are coming and going, like a guest to the network that just pushes you over that license limit).
This is the default:
timeout xlate 3:00:00
This is what you can do to run the timeout to 5 minutes:
timeout xlate 0:05:00
So how do you know for sure if you are over that license limit? Good question.
Do the following command below, and keep in mind that this is concurrent connections.
.5505# sho local-host
Detected interface 'outside' as the Internet interface. Host limit applies to all other interfaces.
Current host count: 48, towards licensed host limit of: 50
Interface outside: 44 active, 209 maximum active, 0 denied
local host: <111.221.74.13>,
TCP flow count/limit = 0/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 1/unlimited
Conn:
UDP outside 111.221.74.13:40016 inside 192.168.104.28:15197, idle 0:01:41, bytes 170, flags -
local host: <91.190.216.61>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited
... the rest is deleted for brevity...
This helps to know where you are in the user usage. No one wants to count devices.
And, if you are close and need to run the timer down from the default 3 hours, you can do the following (if people are coming and going, like a guest to the network that just pushes you over that license limit).
This is the default:
timeout xlate 3:00:00
This is what you can do to run the timeout to 5 minutes:
timeout xlate 0:05:00
Tuesday, October 1, 2013
Cisco: Route-Map Explanations For Policy Based Routing (PBR)
I wrote this out for one of my customers so that they would have a good understanding of route-maps. This is a basic route-map to just set the next-hop of packets defined in the ACL. On the left is the config. On the right is the explanation.
Subscribe to:
Posts (Atom)