×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

UC500 behind a Cisco 800 series: SIP/2.0 400 Bad Request - 'Invalid Host'

Unanswered Question
Dec 18th, 2010
User Badges:

Hi!


I would like to understand how to solve this problem, or clarify if a limit related to the configuration on the router that does not hide the public IP in the SIP message or an error / limit on the UC500... Network design is as follows:

uc-lo.png

The UC500 is properly recorded to an external ITSP and able to adequately perform outgoing calls; but but does not accept any incoming call because it is clearly not happy to receive something in INVITE; here's the exchange with a call made from the iPhone with a SIP client connected directly to the ITSP:


INVITE

Received:
INVITE sip:[email protected]:1027 SIP/2.0

Record-Route: <sip:1.2.3.21;lr=on;ftag=4h3y.38ph6yrwimwrrlfdt-fsmfxnfvt>

Via: SIP/2.0/UDP 1.2.3.21;branch=z9hG4bK7b85.44bcbf45.0

Via: SIP/2.0/UDP 192.168.2.129:5060;received=192.168.2.129;rport=1027;branch=z9hG4bKPjrdpf7fopu3rtuvbcdbubimhpvp9j5v6m

Max-Forwards: 16

From: "RINUX.eu" <sip:[email protected]>;tag=4h3y.38ph6yrwimwrrlfdt-fsmfxnfvt

To: <sip:[email protected]>

Contact: "RINUX.eu" <sip:[email protected]:1027>

Call-ID: bv0fkgffarfbraasdh1hrcbj7q6r3pav

CSeq: 12897 INVITE

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Supported: replaces, 100rel, timer, norefersub

Session-Expires: 1800

Min-SE: 90

User-Agent: iSip v4.7/iPhoneOS

Content-Type: application/sdp

Content-Length: 281

Remote-Party-ID: <sip:[email protected]>;party=calling;id-type=subscriber;screen=yes;privacy=off

P-hint: Geo Onnet from Prepaid


v=0

o=- 3499582265 3499582265 IN IP4 192.168.2.129

s=isipsdp

c=IN IP4 1.2.3.14

t=0 0

m=audio 50496 RTP/AVP 0 8 113 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:113 iLBC/8000

a=fmtp:113 mode=30

a=sendrecv

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15



REPLY

Sent:
SIP/2.0 400 Bad Request - 'Invalid Host'

Via: SIP/2.0/UDP 1.2.3.21;branch=z9hG4bK7b85.44bcbf45.0,SIP/2.0/UDP 192.168.2.129:5060;received=192.168.2.129;rport=1027;branch=z9hG4bKPjrdpf7fopu3rtuvbcdbubimhpvp9j5v6m

From: "RINUX.eu" <sip:[email protected]>;tag=4h3y.38ph6yrwimwrrlfdt-fsmfxnfvt

To: <sip:[email protected]>;tag=E84B3A4-592

Date: Wed, 24 Nov 2010 10:10:53 GMT

Call-ID: bv0fkgffarfbraasdh1hrcbj7q6r3pav

CSeq: 12897 INVITE

Allow-Events: telephone-event

Reason: Q.850;cause=100

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0





...UC500 don't accept INVITE; perhaps because of the call is still present within the public IP of the router that has a static NAT rule? What the Cisco 800 is not ALG capable firewall or it is a matter of setup on one of the two devices? I bring up the public IP to UC500 or I could try an alternative solution???



Where do I begin????


Thanks.



73,

Arturo

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Arturo Bianchi Sat, 12/18/2010 - 03:39
User Badges:

I forgot to mention... on router cfg I see 'ip nat piggyback-support sip all-messages router 100' and if I turn on another SIP server I have no problems receiving calls! It is a trouble or a lower permissiveness of the SIP stack on UC500???


73,

Arturo.

Arturo Bianchi Fri, 12/24/2010 - 06:29
User Badges:

Hi!


I moved the thread from "LAN, Switching and Routing"  to "SBCS - UC 500 " because ultimately it is the UC500 which does not like the call! I did a reboot for scruple of the equipment, nothing new... :-(


Happy holidays.



73,

Arturo

vcappucc Sat, 01/15/2011 - 15:29
User Badges:
  • Bronze, 100 points or more


Salve Arturo,


i see in your nice post this


Received: 
INVITE sip:[email protected]:1027 SIP/2.0


and it seems that your wan interface is in the 1.2.3.0 network,  i will try to add just for testing


int lo10000

ip add ADSL.ADSL.ADSL.110 255.255.255.255

end


and see what happens.


however one of the many good way to help in determine what is going on. is to have following debugs running in your router when a call fails


en

conf ter

no logg mon

no logg con

logg buff 30000000 7

voice iec syslog

end

u all

clear logg

deb ccsip all

deb voice ccapi inout


and  reproduce your issue, when done collect the debugs

ter le 0

show logg


the voice iec syslog and with the others debugs, will hopefully indicate where the issue is, and if you can attach this to the thread the debugs shown so expert from community can comment as well.


Thank you

Victor

Arturo Bianchi Sun, 01/16/2011 - 02:35
User Badges:

Good Sunday Victor,

I could not resist, I went to see what was happening by making the loopback (although I do not like the idea of creating a black hole for the traffic to that ip)! Yes, something has changed but little more ... now I get a good result :-(

Sent:
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP ITSP.ITSP.ITSP.21;branch=z9hG4bK9dab.ebcf9017.0,SIP/2.0/UDP 192.168.2.129:5060;received=192.168.2.129;rport=1033;branch=z


oh well... I remember that you had found something about the fact that the invitation was a double 'Via':


Received:
INVITE sip:[email protected]:1024 SIP/2.0
Record-Route:
Via: SIP/2.0/UDP ITSP.ITSP.ITSP.21;branch=z9hG4bK9dab.ebcf9017.0
Via: SIP/2.0/UDP 192.168.2.129:5060;received=192.168.2.129;rport=1033;branch=z9hG4bKPj0remqgmglgl31uwsmxap04zwuhtm6hl5


...I remember correctly?


Thanks.



Note: when I have a bit of time, I proceed with debugging. I just wanted to bring this first result on the fly.



73,

Arturo

vcappucc Sun, 01/16/2011 - 05:58
User Badges:
  • Bronze, 100 points or more

Good Day Arturo,


I do not see why you are creating a black hole can you shed more light on this thought please, now based on your design and with the configurations suggested, you just are spoofing your IP in order to avoid the Invalid Host SIP Message, or there is a route for this ip to null0?, the only issue i can see here if the UC is a router to reach that network, he will answer that request for traffic moving from the inside.


Now the double VIA issue you describe was fixed in IOS contained on software pack 8.0.1,  for me it seems to be now that the told fraud control is doing his job,  but i can not  sure since there is no show run or debug posted, if this is the case and if you enable voice iec syslog, you should see why the invite received failed.


please find a not working and  working example in the following copy and past from the console:




R1#

R1#

002632: *Jan 16 14:22:33.843: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3130

Remote-Party-ID: "cpic cipc" ;party=calling;screen=no;privacy=off

From: "cpic cipc" ;tag=3C2CB1A8-14F5

To:

Date: Sun, 16 Jan 2011 13:56:23 GMT

Call-ID: [email protected]

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 0177260042-0548344288-2192439140-2041101732

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1295186183

Contact:

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 69

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Lengt

R1#h: 277


v=0

o=CiscoSystemsSIP-GW-UserAgent 9624 9628 IN IP4 172.16.123.254

s=SIP Call

c=IN IP4 172.16.123.254

t=0 0

m=audio 17792 RTP/AVP 0 101 19

c=IN IP4 172.16.123.254

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000

a=ptime:20


002633: *Jan 16 14:22:33.847: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 500 Internal Server Error

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3130

From: "cpic cipc" ;tag=3C2CB1A8-14F5

To: ;tag=ACACB7C-2532

Date: Sun, 16 Jan 2011 14:22:33 GMT

Call-ID: [email protected]

Timestamp: 1295186183

CSeq: 101 INVITE

Allow-Events: telephone-event

Reason: Q.850;cause=63

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



002634: *Jan 16 14:22:33.851: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3130

From: "cpic cipc" ;tag=3C2CB1A8-14F5

To: ;tag=ACACB7C-2532

Date: Sun, 16 Jan 2011 13:56:23 GMT

Call-ID: [email protected]

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0



R1#

R1#ter le 10   

R1#show run | b voice source

voice source-group .

access-list 12

!

voice translation-rule 1234

rule 1 /.*/ /3000/

!

voice translation-rule 2002

rule 1 /^6/ //

!


R1#show ip access-list 12

Standard IP access list 12

    10 deny   any log

R1#conf ter

Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#ip access-list st 12

R1(config-std-nacl)#1 permit 172.16.123.254  !this is on the top via, you will need to add all trusted "via" ip addresses.

R1(config-std-nacl)#end

R1#

R1#

R1#

002635: *Jan 16 14:23:37.755: %SYS-5-CONFIG_I: Configured from console by console

R1#

002636: *Jan 16 14:23:44.331: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3146E3

Remote-Party-ID: "cpic cipc" ;party=calling;screen=no;privacy=off

From: "cpic cipc" ;tag=3C2DC500-1872

To:

Date: Sun, 16 Jan 2011 13:57:34 GMT

Call-ID: [email protected]

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 0881540733-0548344288-2192832356-2041101732

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1295186254

Contact:

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 69

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Len

R1#gth: 277


v=0

o=CiscoSystemsSIP-GW-UserAgent 1357 8506 IN IP4 172.16.123.254

s=SIP Call

c=IN IP4 172.16.123.254

t=0 0

m=audio 19032 RTP/AVP 0 101 19

c=IN IP4 172.16.123.254

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000

a=ptime:20


002637: *Jan 16 14:23:44.343: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3146E3

From: "cpic cipc" ;tag=3C2DC500-1872

To:

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Timestamp: 1295186254

CSeq: 101 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



002638: *Jan 16 14:23:44.351: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DC15D2

Remote-Party-ID: "cpic cipc" ;party=calling;screen=no;privacy=off

From: "cpic cipc" ;tag=ACBDEE0-1007

To:

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 0881540733-0548344288-2192832356-2041101732

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1295187824

Contact:

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 68

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 237


v=0

o=CiscoSystemsSIP-GW-UserAgent 486 2539 IN IP4 10.1.10.2

s=SIP Call

c=IN IP4 10.1.10.2

t=0 0

m=audio 16384 RTP/AVP 0 101

c=IN IP4 10.1.10.2

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20


002639: *Jan 16 14:23:44.363: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DC15D2

To:

From: "cpic cipc" ;tag=ACBDEE0-1007

Call-ID: [email protected]

CSeq: 101 INVITE

Content-Length: 0

Timestamp: 1295187824



002640: *Jan 16 14:23:44.423: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DC15D2

To: ;tag=dsee67a04a

From: "cpic cipc" ;tag=ACBDEE0-1007

Call-ID: [email protected]

CSeq: 101 INVITE

Content-Length: 0

Contact:

Allow: INVITE, BYE, CANCEL, ACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO

Cisco-Gcid: [email protected]



002641: *Jan 16 14:23:44.423: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3146E3

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Timestamp: 1295186254

CSeq: 101 INVITE

Require: 100rel

RSeq: 8697

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: ;party=called;screen=no;privacy=off

Contact:

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



002642: *Jan 16 14:23:44.431: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

PRACK sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK315BE2

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 13:57:34 GMT

Call-ID: [email protected]

CSeq: 102 PRACK

RAck: 8697 101 INVITE

Allow-Events: telephone-event

Max-Forwards: 70

Content-Length: 0



002643: *Jan 16 14:23:44.431: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK315BE2

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 102 PRACK

Content-Length: 0



002644: *Jan 16 14:23:44.479: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DC15D2

To: ;tag=dsee67a04a

From: "cpic cipc" ;tag=ACBDEE0-1007

Call-ID: [email protected]

CSeq: 101 INVITE

Content-Length: 184

Contact:

Content-Type: application/sdp

Allow: INVITE, BYE, CANCEL, ACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO

Cisco-Gcid: [email protected]


v=0

o=CUE 12731173 2 IN IP4 10.1.10.1

s=SIP Call

c=IN IP4 10.1.10.1

t=0 0

m=audio 21058 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15



002645: *Jan 16 14:23:44.487: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:[email protected]:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DD1A86

From: "cpic cipc" ;tag=ACBDEE0-1007

To: ;tag=dsee67a04a

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0



002646: *Jan 16 14:23:44.491: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK3146E3

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

Timestamp: 1295186254

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: ;party=called;screen=no;privacy=off

Contact:

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 215


v=0

o=CiscoSystemsSIP-GW-UserAgent 1712 6761 IN IP4 172.16.123.1

s=SIP Call

c=IN IP4 172.16.123.1

t=0 0

m=audio 16408 RTP/AVP 0 19

c=IN IP4 172.16.123.1

a=rtpmap:0 PCMU/8000

a=rtpmap:19 CN/8000

a=ptime:20


002647: *Jan 16 14:23:44.495: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

ACK sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK31623E7

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 13:57:34 GMT

Call-ID: [email protected]

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0



002648: *Jan 16 14:23:45.879: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK317690

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 13:57:34 GMT

Call-ID: [email protected]

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1295186255

CSeq: 103 BYE

Reason: Q.850;cause=16

Content-Length: 0



002649: *Jan 16 14:23:45.887: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 172.16.123.254:5060;branch=z9hG4bK317690

From: "cpic cipc" ;tag=3C2DC500-1872

To: ;tag=ACBDF2C-0

Date: Sun, 16 Jan 2011 14:23:45 GMT

Call-ID: [email protected]

Server: Cisco-SIPGateway/IOS-12.x

Timestamp: 1295186255

CSeq: 103 BYE

Reason: Q.850;cause=16

Content-Length: 0



002650: *Jan 16 14:23:45.887: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:[email protected]:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DE142

From: "cpic cipc" ;tag=ACBDEE0-1007

To: ;tag=dsee67a04a

Date: Sun, 16 Jan 2011 14:23:44 GMT

Call-ID: [email protected]

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1295187825

CSeq: 102 BYE

Reason: Q.850;cause=16

Content-Length: 0



002651: *Jan 16 14:23:45.895: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK8DE142

To: ;tag=dsee67a04a

From: "cpic cipc" ;tag=ACBDEE0-1007

Call-ID: [email protected]

CSeq: 102 BYE

Content-Length: 0



also please refer to this link https://supportforums.cisco.com/docs/DOC-983 for the double via issue.


Thank you and and i hope you also have a wonderful Sunday

Victor.-

Arturo Bianchi Mon, 01/17/2011 - 09:10
User Badges:

Victor,
you are a Wizard!!!
Do not need debugging, you receive directly the electromagnetic waves directly :-)  I've driven... I remembered that this damn CCA change the access-list according to their data, even after I have changed from the CLI (Do not ask me when, because of course I had already changed and I found it again with the values placed on CCA... actually I forgot to give it a try trivial: remove the list of IP on CCA panel to see if I get the same result). The problem seems to be linked precisely to the fact that in addition the SIP server's IP in INVITE shall present the most disparate IP based on the type of call! So we can't restrict incoming call IP :-(


In practice, I am in a situation that calls coming from certain IPs based on the type of sender: incoming calls from landline phones are from a pool of IP and calls from mobile phones from other IP; and thus far nothing difficult, I subsequent attempts to collect the IP addresses that are a finite number but for calls incoming from IP phones or other trunk connected to the same ITSP it becomes impossible.... I could be with any private and public IP in the header of INVITE. So I understand that I have no solution but to let our guard down and open the device in the world:


access-list 2 remark CCA_SIP_SOURCE_GROUP_ACL_EXTERNAL
access-list 2 remark SDM_ACL Category=1
access-list 2 permit any


Now,
finally I do not have an internal error but I did not go away :-(


004660: Jan 17 08:20:31.176: //30977/7B914B2E9251/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden


Sorry,
this time I did not quote configurations or debug output but as usual I did some testing on the fly, from one activity to another. Maybe I have a bit of calm on Saturday and do various tests looking a little better what happens! I also want to review that document well that I have pointed out, maybe it can help even more in search of the problem....


Among other things I want to understand various issues which escape me:


  1. Why am I forced to use a loopback rather than tell the SIP stack to accept messages coming also to a certain IP or at least to * ???
  2. Why do I have difficulty reconciling incoming connections from the ITSP with a list of the restriction made to prevent fraudulent use I suppose... What does the stack is confused because of the double 'VIA' ???


73,

Arturo

vcappucc Mon, 01/17/2011 - 10:31
User Badges:
  • Bronze, 100 points or more

Hi Arturo,


Thank you for your nice post,  this is something  i have seen before when dealing with another router in the front that is not configured with SIP-ALG.


now for this part:



004660: Jan 17 08:20:31.176: //30977/7B914B2E9251/SIP/Msg/ccsipDisplayMsg: Sent:SIP/2.0 403 Forbidden


Since the request is sent from the UC, and based on this http://www.faqs.org/rfcs/rfc3261.html 



21.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
 
my question for you is if the UC is configured as a proxy and is not allowing the UA to register or to do a call?
i do not have your running configuration so i can not be sure, most of this problem i see is that the CME receives the 403, and the most common issue is  based on authentication, or that the ext on the request is not mapped to the correct DID as expected by the provider, and so on.
Thank you again
Victor.-
Arturo Bianchi Sat, 01/22/2011 - 04:09
User Badges:

vcappucc ha scritto:


if you can attach this to the thread the debugs shown so expert from community can comment as well.




Hi Victor,

I captured the debug of a call. I put my glasses and watched the log ... but I can not find the inspiration to go forward :-(


I do some further checks after lunch, if I will use on the wild-card, thanks.


On after lunch test I observe that:


015656: Jan 22 14:32:04.528: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:   Try with the demoted called number 07765550444

015657: Jan 22 13:32:04.528: %VOICE_IEC-3-GW: Application Framework Core: Internal Error (Toll fraud call rejected): IEC=1.1.228.3.31.0 on callID 37466 GUID=D5CA960B256211E09624E2CC1028A790

015658: Jan 22 14:32:04.532: //37466/D5CA960B9624/CCAPI/ccCallSetContext:   Context=0x898A93B0

015659: Jan 22 14:32:04.532: //37466/D5CA960B9624/CCAPI/cc_process_call_setup_ind:   >>>>CCAPI handed cid 37466 with tag 3003 to app "_ManagedAppProcess_TOLLFRAUD_APP"


73,

Arturo.


Update from bianchi.a @ 14:32

Arturo Bianchi Sat, 01/22/2011 - 06:17
User Badges:

bianchi.a ha scritto:


On after lunch test I observe that:


015657: Jan 22 13:32:04.528: %VOICE_IEC-3-GW: Application Framework Core: Internal Error (Toll fraud call rejected): IEC=1.1.228.3.31.0 on callID 37466 GUID=D5CA960B256211E09624E2CC1028A790





Well to evaluate the impact in terms of security... However in the end I disabled the toll fraud...


voice service voip
ip address trusted list
  ipv4 0.0.0.0 0.0.0.0


...and now I receive any calls, but at what price? Let me know if there is an alternative??????



These are the three things that I had to act by forcing an extreme access to all:


  1. Activate an loopback port with public IP
  2. Modify access-list to accept any IP in the SIP message (via xxxx)
  3. Modify voice service voip to revert toll fraud (accept any ip)


...which way I could try an alternative?



Note:

The point is that, as I indicated earlier, the call takes on different combinations of IP based on the type of phone used (fixed, mobile, VoIP), I use the proxy and see if I can harmonize the different header, then reactivating a restriction on incoming IP? Moreover, now I still have some problems in handling the calls from VoIP phones that are already within the network and are connected to the same ITSP but it is a minor problem that postponement for another time. The snakes and ladders?


73,

Arturo.

vcappucc Sat, 01/22/2011 - 10:29
User Badges:
  • Bronze, 100 points or more

Hello Arturo,


I agree with you, this router should not be  speaking blindly with everyone.


here are some of the many features to avoid told fraud:


http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucme/srnd/design/guide/security.html#wp1086108


Disable secondary dial tone on voice ports

Use access control lists (ACLs) to allow only explicitly valid sources of calls.

Explicit incoming and outgoing dial peers

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps4625/products_tech_note09186a00809dc487.shtml#h323


Explicit destination patterns—Use dial peers with more granularity than .T for destination patterns to block disallowed off-net call destinations.


Use translation rules to manipulate dialed digits before calls connect to the PSTN to provide better control over who may dial PSTN destinations.


Use voice source groups http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftgwrepg.html#wp1173893


or use the new 15.(1)2T  a toll-fraud prevention feature

https://supportforums.cisco.com/docs/DOC-12228

in order to avoid speaking to unknown sources,


voice service voip                 

   ip address trustedlist          

   ipv4 []  


Here you will put a valid IP address, this is easily found in the VIA of the Invite received and  the call should only be from a trusted source or sources in case of having multiple SIP Trunks or if the provider have multiple SIP Gateways, for this you will need to check with your ITSP and get these IPs. please refer to the following document  written by one of Cisco's SIP Guro Mr. Maulik Shah https://supportforums.cisco.com/docs/DOC-9832  which explains more in details


Thank you and have a very good weekend

Actions

This Discussion

Related Content