The way that sipXecs works is that when sipXproxy receives the 302 Moved Temporarily with the list of phones that are to receive INVITES from sipregistrar, it starts issuing the INVITEs based on the q value. If you have a large number of phones with the same q value, be it the same extension or different extensions, sipXproxy starts sending INVITEs to that group of phones. When the first phones that receive the INVITE start responding with 100 Trying and 180 Ringing / 183 Session Progress, sipXecs starts responding to those phones and stops sending out INVITEs to the rest of the phones in the Contact list until it processes the received messages. When those messages are processed, it again start sending out INVITEs to those it has not processed.
When sipXproxy receives a 200 OK from one of the phones, it will acknowledge the message and starts sending out CANCEls to the other phones to which INVITEs have been sent. In your case, the issue may be that the forking timer or session timer has expired. This would cause sipXproxy to start sending out CANCEL messages even if the call has not been answered on a phone. Another reason could be that the Max Forwards have been exceeded. The exact number of phones where this occurs is not definitive. It is impacted by call volume, whether or not the line(s) are being monitored for BLF, and if the user is a Shared User. BLF and BLA cause the system to generate a large set of NOTIFY messages to all of the phones involved. If you have the call-ID, it is normally easier to analyze the call flow using sipx-trace / sipviewer than to use tcpdump / wireshark. Hopefully this and some of the other information on options will allow you to configure the system to meet your needs. DD -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Saturday, November 20, 2010 11:43 AM To: [email protected]; [email protected] Subject: Re: [sipx-users] Inbound Verizon Callers Polycom says never put the same line on more than 5 phones. Just because you did it doesn't mean you should. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: [email protected] <[email protected]> To: 'Discussion list for users of sipXecs software' <[email protected]> Sent: Sat Nov 20 14:40:54 2010 Subject: Re: [sipx-users] Inbound Verizon Callers I can point to at least one installation that has a hunt group with 9 Polycom's on it that are all in a hunt group with their line 3. Each phone also has their own two extension so it. It works beautifully. The devil is in the details - IF you are provisioning the same line on multiple phones, then remove that and see if the hunt group still works with your 8 phones. Can you confirm - example - Hunt group number 300 - call to 300 calls 301-308 on line one. Line two is assigned 321-328 on the phones. I think a detail of what each phone has on it will help to understand the circumstances. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Saturday, November 20, 2010 11:05 AM To: [email protected] Subject: Re: [sipx-users] Inbound Verizon Callers Create unique lines for your hunt groups and the problem will go away. Its HOW you are doing it. Tcpdumps will get you nowhere. Make sure you NEVER call the same line more than once in a hunt group and NEVER call another hunt group from a hunt group. What you are doing now is not supported by Polycom. It will also freak the heck out of the RLS system if you ask me. So stop doing it like that. :>) ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: Tony Graziano <[email protected]> To: '[email protected]' <[email protected]> Sent: Sat Nov 20 13:54:25 2010 Subject: Re: [sipx-users] Inbound Verizon Callers It is not recommended to have the same line provisioned on more than 5 polycom phones. If you are doing this, then DON'T. Polycom has a big "DON'T" on that, and it would explain a lot. Hunt group or not. Thanks for solving this mystery. The cause is not sipx or lan. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: [email protected] <[email protected]> To: Discussion list for users of sipXecs software <[email protected]> Sent: Sat Nov 20 13:50:31 2010 Subject: Re: [sipx-users] Inbound Verizon Callers @R P - It doesn't matter which phone we unplug to reduce to 7 phones, or which phone we delay the ringing. It still works with 7 or less phone, not with 8. @Michael - we have two numbers A and B. A goes to a hunt group with the 8 extensions assigned to line one of the phones, the extension being the phone number calling in. Number B goes to a user, that user is assigned to line 2 one all 8 phones. The issue is there either way. If I look at a TCP dump from the SipXecs server what I see is we recieve the invite and respond with a 100 Trying, and 180 ringing while the SipX box starts inviting the 8 phones. before some one can answer we receive a cancel, but only if all 8 phone ring a once. If we set one extension to ring if no answer, or remove the number 2 user from one phone all calls comes in fine. Bryan On Fri, Nov 19, 2010 at 3:22 AM, Michael Picher <[email protected]> wrote: > What does the inbound ringing look like? Are you trying to ring all 8 > phones at once? If so, how are you doing it? Hunt group or a separate > user > on each phone or a phantom user with forwarding to ring at the same time > on > a bunch of phones? > > Mike > > > On Thu, Nov 18, 2010 at 5:40 PM, R P Herrold <[email protected]> wrote: > >> On Thu, 18 Nov 2010, Bryan Anderson wrote: >> >> > All phones get their IP's from the DHCP server distributed >> > on the SipXecs ISO. >> >> It is not unheard of for a MAC address, which is used to try >> to ensure uniqueness of IP assigmment to be duplicated by a >> hardware vendor [I have some specialty hardware that >> intentionally does just that] ; similarly an IP assignment >> pool can sometimes be exhausted >> >> IP conflicts on a lan can cause failures. >> >> I think I would be firing up tcpdump on the monitor port of a >> switch, or setting up hubbed fabric between the DHCP server >> and the rest of the LAN, and watching the DHCP assignment >> conversations closely [port 68] as I plugged and unplugged >> units at this point >> >> something like: >> tcpdump -i eth0 -nN -xX -s 1500 port 68 >> >> see for more details: >> http://www.owlriver.com/tips/tcpdump-tech/ >> >> -- Russ herrold >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > There are 10 kinds of people in this world, those who understand binary > and > those who don't. > > [email protected] > blog: http://www.sipxecs.info > call: sip:[email protected] <sip%[email protected]> > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
