incoming called-number is not working with sip, but destination-pattern is on CME

[mercdecember]

I have setup a CME lab environment with voip.ms.  I am able to make calls in and out with no issues.  However my incoming dial-peer is only working if I have "Destination-pattern .T" setup on it, if I replace it with "incoming called-number .%", then I cannot receive calls.  Any Idea why I cannot use incoming called-number?  Below is my conifg

voice translation-rule 1
 rule 1 /^9/ //
!
voice translation-rule 2
 rule 1 /^.*/ /91XXXX1462/
!
voice translation-rule 3
 rule 1 /^91XXXX1\(...\)$/ /\1/
!
!
voice translation-profile INCOMING_CALLS
 translate called 3
!
voice translation-profile OUTGOING_CALLS
 translate calling 2
 translate called 1

dial-peer voice 7 voip
 translation-profile outgoing OUTGOING_CALLS
 destination-pattern 9[2-9]......
 session protocol sipv2
 session target dns:newyork4.voip.ms
 no voice-class sip localhost
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad
!
dial-peer voice 11 voip
 translation-profile outgoing OUTGOING_CALLS
 destination-pattern 91[2-9].........
 session protocol sipv2
 session target dns:newyork4.voip.ms
 no voice-class sip localhost
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad
!
dial-peer voice 1 voip
 translation-profile incoming INCOMING_CALLS
 destination-pattern .T
 session protocol sipv2
 session target dns:newyork4.voip.ms
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad

[mercdecember]

They are uploaded

[mercdecember]

I was reviewing the debugs, and I am seeing the issue:

*Oct  5 22:28:24.255: //41/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry:
   Total Call Count=1, Call Entry(Call Count On=FALSE, Incoming Call=FALSE)

for some reason, the incoming calls are not being recognized as incoming calls from the cisco router

[Ayodeji Okanlawon]

Well I have to tell you that this must be some kind of a software error. This call should never work. The behaviour you have with the incoming called number. is the correct one. A router should not process calls for an ip that is not its own.  That means anyone can send calls to this router and it will accept the call. This is what is checked when you use incoming called number. You see the invalid host error. The gateway checks to see if the host ip in the sip RURI (request-URI) matches any configured ip on itself. if it doesn't, the call is rejected.

I would like to investigate this a little more..

Please use destination-pattern .T and configure the ff

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

<Enable debugs, then test again.>

debug ccsip all

<Enable session capture to txt file in terminal program.> (such as Putty)

then do the ff:

terminal length 0
show logging

Attach the logs please..

[mercdecember]

Here you go

Thanks

[mercdecember]

maybe on my internet facing router I should have a nat statement like this:

ip nat source static udp 192.168.100.21 5060 int g9 5060

[mercdecember]

So you mean doing this http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/nat-tcp-sip-alg.html? ;  Could I just map the 5060 port to the wan port on my wan router?

[mercdecember]

I made the following changes

ip nat service sip udp port 5060

ip nat inside source static udp 192.168.100.21 5060 interface GigabitEthernet9 5060
ip nat inside source static tcp 192.168.100.21 5060 interface GigabitEthernet9 5060

 and I get this output debug ccsip all:

//-1/xxxxxxxxxxxx/SIP/Transport/sipSPIUpdateResponseInfo: Dialog Transaction Address 107.6.67.238,Port 5060, Transport 1, SentBy Port 5060
//-1/1BC87302802D/SIP/Info/resolve_sig_ip_address_to_bind: signaling bind address : 192.168.100.21
//-1/xxxxxxxxxxxx/SIP/Error/sipSPI_validate_own_ip_addr: ReqLine IP addr does not match with host IP addr
//-1/1BC87302802D/SIP/Error/sact_idle_new_message_invite: Invalid URL in incoming INVITE
//-1/1BC87302802D/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:100, category:100
//-1/xxxxxxxxxxxx/SIP/Info/ccsip_set_release_source_for_peer: ownCallId[-1], src[6]
//-1/1BC87302802D/SIP/Info/sipSPIUaddCcbToUASReqTable: ****Adding to UAS Request table.

anyone got any ideas?  could this be a carrier issue?

[Ayodeji Okanlawon]

This is not a carrier issue. Your nat doesn't seem to be working. The gateway is saying that the hostname in the request line doesn't match an ip on itself..

Have a look at this doc, see if it helps. I am not a security guy, so cant help much. You might want to post a new thread in the security forum on how to setup static nat for your scenario

http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13773-2.html

[mercdecember]

I created the outside source-list

ip nat outside source static udp 172.101.112.85 5060 192.168.100.21 5060 extendable

when I applied it my phone went down, do the phones use 5060?  This is my CME config:

telephony-service
 max-ephones 20
 max-dn 20
 ip source-address 192.168.100.21 port 2000
 cnf-file perphone
 max-conferences 8 gain -6
 transfer-system full-consult
 create cnf-files version-stamp Jan 01 2002 00:00:00

[mercdecember]

Everything started working after I rebooted my wan router.  I also found an issue with my cipc, but I can now receive incoming call on sip.  Attached are the configurations.

[Ayodeji Okanlawon]

Glad you go tit working,,

[Ayodeji Okanlawon]

So for calls working with destination-pattern..The CCME processes the call with its local ip address even though the Request is sent to the WAN ip address.This is really strange. Here you can see the local ip address is different from the host portion of the INVITE

000141: *Oct  7 01:56:44.367: //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads: Msg enqueued for SPI with IP addr: [107.6.67.238]:5060, local_address:[192.168.100.21]
000142: *Oct  7 01:56:44.367: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 for event 1
000143: *Oct  7 01:56:44.367: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg: context=0x4AC1437C
000144: *Oct  7 01:56:44.367: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessNewConnMsg: gConnTab=0x4AC1437C, addr=107.6.67.238, port=5060, local_addr=192.168.100.21, connid=3, transport=UDP
000145: *Oct  7 01:56:44.367: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:9142281462@74.101.112.85:63717 SIP/2.0
Via: SIP/2.0/UDP 107.6.67.238:5060;branch=z9hG4bK51730524;rport
Max-Forwards: 70
From: "9144410197" <sip:9144410197@107.6.67.238>;tag=as01f3fcb9
 

yes you will need nat to resolve this..

You will need a dedicated public IP to which all your calls will be sent to. You will then configure NAT and enable ALG on your router, to translate the public ip to the local ip of the ccme.