<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Seems to have been effected by an unidentified defect. Setting the inside interface MTU to the default MTU of 1500 resolved the issue. <BR><BR>--- On <B>Tue, 1/18/11, ash AD <I><commo_ssg_31f@yahoo.com></I></B> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><BR>From: ash AD <commo_ssg_31f@yahoo.com><BR>Subject: Re: [cisco-voip] SCCP NAT Question<BR>To: "Max Pierson" <nmaxpierson@gmail.com><BR>Cc: cisco-voip@puck.nether.net<BR>Date: Tuesday, January 18, 2011, 11:48 AM<BR><BR>
<DIV id=yiv1547640752>
<TABLE id=yiv1547640752bodyDrftID class=yiv1547640752 border=0 cellSpacing=0 cellPadding=0>
<TBODY>
<TR>
<TD style="FONT-FAMILY: arial; FONT-SIZE: 10pt" id=yiv1547640752drftMsgContent>Thanks for the reply max. The phones are not terminating on the 2811; so, no signalling directly to the 2811 as would be in a CME type deployment. I did also do a 1-fo-1 NAT to attempt to overcome broken NAT. I use the "ip nat inside source static" command set. I didn't increase the PAT translation window since using 1-to-1 static NATs for each phone didn't seem to work. I did increase the SCCP inspection window to 30 min for skinny. I went thru 5 versions of the 12.4(24)T train (T thru T4) and all seem to have the same symptom. <BR><BR>--- On <B>Tue, 1/18/11, Max Pierson <I><nmaxpierson@gmail.com></I></B> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><BR>From: Max Pierson <nmaxpierson@gmail.com><BR>Subject: Re: [cisco-voip] SCCP NAT Question<BR>To: "ash AD" <commo_ssg_31f@yahoo.com><BR>Cc: cisco-voip@puck.nether.net<BR>Date: Tuesday, January 18, 2011, 4:45 AM<BR><BR>
<DIV id=yiv1547640752yiv1956836858>
<DIV>Hi Ash,</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>First off, can you confirm your signaling proto from the 2811 to the CM (SIP, H.323, etc) ?? Second, what are the NAT metrics set to (as in timeout values, etc, so how long does the nat process keep the entry valid (default or did u make changes)?   Bugs are possible in the "T" train as well  ;)</DIV>
<DIV><BR></DIV>
<DIV>There are a few caveats when using H.323 and NAT (at least since my older CM days and 12.3 IOS). As you stated, you're "inspecting" SCCP traffic. What does your "show" output commands say about the inspection??</DIV>
<DIV><BR></DIV>
<DIV>My end solution was to do a "one-to-one static nat translation called by a route-map" to the CM Pub and Sub's to resolve the issue, but I need to know a little more about your environment.</DIV>
<DIV><BR></DIV>
<DIV>Regards,</DIV>
<DIV>M</DIV>
<DIV>
<DIV><BR>
<DIV class=yiv1547640752yiv1956836858gmail_quote>On Mon, Jan 17, 2011 at 10:10 PM, ash AD <SPAN dir=ltr><<A href="http://us.mc1301.mail.yahoo.com/mc/compose?to=commo_ssg_31f@yahoo.com" rel=nofollow target=_blank>commo_ssg_31f@yahoo.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=yiv1547640752yiv1956836858gmail_quote>
<TABLE border=0 cellSpacing=0 cellPadding=0>
<TBODY>
<TR>
<TD vAlign=top>
<DIV>Have phones being NAT'd that continue to reboot as if they lose registeration. Router is a Cisco 2811 running 12.4(24)T4 Adv Ent Services. There is NAT between the CallManager and three 7941 SCCP phones on the LAN side of the router. The phones are running SCCP 8.3(5). The router is doing PAT using its public IP'd interface. An IP inspect policy set to inspect SCCP is applied on the egress direction of the public IP'd interface. If the phones are placed on the same IP subnet as the outside interface with public IPs, the register and maintain registration. So, this WAN segment has full IP access to the CM. Any advise or expirience with over coming this issue.</DIV>
<DIV> </DIV>
<DIV>-Pete</DIV></TD></TR></TBODY></TABLE><BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="http://us.mc1301.mail.yahoo.com/mc/compose?to=cisco-voip@puck.nether.net" rel=nofollow target=_blank>cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel=nofollow target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></DIV></BLOCKQUOTE></TD></TR></TBODY></TABLE></DIV></BLOCKQUOTE></td></tr></table><br>