SIP Trace Question / NAT one way audio problem.
Hi all, I seem to have fallen off the list! No mail since 7/26/2013. Have I made someone mad?? :) I have also been blissfully running with ISSUES what so ever since that time. I have a NATed client with PERIODIC one way audio. The client end has a Cisco 220W router with SIP ALG disabled. The phones are CISCO 504Gs and Polycom 330s(?), basciallt the same as everywhere else we have phones. I did a sofia global sip trace on for a while and captured the output. After writing an app to sort those sip packets into logical stream files, I dug in to the SIP conversations. This has left me with som questions for the people who know these things: 1. I found all my phones are REGISTERing every 23 seconds! That seems absurd TO ME, so where have I screwed that up/where do I set it and what is a reasonable number? 2. The only difference I see in the SIP packets from my working phone and these non-working ones is of course NAT related. The working phone's REGISTER looks like this: recv 757 bytes from udp/[WW.XX.YY.93]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP WW.XX.YY.93:5063;branch=z9hG4bK-238fcc8b;rport But the failing phones look like this: recv 801 bytes from udp/[AA.BB.CC.38]:5104 at 17:53:40.693691: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP 10.2.2.239:5104;branch=z9hG4bKb374d6507894B431 The response is still sent to [AA.BB.CC.38]:5104 I guess first, IS THAT A PROBLEM? So, can anyone share any insight into the CISCO 220W config that I might be missing? Why would it only be a periodic problem? Could this be a problem where one end is using a wider range of rports than the other supports? Thanks, Sean --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re-registering every 23 seconds isnt that big of a deal if the phones are behind nat, sometimes this is needed due to the way NAT happens on UDP with various routers. There is no way to track the start/end of the session w/out using an ALG. I have seen some NAT routers require a re-reg interval around 15 seconds which is a bit excessing On the issue w/ the non-working ones is you¹ll notice the rport on the one that¹s working... On the ones that arent working they arent specifying rport... If those are the polycoms look for NDLB force rport setting and set it to safe... That¹s a special mode for the polycoms... Check the wiki for more NAT handling examples K On 12/5/13 8:36 PM, "Sean P Devoy" <sdevoy@bizfocused.com> wrote:
Hi all,
I seem to have fallen off the list! No mail since 7/26/2013. Have I made someone mad?? J
I have also been blissfully running with ISSUES what so ever since that time.
I have a NATed client with PERIODIC one way audio. The client end has a Cisco 220W router with SIP ALG disabled. The phones are CISCO 504Gs and Polycom 330s(?), basciallt the same as everywhere else we have phones.
I did a sofia global sip trace on for a while and captured the output. After writing an app to sort those sip packets into logical stream files, I dug in to the SIP conversations. This has left me with som questions for the people who know these things:
1. I found all my phones are REGISTERing every 23 seconds! That seems absurd TO ME, so where have I screwed that up/where do I set it and what is a reasonable number?
2. The only difference I see in the SIP packets from my working phone and these non-working ones is of course NAT related. The working phone¹s REGISTER looks like this:
recv 757 bytes from udp/[WW.XX.YY.93]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP WW.XX.YY.93:5063;branch=z9hG4bK-238fcc8b;rport
But the failing phones look like this:
recv 801 bytes from udp/[AA.BB.CC.38]:5104 at 17:53:40.693691:
------------------------------------------------------------------------
REGISTER sip: <MYDOMAIN.COM> SIP/2.0
Via: SIP/2.0/UDP 10.2.2.239:5104;branch=z9hG4bKb374d6507894B431
The response is still sent to [AA.BB.CC.38]:5104
I guess first, IS THAT A PROBLEM?
So, can anyone share any insight into the CISCO 220W config that I might be missing?
Why would it only be a periodic problem? Could this be a problem where one end is using a wider range of rports than the other supports?
Thanks, Sean
<http://www.avast.com/> This email is free from viruses and malware because avast! Antivirus <http://www.avast.com/> protection is active.
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org G+ ClueCon : http://fs0.us/cluecon-gplus FB ClueCon : http://fs0.us/cluecon-fb G+ FreeSwitch : http://fs0.us/freeswitch-gplus FB FreeSWITCH : http://fs0.us/freeswitch-fb Twitter : @FreeSWITCH_WIRE irc.freenode.net #freeswitch
I set the linksys spas to have a ping of 15 seconds, but not to re register every 15 seconds! When I see constant register attempts, it always means that the 401 was not received so the register never completes. Are these phones actually successfully registered? -Avi On Dec 6, 2013 4:47 AM, "Ken Rice" <krice@freeswitch.org> wrote:
Re-registering every 23 seconds isnt that big of a deal if the phones are behind nat, sometimes this is needed due to the way NAT happens on UDP with various routers. There is no way to track the start/end of the session w/out using an ALG. I have seen some NAT routers require a re-reg interval around 15 seconds which is a bit excessing
On the issue w/ the non-working ones is you’ll notice the rport on the one that’s working...
On the ones that arent working they arent specifying rport... If those are the polycoms look for NDLB force rport setting and set it to safe... That’s a special mode for the polycoms...
Check the wiki for more NAT handling examples K
On 12/5/13 8:36 PM, "Sean P Devoy" <sdevoy@bizfocused.com> wrote:
Hi all,
I seem to have fallen off the list! No mail since 7/26/2013. Have I made someone mad?? J
I have also been blissfully running with ISSUES what so ever since that time.
I have a NATed client with *PERIODIC* one way audio. The client end has a Cisco 220W router with SIP ALG disabled. The phones are CISCO 504Gs and Polycom 330s(?), basciallt the same as everywhere else we have phones.
I did a sofia global sip trace on for a while and captured the output. After writing an app to sort those sip packets into logical stream files, I dug in to the SIP conversations. This has left me with som questions for the people who know these things:
1. I found all my phones are REGISTERing every 23 seconds! That seems absurd TO ME, so where have I screwed that up/where do I set it and what is a reasonable number?
2. The only difference I see in the SIP packets from my working phone and these non-working ones is of course NAT related. The working phone’s REGISTER looks like this:
recv 757 bytes from udp/[WW.XX.YY.93]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP WW.XX.YY.93:5063;branch=z9hG4bK-238fcc8b;rport
But the failing phones look like this:
recv 801 bytes from udp/[AA.BB.CC.38]:5104 at 17:53:40.693691:
------------------------------------------------------------------------
REGISTER sip: <MYDOMAIN.COM> SIP/2.0
Via: SIP/2.0/UDP 10.2.2.239:5104;branch=z9hG4bKb374d6507894B431
The response is still sent to [AA.BB.CC.38]:5104
I guess first, IS THAT A PROBLEM?
So, can anyone share any insight into the CISCO 220W config that I might be missing?
Why would it only be a periodic problem? Could this be a problem where one end is using a wider range of rports than the other supports?
Thanks, Sean
------------------------------ <http://www.avast.com/> This email is free from viruses and malware because avast! Antivirus <http://www.avast.com/> protection is active.
------------------------------ _________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org G+ ClueCon : http://fs0.us/cluecon-gplus FB ClueCon : http://fs0.us/cluecon-fb G+ FreeSwitch : http://fs0.us/freeswitch-gplus FB FreeSWITCH : http://fs0.us/freeswitch-fb Twitter : @FreeSWITCH_WIRE irc.freenode.net #freeswitch
_________________________________________________________________________ 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
Hi Avi, Thanks for the reply, nice to "hear" from you again. You too Ken. FYI: I do have NDLB force rport set to TRUE, I will change to safe. My Cisco 504G has been working like a champ for like a year or so, and I just noticed in the sip trace it appears to REGISTER every 23 seconds. Maybe I am reading this wrong. I don't see any NAK w/ nonce and re-REGISTER. Also, the CSeq DOES increment, so it appears to have gotten the response. It seems to me the CSeq stays the same if the sender does not get a response at all. Here is my SIP trace extract for a WORKING CISCO 504G: recv 757 bytes from udp/[7x.1xx.1xx.9x]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip:xyz.mydomain.com SIP/2.0 Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-238fcc8b;rport From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: "BFIS" <sip:220@xyz.mydomain.com> Call-ID: 92b82661-3cbfddb2@10.10.40.50 CSeq: 627972 REGISTER Max-Forwards: 70 Authorization: Digest username="220",realm="xyz.mydomain.com",nonce="7ccf6076-769a-4857-9f53-30808 b2a4e61",uri="sip:xyz.mydomain.com",algorithm=MD5,response="b3ec391477f137bf af2393c97b4e0f21",qop=auth,nc=0000010e,cnonce="49035914" Contact: "BFIS" <sip:220@7x.1xx.1xx.9x:5063>;expires=3600 User-Agent: Cisco/SPA504G-7.5.4 Content-Length: 0 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE ------------------------------------------------------------------------ send 615 bytes to udp/[7x.1xx.1xx.9x]:5063 at 17:53:12.168173: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-238fcc8b;rport=5063 From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: "BFIS" <sip:220@xyz.mydomain.com>;tag=pS3teKg2aNtgj Call-ID: 92b82661-3cbfddb2@10.10.40.50 CSeq: 627972 REGISTER Contact: <sip:220@7x.1xx.1xx.9x:5063>;expires=30 Date: Wed, 04 Dec 2013 17:53:12 GMT User-Agent: FreeSWITCH-mod_sofia/1.2.9+git~20130518T213043Z~4fc1369a1b Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Content-Length: 0 ------------------------------------------------------------------------ send 769 bytes to udp/[7x.1xx.1xx.9x]:5063 at 17:53:13.987120: ------------------------------------------------------------------------ OPTIONS sip:220@7x.1xx.1xx.9x:5063 SIP/2.0 Via: SIP/2.0/UDP 66.241.102.41;rport;branch=z9hG4bKZvvNXpHcSeKQS Max-Forwards: 70 From: <sip:mod_sofia@66.241.102.41:5060>;tag=1vSB2v98aQFyH To: <sip:220@xyz.mydomain.com> Call-ID: 5f13a1c3-814d-4f48-837a-b906e5288b00_92b82661-3cbfddb2@10.10.40.50 CSeq: 61471088 OPTIONS Contact: <sip:mod_sofia@66.241.102.41:5060> User-Agent: FreeSWITCH-mod_sofia/1.2.9+git~20130518T213043Z~4fc1369a1b Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Length: 0 ------------------------------------------------------------------------ recv 451 bytes from udp/[7x.1xx.1xx.9x]:5063 at 17:53:14.054668: ------------------------------------------------------------------------ SIP/2.0 200 OK To: <sip:220@xyz.mydomain.com>;tag=dcdb8ee2502b328ei0 From: <sip:mod_sofia@66.241.102.41:5060>;tag=1vSB2v98aQFyH Call-ID: 5f13a1c3-814d-4f48-837a-b906e5288b00_92b82661-3cbfddb2@10.10.40.50 CSeq: 61471088 OPTIONS Via: SIP/2.0/UDP 66.241.102.41;branch=z9hG4bKZvvNXpHcSeKQS;rport=5060 Server: Cisco/SPA504G-7.5.4 Content-Length: 0 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE ------------------------------------------------------------------------ recv 412 bytes from udp/[7x.1xx.1xx.9x]:5063 at 17:53:14.733495: ------------------------------------------------------------------------ NOTIFY sip:xyz.mydomain.com SIP/2.0 Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-b8f05783;rport From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: <sip:xyz.mydomain.com> Call-ID: f5c9e863-5d603f02@10.10.40.50 Max-Forwards: 70 Contact: "BFIS" <sip:220@7x.1xx.1xx.9x:5063> Event: keep-alive User-Agent: Cisco/SPA504G-7.5.4 Content-Length: 0 ------------------------------------------------------------------------ send 741 bytes to udp/[7x.1xx.1xx.9x]:5063 at 17:53:14.733877: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-b8f05783;rport=5063 From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: <sip:xyz.mydomain.com>;tag=rcZ5aBDt83Fcc Call-ID: f5c9e863-5d603f02@10.10.40.50 Contact: <sip:gw+didlogic@66.241.102.41:5060;transport=udp;gw=didlogic> User-Agent: FreeSWITCH-mod_sofia/1.2.9+git~20130518T213043Z~4fc1369a1b Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Length: 0 ------------------------------------------------------------------------ recv 412 bytes from udp/[7x.1xx.1xx.9x]:5063 at 17:53:29.805194: ------------------------------------------------------------------------ NOTIFY sip:xyz.mydomain.com SIP/2.0 Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-ef6775c6;rport From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: <sip:xyz.mydomain.com> Call-ID: f5c9e863-5d603f02@10.10.40.50 Max-Forwards: 70 Contact: "BFIS" <sip:220@7x.1xx.1xx.9x:5063> Event: keep-alive User-Agent: Cisco/SPA504G-7.5.4 Content-Length: 0 ------------------------------------------------------------------------ send 741 bytes to udp/[7x.1xx.1xx.9x]:5063 at 17:53:29.805669: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-ef6775c6;rport=5063 From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: <sip:xyz.mydomain.com>;tag=Dajeg3e4BZ3mF Call-ID: f5c9e863-5d603f02@10.10.40.50 Contact: <sip:gw+didlogic@66.241.102.41:5060;transport=udp;gw=didlogic> User-Agent: FreeSWITCH-mod_sofia/1.2.9+git~20130518T213043Z~4fc1369a1b Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: precondition, path, replaces Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Length: 0 ------------------------------------------------------------------------ recv 757 bytes from udp/[7x.1xx.1xx.9x]:5063 at 17:53:35.236173: ------------------------------------------------------------------------ REGISTER sip:xyz.mydomain.com SIP/2.0 Via: SIP/2.0/UDP 7x.1xx.1xx.9x:5063;branch=z9hG4bK-4d49f459;rport From: "BFIS" <sip:220@xyz.mydomain.com>;tag=163202d2fcedcf5eo0 To: "BFIS" <sip:220@xyz.mydomain.com> Call-ID: 92b82661-3cbfddb2@10.10.40.50 CSeq: 627973 REGISTER Max-Forwards: 70 Authorization: Digest username="220",realm="xyz.mydomain.com",nonce="7ccf6076-769a-4857-9f53-30808 b2a4e61",uri="sip:xyz.mydomain.com",algorithm=MD5,response="f0da4a7351b8d978 20cfa98a1669a695",qop=auth,nc=0000010f,cnonce="49035914" Contact: "BFIS" <sip:220@7x.1xx.1xx.9x:5063>;expires=3600 User-Agent: Cisco/SPA504G-7.5.4 Content-Length: 0 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE ------------------------------------------------------------------------ And so it continues. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Avi Marcus Sent: Thursday, December 05, 2013 10:55 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] SIP Trace Question / NAT one way audio problem. I set the linksys spas to have a ping of 15 seconds, but not to re register every 15 seconds! When I see constant register attempts, it always means that the 401 was not received so the register never completes. Are these phones actually successfully registered? -Avi On Dec 6, 2013 4:47 AM, "Ken Rice" <krice@freeswitch.org <mailto:krice@freeswitch.org> > wrote: Re-registering every 23 seconds isnt that big of a deal if the phones are behind nat, sometimes this is needed due to the way NAT happens on UDP with various routers. There is no way to track the start/end of the session w/out using an ALG. I have seen some NAT routers require a re-reg interval around 15 seconds which is a bit excessing On the issue w/ the non-working ones is you'll notice the rport on the one that's working... On the ones that arent working they arent specifying rport... If those are the polycoms look for NDLB force rport setting and set it to safe... That's a special mode for the polycoms... Check the wiki for more NAT handling examples K On 12/5/13 8:36 PM, "Sean P Devoy" <sdevoy@bizfocused.com <http://sdevoy@bizfocused.com> > wrote: Hi all, I seem to have fallen off the list! No mail since 7/26/2013. Have I made someone mad?? :) I have also been blissfully running with ISSUES what so ever since that time. I have a NATed client with PERIODIC one way audio. The client end has a Cisco 220W router with SIP ALG disabled. The phones are CISCO 504Gs and Polycom 330s(?), basciallt the same as everywhere else we have phones. I did a sofia global sip trace on for a while and captured the output. After writing an app to sort those sip packets into logical stream files, I dug in to the SIP conversations. This has left me with som questions for the people who know these things: 1. I found all my phones are REGISTERing every 23 seconds! That seems absurd TO ME, so where have I screwed that up/where do I set it and what is a reasonable number? 2. The only difference I see in the SIP packets from my working phone and these non-working ones is of course NAT related. The working phone's REGISTER looks like this: recv 757 bytes from udp/[WW.XX.YY.93]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM <http://MYDOMAIN.COM> > SIP/2.0 Via: SIP/2.0/UDP WW.XX.YY.93:5063;branch=z9hG4bK-238fcc8b;rport But the failing phones look like this: recv 801 bytes from udp/[AA.BB.CC.38]:5104 at 17:53:40.693691: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM <http://MYDOMAIN.COM> > SIP/2.0 Via: SIP/2.0/UDP 10.2.2.239:5104;branch=z9hG4bKb374d6507894B431 The response is still sent to [AA.BB.CC.38]:5104 I guess first, IS THAT A PROBLEM? So, can anyone share any insight into the CISCO 220W config that I might be missing? Why would it only be a periodic problem? Could this be a problem where one end is using a wider range of rports than the other supports? Thanks, Sean _____ <http://www.avast.com/> This email is free from viruses and malware because avast! Antivirus <http://www.avast.com/> protection is active. _____ _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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 -- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org G+ ClueCon : http://fs0.us/cluecon-gplus FB ClueCon : http://fs0.us/cluecon-fb G+ FreeSwitch : http://fs0.us/freeswitch-gplus FB FreeSWITCH : http://fs0.us/freeswitch-fb Twitter : @FreeSWITCH_WIRE irc.freenode.net <http://irc.freenode.net> #freeswitch _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto: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 <mailto: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 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Just a follow up with the confirmed resolution. I had copied the FS Directory entries for these Polycom Phones from a CISCO phone setup. That setup specified: <param name="NDLB-force-rport" value="true"/> Ken adviced to change that for Polycom Phones to: <param name="NDLB-force-rport" value="safe"/> The customer emailed me today to say the problem has been resolved. Thanks for all who sent their thoughts. Extra thanks to Ken. Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Ken Rice Sent: Thursday, December 05, 2013 9:48 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] SIP Trace Question / NAT one way audio problem. Re-registering every 23 seconds isnt that big of a deal if the phones are behind nat, sometimes this is needed due to the way NAT happens on UDP with various routers. There is no way to track the start/end of the session w/out using an ALG. I have seen some NAT routers require a re-reg interval around 15 seconds which is a bit excessing On the issue w/ the non-working ones is you'll notice the rport on the one that's working... On the ones that arent working they arent specifying rport... If those are the polycoms look for NDLB force rport setting and set it to safe... That's a special mode for the polycoms... Check the wiki for more NAT handling examples K On 12/5/13 8:36 PM, "Sean P Devoy" <sdevoy@bizfocused.com> wrote: [cid:image001.gif@01CEFD76.90387370] Hi all, I seem to have fallen off the list! No mail since 7/26/2013. Have I made someone mad?? :) I have also been blissfully running with ISSUES what so ever since that time. I have a NATed client with PERIODIC one way audio. The client end has a Cisco 220W router with SIP ALG disabled. The phones are CISCO 504Gs and Polycom 330s(?), basciallt the same as everywhere else we have phones. I did a sofia global sip trace on for a while and captured the output. After writing an app to sort those sip packets into logical stream files, I dug in to the SIP conversations. This has left me with som questions for the people who know these things: 1. I found all my phones are REGISTERing every 23 seconds! That seems absurd TO ME, so where have I screwed that up/where do I set it and what is a reasonable number? 2. The only difference I see in the SIP packets from my working phone and these non-working ones is of course NAT related. The working phone's REGISTER looks like this: recv 757 bytes from udp/[WW.XX.YY.93]:5063 at 17:53:12.164203: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP WW.XX.YY.93:5063;branch=z9hG4bK-238fcc8b;rport But the failing phones look like this: recv 801 bytes from udp/[AA.BB.CC.38]:5104 at 17:53:40.693691: ------------------------------------------------------------------------ REGISTER sip: <MYDOMAIN.COM> SIP/2.0 Via: SIP/2.0/UDP 10.2.2.239:5104;branch=z9hG4bKb374d6507894B431 The response is still sent to [AA.BB.CC.38]:5104 I guess first, IS THAT A PROBLEM? So, can anyone share any insight into the CISCO 220W config that I might be missing? Why would it only be a periodic problem? Could this be a problem where one end is using a wider range of rports than the other supports? Thanks, Sean ________________________________ <http://www.avast.com/> This email is free from viruses and malware because avast! Antivirus <http://www.avast.com/> protection is active. ________________________________ _________________________________________________________________________ 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 -- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org G+ ClueCon : http://fs0.us/cluecon-gplus FB ClueCon : http://fs0.us/cluecon-fb G+ FreeSwitch : http://fs0.us/freeswitch-gplus FB FreeSWITCH : http://fs0.us/freeswitch-fb Twitter : @FreeSWITCH_WIRE irc.freenode.net #freeswitch
participants (4)
-
Avi Marcus
-
Ken Rice
-
Sean Devoy
-
Sean P Devoy