Dear All ,
I have Cisco 2821 , on IOS Version 12.4(13r)T, RELEASE SOFTWARE (fc1) " c2800nm-advipservicesk9-mz.124-24.T.bin" and cme version 7.1 , running since the last 2 years without any problem , i had client getting connected remotely using pptp to cisco2821 (Virtual-Template) and would use Cisco communicator , but slow network connection the voice would have disturbance, breakup etc , , I then shifted to SIP protocol , the voice quality on the same network changed from just manageable to excellent , the voice on pptp was so clear on G711ulaw encoding , using sip client xlite ,as never before . The problem is that every 19-20 the call disconnects , I opened a tac case and worked about for month on the same but did not have any result as well.
I am attaching the running-config of the router with debugs collected in hope that someone would be able to help me
Remote End (Windows Vista Home ) , 172.31.1.38/24 - PPTP(VPN) – Office CME 172.31.1.1/24
Remote End Extension (602) - Office Extension (500)
At Office end we have 4 MB connection and at Remote End we have 2Mb Connection
The below debugs have been collected, once the debug output is taken , logging has been cleared to avoid repetition ,
The Debug file has the following (debug-ccsip.txt)
1) debug ccsip calls
2) debug ccsip events
3) debug ccsip errors
4) debug ccapi in out
5) debug ccsip mess
Also please find attached file with (basic-cme.txt)
1) Show flash
2) Show ver
3) Show run
4) Show tech
I need to figure this thing out as i want to use a Cisco Linksys Spa 525G with a builtin VPN to use on the same network , and Black Berry Running Sip Client
Till Date I have successfully confired the following to work with CME
¨ Nokia Phone Running Nokia Call Connect for Cisco
¨ SPA 941 Phone
¨ SPA 2002
Guys Seriously need your help
The issue here is that CCME sends 200 OK to the INVITE for the answer, but CCME never receives an ACK back from the phone. CCME sends 200 OK 7 times total, the initial 200 OK...followed by 6 retries. CCME never receives an ACK, so the call will fail.
You'll want to sniff either CCME or your PC to see if the 200 OK is getting there...and if so, is X-Lite responding with ACK.
032014: Nov 19 19:25:41.878 AST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
SIP/2.0 200 OK
Date: Fri, 19 Nov 2010 15:25:28 GMT
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Remote-Party-ID: "Reception" <500>;party=called;screen=no;privacy=off
Via: SIP/2.0/UDP 172.31.1.47:24040;branch=z9hG4bK-d87543-243a6f29e409c26d-1--d87543-;rport
CSeq: 1 INVITE
o=CiscoSystemsSIP-GW-UserAgent 5879 2442 IN IP4 18.104.22.168
c=IN IP4 22.214.171.124
m=audio 18684 RTP/AVP 0
c=IN IP4 126.96.36.199
First of all i cant express my happiness and gratitude , just for the fact that someone did answer , GOD BLESS .
Well shall do a packet capture at the client end using wireshark and then send the entire capture , i tried doing the below at the CCME but here is my problem .
ip traffic-export profile sniffer mode capture
since i get connected via pptp to router using a virtual-template , i enabled the traffic capture on the virtual template interface , but it does not capture any traffic what so ever , this is my output for the show ip int brief .
Acti-Systems#show ip int brief
Interface IP-Address OK? Method Status Prot
FastEthernet0/0 172.31.1.1 YES NVRAM up up
Service-Engine0/0 172.31.1.1 YES TFTP up up
FastEthernet0/1 unassigned YES NVRAM up up
ATM0/3/0 unassigned YES NVRAM administratively down down
ATM0/3/0.1 unassigned YES unset administratively down down
NVI0 172.31.1.1 YES unset up up
SSLVPN-VIF0 unassigned NO unset up up
Virtual-Access1 unassigned YES unset down down
Virtual-Template1 188.8.131.52 YES TFTP down down
Virtual-Access2 unassigned YES unset up up
Virtual-Access3 unassigned YES unset up up
Virtual-Access4 unassigned YES unset up up
Virtual-Access4.1 184.108.40.206 YES TFTP up up
Dialer1 220.127.116.11 YES IPCP up up
Dialer1200 unassigned YES NVRAM up up
Line User Host(s) Idle Location
514 vty 0 admin idle 1d23h 172.31.1.33
515 vty 1 admin idle 1d23h 172.31.1.32
516 vty 2 admin idle 1d23h 172.31.1.34
517 vty 3 admin idle 03:53:50 172.31.1.38
518 vty 4 admin idle 02:06:02 172.31.1.39
519 vty 5 admin idle 01:57:06 172.31.1.39
520 vty 6 admin idle 00:01:12 18.104.22.168
*521 vty 7 admin idle 00:00:01 172.31.1.46
Interface User Mode Idle Peer Address
Vi3 PPPoE 00:00:00 22.214.171.124
Vi4.1 modest PPPoVPDN - 172.31.1.46 (This MY PPTP Session )
Please just guide me as to how i need to go ahead ,also i have got some debug from the client end .
If I try the virtual Interface , here is the error.
% Please use virtual template to configure your virtual access
Well in either case shall collect the wireshark output at the system end and revert back
I'm wondering if this is a simple routing issue...where the phone can reach the CCME (172.31.1.1), but CCME cannot reach the phone because of a routing issue.
Your voice register configs are bound to FE 0/0:
voice register global
source-address 172.31.1.1 port 5060
ip address 172.31.1.1 255.255.255.0
But it appears that the source being used on CCME is 126.96.36.199 because of your default route:
ip route 0.0.0.0 0.0.0.0 Dialer1
Also possibly because of your NAT configs.
031900: Nov 19 19:21:39.774 AST: //3240/685F1C919571/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Call Control Block (CCB) : 0x49EF0158
State of The Call : STATE_DEAD
TCP Sockets Used : NO
Calling Number : 602
Called Number : 500
Source IP Address (Sig ): 188.8.131.52
Destn SIP Req Addr:Port : 172.31.1.47:24040
Destn SIP Resp Addr:Port : 172.31.1.47:24040
Destination Name : 172.31.1.47
The SIP phone you're using has an IP of 172.31.1.47, same subnet as FE 0/0. If X-Lite is set up with a proxy/GW of 172.31.1.1...then this explains why the phone can get to CCME. But I bet you cannot reach 172.31.1.47 using a source of 184.108.40.206.
Can you run a few quick tests?
do the following:
ping 172.31.1.47 source 172.31.1.1
Does that work?
ping 172.31.1.47 source 220.127.116.11
Does that work?
If you can ping 172.31.1.47 sourcing off the FE interface IP of 172.31.1.1, but not 18.104.22.168 then you have a routing config issue.
I'm assuming if you did a debug of an outbound call from an SCCP phone to the X-lite...you would see a similar issue, no response to INVITE.
If you are able to ping sourcing off 172.31.1.1, try adding the below and retesting:
voice service voip
bind all source-interface fastEthernet 0/0
If unsuccesful grab a debug ccsip message of both an outound and inbound call.