All, I currently have two problems that seems to be occurring with my sipXecs.
I'm running sipXecs (4.4.0- 2011-04-19EDT11:43:17 domU-12-31-39-0E-C9-92). My ITSP is Bandtel. I'm using Polycom VVX1500 phones running 3.2.3 combined SIP application. Hold Problem =============== I've been back and forth between Polycom and Bandtel about the issue. The conclusion we have all come to, and I can verify by packet capture, that sipXbridge is NOT sending out the SDP to Bandtel when a hold is issued from the Polycom phone. Bandtel, obviously, drops the call as the carrier did not find an SDP in the invite (the invite issued by the hold). Upon review of the packet captures, I can see that the Polycom phone DOES issues the hold WITH the SDP, but after it is processed by the sipXbridge the SDP is dropped thus triggering the dropped call when the carrier notices that the invite came with no SDP. My question is relatively simple: what am I missing? Is there a setting that fixes this? Or is this something that sipXbridge isn't designed to do? It seems like relatively simple configuration problem, but I have yet to be able to figure it out. Any assistance with this issue would be greatly appreciated. ----------------------------------- Multi-Hosted SIP Trunk Problem ========================== I've also been back and forth with Bandtel on this issue. The conclusion we have come to is that Bandtel is not the problem in the sense that they are relaying all incoming and outgoing calls to our sipXecs, which has been verified by packet captures. Bandtel has given us a FQDN - proxy1.bandtel.com - for our SIP Trunk/Outgoing proxy. This FQDN resolves to two public IP addresses, who flip flop in which is primary and which is secondary. The problem occurs when we register with the ITSP. Sometimes we will register on one IP, sometimes on the other. Which ever IP address we registered at will be able to receive and send calls, but on the other, we can receive a call into the PBX, but the PBX does not send the call to the actual end user device. I believe I have worked around the issue by creating THREE separate SIP trunks. First one registers with proxy1.bandtel.com, thus either IP address could be the one register. The second one registers with the first IP and the third one registers with the second IP. I also added the two IP addresses to the "White" list on the SIP Proxy service in sipXecs. Everything works and we don't miss any calls, but I still believe this is a work around and not a solution. Has anyone experienced this before with an ITSP? Or anything similar? Is it that sipXecs is only BUILT to handle one IP address to register with an ITSP and treats anything else as a security breach, thus throwing away the call? If so, that would say that my workaround is the solution. ---------------------------------------------------- Any help/insight you can provide to me would be immensely helpful! -- William E. W. Russell Director, Systems Integration incNETWORKS, Inc. 25 James Way Long Branch, NJ 07724 Cell Phone # 732-744-6483 Work Phone # 732-508-2224
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
