[Freeswitch-users] Help with a Cisco 7970 phone.
Matt Piermarini
matt at partlytrue.com
Sat Dec 24 05:19:08 MSK 2011
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 at 192.168.2.59
> User: 15 at x.y.com
> Contact: "user"
> <sip:15 at 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 at x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
> To: <sip:15 at x.y.com>
> Call-ID: 00181844-c24f0002-eb21e8a8-77681214 at 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 at 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 at x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
> To: <sip:15 at x.y.com>;tag=Qv2N52egZ2teH
> Call-ID: 00181844-c24f0002-eb21e8a8-77681214 at 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 at x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
> To: <sip:15 at x.y.com>
> Call-ID: 00181844-c24f0002-eb21e8a8-77681214 at 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 at 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 at x.y.com>;tag=00181844c24f0002a0bb4968-7b2b7dd4
> To: <sip:15 at x.y.com>;tag=SeN78rgQSm7Kr
> Call-ID: 00181844-c24f0002-eb21e8a8-77681214 at 192.168.2.59
> CSeq: 102 REGISTER
> Contact: <sip:15 at 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 at 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 at 192.168.2.59:49320>;transport=udp
> Max-Forwards: 70
> From: <sip:15 at 192.168.2.1>;tag=U07rcFjyK6KSF
> To: <sip:15 at 192.168.2.1>
> Call-ID: 93e179d6-a7b0-122f-d396-5254003b348b
> CSeq: 21967576 NOTIFY
> Contact: <sip:mod_sofia at 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 at 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 at 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 at 192.168.2.59:49320>;transport=udp
> Max-Forwards: 69
> From: "x x x" <sip:11 at 192.168.2.1>;tag=63X9ZrB5K886e
> To: <sip:15 at 192.168.2.59:5060;transport=udp>
> Call-ID: 00e33727-a7b2-122f-d396-5254003b348b
> CSeq: 21967883 INVITE
> Contact: <sip:mod_sofia at 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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111223/a957d49f/attachment-0001.html
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list