07-27-2016 08:54 AM - edited 03-03-2019 08:18 AM
I have a problem with SIP-ALG on IOS-XE.
My setup is:
Cisco ISR4431/K9
isr4400-universalk9.03.13.02.S.154-3.S2-ext.SPA.bin
This is an Internet edge router. I want to migrate static NAT for Astersk server from old Cisco 2921. On 2921 sip-alg correctly works directly out of the box. According to this:
IOS-XE also have this feature enabled out of the box.
But when i try to move routes to SIP providers peers from 2921 to 4431 it don't work. I see that 4431 is actually perform sip processing:
C4431#sh platform hardware qfp active feature alg statistics sip l7data
SIP info pool used chunk entries number: 11
Hashindex: 940 l7_data: 0x31e24200 callid: 156108f429dd067e562123db49d91a19 wlock_cnt: 0
Hashindex: 1657 l7_data: 0x31e01980 callid: 09f5363f41c024fa52c6256a5ba535b5 wlock_cnt: 0
Hashindex: 2299 l7_data: 0x31e2f6a0 callid: 5a57acc63c899a7d35888a4a0e7d5a22 wlock_cnt: 0
Hashindex: 3074 l7_data: 0x31e20ce0 callid: 00f3cd237eb1a80236e9c6a9326dd923 wlock_cnt: 0
Hashindex: 4234 l7_data: 0x31e070a0 callid: 60ce59d54df7f1a15a79ab452f3471ff wlock_cnt: 0
Hashindex: 4620 l7_data: 0x31e2c5c0 callid: 1598a6c2541410316be248810384fac1 wlock_cnt: 0
Hashindex: 4823 l7_data: 0x31e37c80 callid: 7dad75313414101e13dd399118f1e57f wlock_cnt: 0
Hashindex: 4937 l7_data: 0x31df9c20 callid: 17675c704bb998b3625d9500625ce8a2 wlock_cnt: 0
Hashindex: 5866 l7_data: 0x31e02ec0 callid: 210c2bbe6400b4b24ccf651103c8fdfc wlock_cnt: 0
Hashindex: 7510 l7_data: 0x31dfeac0 callid: 51fa4be940246bab0de0d8f93b052d17 wlock_cnt: 0
Hashindex: 7668 l7_data: 0x31e36b80 callid: 65bf40c541aaadc17cae9815012fb3f2 wlock_cnt: 0
Unfortunately all calls are empty, SIP/SDP information is not available, but L3 headers addresses are listed, and they are correct:
C4431#sh platform hardware qfp active feature alg statistics sip l7data callid 65bf40c541aaadc17cae9815012fb3f2
Cur_sip_state: 0 prev_sip_state: 0
num_of_media_line: 0 sip_patterns: 0x70100
client_proxy_addr: 0.0.0.0 server_proxy_addr: 0.0.0.0
client_contact_addr: 0.0.0.0 addr_vrfid: 0
server_contact_addr: 0.0.0.0 addr_vrfid: 0
client_record_addr: 0.0.0.0 addr_vrfid: 0
xlated_client_record_addr: 0.0.0.0 xlated_client_record_port: 0
server_record_addr: 0.0.0.0 addr_vrfid: 0
client_proxy_port: 0 server_proxy_port: 0
client_contact_port: 0 server_contact_port: 0
client_record_port: 0 server_record_port: 0
expire_time: 0 session_expire_time: 0
client_portlist addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
server_port_list addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
client_portlist addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
server_port_list addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
client_portlist addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
server_port_list addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
client_portlist addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
server_port_list addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
client_portlist addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
server_port_list addr: 0.0.0.0 port_start: 0 port_num: 0 vrfid: 0
source_addr: <CORRECT ASTERISK SERVER ADDRESS> destination_addr: <CORRECT SIP PROVIDER ADDRESS>
tw_timeout: 180 last_accessed: 3213911565
sip_info_flags: 0x0 callid_idx: 7668
callid: 65bf40c541aaadc17cae9815012fb3f2
As a result, SIP/SDP embedded addresses are not translated, and provider sent back "401 Unauthorized" message
SIP-ALG statistics also show some counters incrementing:
C4431# sh platform hardware qfp active feature alg statistics sip
SIP info pool used chunk entries number: 12
RECEIVE
Register: 6047 -> 200-OK: 134
Invite: 4 -> 200-OK: 0 Rexmit-invite 0
Update: 0 -> 200-OK: 0
Bye: 0 -> 200-OK: 0
Subscribe: 0 -> 200-OK: 0
Refer: 0 -> 200-OK: 0
Prack: 0 -> 200-OK: 0
Trying: 2 Ringing: 0 Ack: 4
Info: 0 Cancel: 1 Sess Prog: 2
Message: 0 Notify: 0
Publish: 0 Options: 1061
1xx: 0 2xx: 0
OtherReq: 0 OtherOk: 823 3xx-6xx: 5917
Events
Null dport: 0 Media Port Zero: 0
Malform Media: 0 No Content Length: 0
Cr Trunk Chnls: 919 Del Trunk Chnls: 907
start trunk timer: 919 restart trunk timer: 1087
stop trunk timer: 4 trunk timer timeout: 903
Cr dbl entry: 0 Del dbl entry: 0
Cr dbl cfg entry: 0 Del dbl cfg entry: 0
start dbl trig tmr: 0 restart dbl trig tmr: 0
stop dbl trig tmr: 0 dbl trig timeout: 0
start dbl blk tmr: 0 restart dbl blk tmr: 0
stop dbl blk tmr: 0 dbl blk tmr timeout: 0
start dbl idle tmr: 0 restart dbl idle tmr: 0
stop dbl idle tmr: 0 dbl idle tmr timeout: 0
Media Addr Zero: 0 Need More Data: 0
SIP PKT Alloc: 13996 SIP PKT Free: 13996
SIP MSG Alloc: 0 SIP MSG Free: 0
Errors
Create Token Err: 0 Add portlist Err: 0
Invalid Offset: 0 Invalid Pktlen: 0
Free Magic: 1 Double Free: 0
Sess Retmem Failed: 0 Sess Malloc Failed 0
Pkt Retmem Failed: 0 Pkt Malloc Failed: 0
Msg Retmem Failed: 0 Msg Malloc Failed: 0
Bad Format: 0 Invalid Proto: 0
Add ALG state Fail: 0 No Call-id: 0
Parse SIP Hdr Fail: 0 Parse SDP Fail: 0
Error New Chnl: 0 Huge Size: 0
Create Failed: 0 Not SIP Msg: 0
Writeback Errors
Offset Err: 0 PA Err: 0
No Info: 0
In nat translations it seems to be correct (this is test dynamic translation now, but static with preserved inside global port 5060 show same overral picture):
C4431#sh ip nat translations outside <SIP PROVIDER ADDRESS> verbose
Pro Inside global Inside local Outside local Outside global
udp X.X.X.X:22890 X.X.X.X:5060 X.X.X.X:5060 X.X.X.X:5060
create: 07/27/16 14:31:13, use: 07/27/16 18:18:03, timeout: 00:09:31
Map-Id(In): 2
Appl type: sip
Mac-Address: 0000.0000.0000 Input-IDB: Port-channel2.301
entry-id: 0x31c3a960, use_count:1
debug alg all - dont show any output at all
When i researched for this, i encountered many info about ZBF inspection along with SIP-ALG. But i dont believe that in IOS-XE SIP-ALG must use ZBF inspection to work correctly. Or i'm wrong?
I suppose that this is defect in current image, but maybe i dont catch something?
08-01-2016 07:42 AM
Actually, SIP-ALG is working. I'm seeing this from packet dumps, but it works somewhat differently in IOS-XE than in IOS. So, i will turn it off, and see how asterisk will do it alone.
08-22-2016 05:43 PM
ALG, by default, is enabled. With my Asterisk setup, my voice service provider do all the ALG work internally so I've been advised to disable ALG in my end.
03-22-2019 04:12 AM
Hi did you manage to get your issues sorted? I have an issue with a new ISR 1112 where it looks as if ALG is working even though it has been disabled. When I use an old 887VA router it works fine, move to ISR1112 with the same BB and VOIP provider I call into a hunt group and only one phone rings. It looks like an ALG issue though I have applied a "no nat service sip udp 5060" and "no nat service sip tcp 5060" which is supposed to turn off SIP ALG. Another thing I found different between the IOS 887VA and the IOS XE ISR1112 is the default port range for dynamic NAT, the 887VA starts at 1024 whereas the ISR begins at 5074, I thought that this would be the problem and could be getting blocked by an upstream firewall, I changed the ISR portblock to start at 1024 and still hasn't resolved my issues.
04-05-2019 06:17 AM
Hi Stuart,
Did you find a fix to the issue? I suspect we may have the same problem..
Thanks
Matt
05-28-2019 04:22 AM
Hi Matt,
still not fixed, I have sent the router to my BB and VOIP service provider to see if they can locate the problem. PBX is sending the correct SIP Invites though we are not seeing them at the router WAN port?
Very strange behaviour
07-25-2019 07:27 AM
I think that we have now fixed this issue, the maximum MTU size for the dialer interface on a Cisco 1100 ISR is 1492 allowing an extra 8 bytes for PPPoE header bringing it up to 1500 bytes MTU. The SIP headers from our service provider were about 1508 bytes which are classified as mini jumbo frames and therefore being dropped. Our Service provider has now reduced the packet header size to 1300 ish bytes and we no longer have the issue.
05-18-2020 06:53 AM
Hi there,
sorry to reply to an old thread, but did you ever find out why the ALG on the ISR11xx did not turn off as expected. I’m seeing same issue.
thanks
05-18-2020 07:21 AM
You have the same problem as I did? My issue turned out to be the size of the SIP headers and the fact that the router wouldn't forward mini jumbos whereas older routers like the 887 would. work around was getting the service provider to reduce the size of the SIP headers which in turn reduce the packet size to below the MTU of 1500.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide