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

Arturo Bianchi · ‎12-18-2010

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:

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:PREFIXXXXXXX4@ADSL.ADSL.ADSL.110: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:PREFIXYYYYYY5@voip.provider.it>;tag=4h3y.38ph6yrwimwrrlfdt-fsmfxnfvt
To: <sip:PREFIXXXXXXX4@voip.provider.it>
Contact: "RINUX.eu" <sip:PREFIXYYYYYY5@4.5.6.184: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:PREFIXYYYYYY5@voip.provider.it>;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:PREFIXYYYYYY5@voip.provider.it>;tag=4h3y.38ph6yrwimwrrlfdt-fsmfxnfvt
To: <sip:PREFIXXXXXXX4@voip.provider.it>;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

Arturo Bianchi · ‎12-18-2010

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 · ‎12-24-2010

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 · ‎01-15-2011

Salve Arturo,

i see in your nice post this

Received: 
INVITE sip:PREFIXXXXXXX4@ADSL.ADSL.ADSL.110: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 · ‎01-16-2011

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:0776xxxxxx4@ADSL.ADSL.ADSL.110: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 · ‎01-16-2011

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#

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

Received:

INVITE sip:999111@172.16.123.1:5060 SIP/2.0

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

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

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

To: <999111>

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

Call-ID: 3CF70B99-20AF11E0-ADD1C18A-E1958C43@172.16.123.254

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: <401>

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" <401>;tag=3C2CB1A8-14F5

To: <999111>;tag=ACACB7C-2532

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

Call-ID: 3CF70B99-20AF11E0-ADD1C18A-E1958C43@172.16.123.254

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:999111@172.16.123.1:5060 SIP/2.0

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

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

To: <999111>;tag=ACACB7C-2532

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

Call-ID: 3CF70B99-20AF11E0-ADD1C18A-E1958C43@172.16.123.254

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#

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:999111@172.16.123.1:5060 SIP/2.0

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

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

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

To: <999111>

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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: <401>

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" <401>;tag=3C2DC500-1872

To: <999111>

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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:3000@10.1.10.1:5060 SIP/2.0

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

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

From: "cpic cipc" <401>;tag=ACBDEE0-1007

To: <3000>

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

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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: <401>

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: <3000>

From: "cpic cipc" <401>;tag=ACBDEE0-1007

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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: <3000>;tag=dsee67a04a

From: "cpic cipc" <401>;tag=ACBDEE0-1007

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

CSeq: 101 INVITE

Content-Length: 0

Contact: <3000>

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

Cisco-Gcid: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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" <401>;tag=3C2DC500-1872

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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: <3000>;party=called;screen=no;privacy=off

Contact: <3000>

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

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

Received:

PRACK sip:3000@172.16.123.1:5060 SIP/2.0

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

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

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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" <401>;tag=3C2DC500-1872

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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: <3000>;tag=dsee67a04a

From: "cpic cipc" <401>;tag=ACBDEE0-1007

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

CSeq: 101 INVITE

Content-Length: 184

Contact: <3000>

Content-Type: application/sdp

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

Cisco-Gcid: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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:3000@10.1.10.1:5060;transport=udp SIP/2.0

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

From: "cpic cipc" <401>;tag=ACBDEE0-1007

To: <3000>;tag=dsee67a04a

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

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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" <401>;tag=3C2DC500-1872

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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: <3000>;party=called;screen=no;privacy=off

Contact: <999111>

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:999111@172.16.123.1:5060 SIP/2.0

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

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

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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:999111@172.16.123.1:5060 SIP/2.0

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

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

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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" <401>;tag=3C2DC500-1872

To: <999111>;tag=ACBDF2C-0

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

Call-ID: 66FAAA64-20AF11E0-ADD7C18A-E1958C43@172.16.123.254

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:3000@10.1.10.1:5060;transport=udp SIP/2.0

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

From: "cpic cipc" <401>;tag=ACBDEE0-1007

To: <3000>;tag=dsee67a04a

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

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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: <3000>;tag=dsee67a04a

From: "cpic cipc" <401>;tag=ACBDEE0-1007

Call-ID: EF7DDA8-20B311E0-8192C235-44E9D59C@10.1.10.2

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 · ‎01-17-2011

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:

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 * ???
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 · ‎01-17-2011

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.

if you like send me a email (vcappucc@cisco.com) with your contact information, and we can schedule a call in order to see this with more details on a webex session?

Thank you again

Victor.-

Arturo Bianchi · ‎01-22-2011

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 · ‎01-22-2011

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:

Activate an loopback port with public IP
Modify access-list to accept any IP in the SIP message (via xxxx)
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 · ‎01-22-2011

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

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