All,

Typical as it is, as soon as I sent the help request, I figured it out.  I had  <param name="apply-nat-acl" value="nat.auto"/> in the internal.xml, which I guess was forcing NAT on everything in the profile.  I took that out and now everything works.  That appears to break phones which talk to FS on a random source port, like the cisco, and when NOT running on a nat.  I also assumed that running FS with the --nonat would essentially stop all NAT processing. 

Thank you for OSS.  These lines of code in sofia_reg.c gave me the clue, as is_nat WAS being set in my system.

        if (is_nat && profile->local_network && switch_check_network_list_ip(network_ip, profile->local_network)) {
                if (profile->debug) {
                        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "IP %s is on local network, not seting NAT mode.\n", network_ip);
                }
                is_nat = NULL;
        }
Is there a possibility to also set is_nat = NULL when --nonat is specified on the cmdline?

Thanks again,
Matt

On 12/23/2011 11:35 AM, Matt Piermarini wrote:
Hello all,

I have been trying forever to get this Cisco 7970 to work properly with our freeswitch (latest git).  The phone will register fine, and it will make outbound calls perfectly.  The problem is with inbound calls to this phone, where FS tries to contact it on the wrong UDP port.  The entire system here is on a local lan, and NAT has been disabled via --nonat cmd line FS parameter.

Here is what it looks like when registered:

sofia status profile internal reg

Call-ID:        00181844-c24f0002-25f0dff2-c470b5a7@192.168.2.59
User:           15@x.y.com
Contact:        "user" <sip:15@192.168.2.59:5060;transport=udp;fs_nat=yes;fs_path=sip%3A15%40192.168.2.59%3A49320%3Btransport%3Dudp>
Agent:          Cisco-CP7970G/8.5.2
Status:         Registered(UDP-NAT)(unknown) EXP(2011-12-22 21:31:47) EXPSECS(724)
Host:           x.y.com
IP:             192.168.2.59
Port:           49165
Auth-User:      15
Auth-Realm:     x.y.com


FS tries to contact the phone using the fs_path, which is getting set incorrectly.  I'm not why FS thinks the fs_path should be different, as it appears the Cisco is sending proper Contact header in the sip requests/responses.
Also, we have a bunch of ATA's on the same lan which all work fine (meaning the fs_path is correct).  I tried chaning the NDLB-force-rport param in the internal context, but didn't seems to change anything.
Here are the SIP traces which show what's happening.  Any ideas of what's going on would be appreciated.

Thanks,
Matt

192.168.2.59 is the cisco phone.  
192.168.2.1 is FS (listening on port 5070).

recv 713 bytes from udp/[192.168.2.59]:49320 at 02:28:01.712338:
   ------------------------------------------------------------------------
   REGISTER sip:x.y.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.2.59:5060;branch=z9hG4bKd9e43394
   From: <sip:15@x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
   To: <sip:15@x.y.com>
   Call-ID: 00181844-c24f0002-eb21e8a8-77681214@192.168.2.59
   Max-Forwards: 70
   Date: Fri, 23 Dec 2011 02:28:00 GMT
   CSeq: 101 REGISTER
   User-Agent: Cisco-CP7970G/8.5.2
   Contact: <sip:15@192.168.2.59:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00181844c24f>";+u.sip!model.ccm.cisco.com="30006"
   Supported: (null),X-cisco-xsi-7.0.1
   Content-Length: 0
   Reason: SIP;cause=200;text="cisco-alarm:20 Name=SEP00181844C24F Load=SIP70.8-5-2S Last=phone-keypad"
   Expires: 3600

send 689 bytes to udp/[192.168.2.59]:5060 at 02:28:01.715057:
   ------------------------------------------------------------------------
   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/UDP 192.168.2.59:5060;branch=z9hG4bKd9e43394
   From: <sip:15@x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
   To: <sip:15@x.y.com>;tag=Qv2N52egZ2teH
   Call-ID: 00181844-c24f0002-eb21e8a8-77681214@192.168.2.59
   CSeq: 101 REGISTER
   User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-8059cdc 2011-12-22 14-03-32 -0600
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   WWW-Authenticate: Digest realm="x.y.com", nonce="fae142ab-8b00-4ac7-89d7-04955e8714f6", algorithm=MD5, qop="auth"
   Content-Length: 0

recv 958 bytes from udp/[192.168.2.59]:49320 at 02:28:01.725802:
   ------------------------------------------------------------------------
   REGISTER sip:x.y.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.2.59:5060;branch=z9hG4bK18d5a468
   From: <sip:15@x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
   To: <sip:15@x.y.com>
   Call-ID: 00181844-c24f0002-eb21e8a8-77681214@192.168.2.59
   Max-Forwards: 70
   Date: Fri, 23 Dec 2011 02:28:00 GMT
   CSeq: 102 REGISTER
   User-Agent: Cisco-CP7970G/8.5.2
   Contact: <sip:15@192.168.2.59:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00181844c24f>";+u.sip!model.ccm.cisco.com="30006"
   Authorization: Digest username="15",realm="x.y.com",uri="sip:x.y.com",response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",nonce="fae142ab-8b00-4ac7-89d7-04955e8714f6",cnonce="4f2a64d4",qop=auth,nc=00000001,algorithm=MD5
   Supported: (null),X-cisco-xsi-7.0.1
   Content-Length: 0
   Reason: SIP;cause=200;text="cisco-alarm:20 Name=SEP00181844C24F Load=SIP70.8-5-2S Last=phone-keypad"
   Expires: 3600

send 649 bytes to udp/[192.168.2.59]:5060 at 02:28:01.737460:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.168.2.59:5060;branch=z9hG4bK18d5a468
   From: <sip:15@x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
   To: <sip:15@x.y.com>;tag=SeN78rgQSm7Kr
   Call-ID: 00181844-c24f0002-eb21e8a8-77681214@192.168.2.59
   CSeq: 102 REGISTER
   Contact: <sip:15@192.168.2.59:5060;transport=udp>;expires=3600
   Date: Fri, 23 Dec 2011 02:28:01 GMT
   User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-8059cdc 2011-12-22 14-03-32 -0600
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Content-Length: 0

--------------- OK, so far so good.. phone is now registered..   Now look how FS tries to contact it.. sending notify's here:  Note the port it tries to use, 49320 in this case.

send 1034 bytes to udp/[192.168.2.59]:49320 at 02:28:01.837149:
   ------------------------------------------------------------------------
   NOTIFY sip:15@192.168.2.59:5060;transport=udp;fs_nat=yes;fs_path=sip:15%40192.168.2.59:49320%3Btransport%3Dudp SIP/2.0
   Via: SIP/2.0/UDP 192.168.2.1:5070;rport;branch=z9hG4bKv92r0r53rQKNa
   Route: <sip:15@192.168.2.59:49320>;transport=udp
   Max-Forwards: 70
   From: <sip:15@192.168.2.1>;tag=U07rcFjyK6KSF
   To: <sip:15@192.168.2.1>
   Call-ID: 93e179d6-a7b0-122f-d396-5254003b348b
   CSeq: 21967576 NOTIFY
   Contact: <sip:mod_sofia@192.168.2.1:5070>
   User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-8059cdc 2011-12-22 14-03-32 -0600
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Event: message-summary
   Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Subscription-State: terminated;reason=timeout
   Content-Type: application/simple-message-summary
   Content-Length: 69
  
   Messages-Waiting: no
   Message-Account: sip:15@x.y.com

The phone never responds, as FS is supposed to contact it on port 5060, but FS is trying to use the same port that phone sent is SIP messages on.  Here is a sample INVITE:

send 1229 bytes to udp/[192.168.2.59]:49320 at 02:38:15.217775:
   ------------------------------------------------------------------------
   INVITE sip:15@192.168.2.59:5060;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 192.168.2.1:5070;rport;branch=z9hG4bK0D8U748HDUc0r
   Route: <sip:15@192.168.2.59:49320>;transport=udp
   Max-Forwards: 69
   From: "x x x" <sip:11@192.168.2.1>;tag=63X9ZrB5K886e
   To: <sip:15@192.168.2.59:5060;transport=udp>
   Call-ID: 00e33727-a7b2-122f-d396-5254003b348b
   CSeq: 21967883 INVITE
   Contact: <sip:mod_sofia@192.168.2.1:5070>
   User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-8059cdc 2011-12-22 14-03-32 -0600
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Content-Type: application/sdp
   Content-Disposition: session
   Content-Length: 204
   X-FS-Support: update_display,send_info
   Remote-Party-ID: "x x x" <sip:11@192.168.2.1>;party=calling;screen=yes;privacy=off
  
   v=0
   o=FreeSWITCH 1324545412 1324545413 IN IP4 192.168.2.1
   s=FreeSWITCH
   c=IN IP4 192.168.2.1
   t=0 0
   m=audio 62482 RTP/AVP 18 0 8 101 13
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:20



_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org