I get the same problem, even if I just use an ATA and skip the PBX entirely.
-Mark On 11/30/11 3:31 PM, "Tony Graziano" <[email protected]> wrote: Signalling looks fine. You need to verify they "like" the PAI you are sending and they are going to respond to you when you register from port 5080. When you send a call it originates on port 5080 to them on port 5060. What is happening is the call setup takes more than 2 seconds before it is ack'ed from them, so the call is timing out. Their signalling is arriving as the call is cancelled by the system. Will you verify you are sending the public address in the gateway setup and that vitelity has any nat function turned off? On Wed, Nov 30, 2011 at 4:38 PM, Tim Ingalls <[email protected]> wrote: I've been working with Vitelity on an issue that is perplexing. I used to have (until yesterday) a static IP with Qwest/CenturyLink. The only way I could get Vitelity trunks to work reliably was to go into the Vitelity portal and input an IP address in their portal. That made it so that it didn't use normal SIP registration for authentication. As soon as I removed the static IP setting and just went with regular SIP registration, I was unable to make any outbound calls. After changing the ITSP address from outbound.vitelity.net <http://outbound.vitelity.net> to sip7.vitelity.net <http://sip7.vitelity.net> (in all settings in the gateway configuration) it would ring and connect the call, but there was no audio on the inbound side. The other side could hear fine. I changed nothing in my firewall port forwarding rules. We changed NAT settings for the RTP stream and made matching changes to the port forwarding rules on my router, but it still didn't help. The only thing that fixed things was to enter my temporary IP address into the Vitelity portal's IP routing setting again. We put everything else back the way it was in sipXecs. The tech I'm talking about says he thinks there is something wrong with the SIP messaging going back and forth, but he's going to show it to an engineer to figure out what could be wrong. I've attached the trace for a call example that failed. Can anyone take a look and see what they think is wrong? I don't know if it is truly an incompatibility between platforms or maybe something I did wrong in my settings. The Vitelity guy says they'd be willing to talk to the sipXecs/Ezuce engineers to work on this issue. He said there are several other issues they'd like to solve, but they have had problems finding someone on the sipXecs side to interface with. Is there anyone who could do that? This could help a lot of people, I think. -- Thanks! Mark Theis Chief Technology Officer Southern California Telephone & Energy - SCT&E 1278 Glenneyre Street #76 Laguna Beach, CA 92651 Direct: 951.294.5112 | Cell: 951.545.1013 | Fax: 949.715.5511 http://socaltelephone.com [cid:3407325237_51114662]
<<inline: image.png>>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
