You should be able to adjust the ports within sipXecs to accommodate that provider. Although, there has been a lot of chatter on this list with regards to people not being able to set things up with Flowroute. You might want to go back into the archives to see how they worked around the issue. I think Tony is right though, I think a bunch of them moved to other carriers.
I didn't read it as there was a third party provider, but that Flowroute was the downstream vendor from your invites. But it is not entirely clear the way he worded the response. I guess the question is this - can he adhere to your request or not? From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Monday, September 12, 2011 3:43 PM To: [email protected]; Discussion list for users of sipXecs software Cc: [email protected] Subject: Re: [sipx-users] FW: Incoming external call does not complete successfully but there you go. its one of their downstream vendors. they are not even in control of their own network. how embarassing to admit it that way. FRAME 67 & 68. We don't offer anything but 30504. The FR downstream vendor is re-inviting media we aren't offering. IT IS A FR problem. RUN AWAY! When kids can't play and get along, the kid who owns the toys take theirs and go home. I suggest you get a real vendor and take your toys with you. On Mon, Sep 12, 2011 at 6:30 PM, Marcel Manzardo <[email protected]> wrote: Here is what I got back from Flowroute: when the call sets up FROm sipx it asks for port 30504 for rtp. the guys at FR keep shoving 10204 back as a reinvite This is fairly ambiguous as the RTP port range your system would like to communicate on is sent in your offer (INVITE), however, the RTP port the downstream vendor would like to receive audio on is sent in the answer (SIP/200). I'm not sure where Flowroute is forcing or "shoving" a specific RTP port for the sipX system to use. Any help is greatly appreciated. Cheers, Marcel From: Marcel Manzardo [mailto:[email protected]] Sent: Monday, September 12, 2011 2:45 PM To: 'Discussion list for users of sipXecs software' Cc: '[email protected]' Subject: RE: [sipx-users] FW: Incoming external call does not complete successfully Hi Toni, Thank you VERY much for your feedback. We really appreciate it!!! We forwarded your information to Flowroute and we will change our config. We'll post back shortly. Cheers, Marcello From: Tony Graziano [mailto:[email protected]] Sent: Monday, September 12, 2011 2:35 PM To: [email protected]; Discussion list for users of sipXecs software Cc: [email protected] Subject: Re: [sipx-users] FW: Incoming external call does not complete successfully and you neglected to say the RTP port is where the conflict is... when the call sets up FROm sipx it asks for port 30504 for rtp. the guys at FR keep shoving 10204 back as a reinvite. Usually that is acceptable or not acceptable. the only time you would reinvite after an offer is after a call is established. So revisit your FR config. Also, you are sending them a PING as a keepalive and they dont like that either. so what you have is a disagreement on an acceptable SDP of what rtp port/range to use. On Mon, Sep 12, 2011 at 5:19 PM, Tony Graziano <[email protected]> wrote: explain your trunk config. why is port 5160 being used? On Mon, Sep 12, 2011 at 4:59 PM, Marcel Manzardo <[email protected]> wrote: Some more tracing was completed and we got the following feedback from Flowroute. - The issue is not related to NAT. - According to Flowroute's tracing, sipX is rejecting a reINVITE with a SIP/491 for certain calls (the ones that fail) which is incorrect. - Attached is trace information and any feedback would be greatly appreciated. Cheers, Marcello From: [email protected] [mailto:[email protected]] On Behalf Of Marcel Manzardo Sent: Thursday, July 07, 2011 3:29 PM To: 'Discussion list for users of sipXecs software' Subject: Re: [sipx-users] FW: Incoming external call does not complete successfully Thank you for your suggestions. We did sign up for VoIP.ms and will do some testing as soon as they enable our new account. We are still investigating what exactly is going on with Flowroute and their engineering is analyzing the traces at this point. I will report back as soon as possible. From: Tony Graziano [mailto:[email protected]] Sent: Thursday, July 07, 2011 11:15 AM To: [email protected]; Discussion list for users of sipXecs software Subject: Re: [sipx-users] FW: Incoming external call does not complete successfully it is how the calls are being sent in (or anchored). I never use an ITSP that handles NAT for me. I think if you took 5 minutes to get an account at voip.ms and configured it properly, you would find that it works (as long as you disable NAT in the account settings). I would ask flowroute if they have a way to disable it (in the vent their portal does not offer the option). On Thu, Jul 7, 2011 at 2:11 PM, Marcel Manzardo <[email protected]> wrote: For some reason our replies seem to get stuck somewhere. Here is another try. We did numerous test and the issue boils down to NAT. - Flowroute (our SIP Service Provider) provides NAT and it cannot be turned off. - Incoming calls work until they are transferred for a second time e.g. Attendant -> Hunt Group -> Other Attendant -> Mailbox - sipX uses a re-invite for the second transfer which is not supported by Flowroute. - if we move the sipX outside the internal network everything works as intended. - we also tried a second sipX outside the network but were not able to route incoming calls to the internal sipX - we tried several routers and it is not a firewall issue. - we also tried using two NICs, one with public IP and one with internal IP. But there registration issues and it is not officially supported. - Flowroute suggested to set the contact header from the internal IP to the public IP. Not sure how to do that??? There are two reasons why we would like to keep the sipX internal: - auto provisioning of the phones works only if sipX is internal - we are much more vulnerable to attacks if the sipX is external Does anybody have any suggestions on how to get around this NAT issue. Any help is greatly appreciated. Thanks, Marcello -----Original Message----- From: Marcel Manzardo [mailto:[email protected]] Sent: Friday, June 24, 2011 6:28 AM To: 'Discussion list for users of sipXecs software' Subject: RE: [sipx-users] Incoming external call does not complete successfully Sorry for the delay. Our reply got held by the moderator because the attachment was too big... Here is the rest of the info including the siptrace: - Our firewall type is NATed with outbound ports set to static so no port manipulation. - Additional info about the failed call: The call is a one way/no audio call. Incoming external caller still has an active call until caller hangs up. Any help is greatly appreciated Thanks Marcello -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcel Manzardo Sent: Tuesday, June 21, 2011 3:24 PM To: 'Discussion list for users of sipXecs software' Subject: Re: [sipx-users] Incoming external call does not complete successfully Thank you very much for all the feedback. We will provide a SIP trace as soon as possible. Here is some additional info: - The only difference between a failed call flow and a successful call flow is that in the case of the successful call, the caller is an internal user calling the autoattendant. In the failed call an incoming "external" call is directed to the same autoattendant via the DID and the call fails after the second leg. - We are using SIP trunks from Flowroute. - We are connected via a pfSense firewall with QoS enabled; we have a static IP (I will be able to provide more info shortly) Thanks Marcello -----Original Message----- From: Tony Graziano [mailto:[email protected]] Sent: Tuesday, June 21, 2011 1:29 PM To: Discussion list for users of sipXecs software Cc: [email protected] Subject: Re: [sipx-users] Incoming external call does not complete successfully that pcap is useless. it shows an ip "248" and another "222", there are only two packets and there is a registration attempt. You can't tell if it is successful, and none of the packets are from sipx itself. What we all would like to see if a siptrace as George pointed out. In the interim, please make sure you describe your call flow according to the failed call. I don't think an internal "successful" call would be much help here. Also, please describe your gateway (type and schema). I.e. Grandstream HT386 FXO, Audicocodes, Patton, etc. or siptrunk through provider "abc" with firewall configured as "type"... On Tue, Jun 21, 2011 at 4:21 PM, George Niculae <[email protected]> wrote: > > > On Tue, Jun 21, 2011 at 10:50 PM, Marcel Manzardo > <[email protected]> > wrote: >> >> We are running SIPx ver 4.4. Internal calls follow call flow >> successfully but external call does not. We might be missing a >> parameter? Here are the call flows: >> >> Internal Call Scenario: >> >> 1. USER Extension 401(BEN) calls General Auto Attendant(x380) 2. >> General Auto Attendant picks up call and USER chooses option 2(Sales >> Hunt Group x 352) 3. Sales Hunt Group rings extensions 400,401,404 4. >> No extensions answers and Sales Hunt Group and falls back to >> extension 382(Sales Auto Attendant) 5. Sales Auto Attendant answers >> call and user chooses option 4(General Mailbox x393) 6. Call is >> successful USER is able to leave voicemail >> >> External Call Scenario: >> 1. External caller calls General Auto Attendant(DID 18888850205 >> ext380) 2. General Auto Attendant picks up call and USER chooses >> option 2(Sales Hunt Group x 352) 3. Sales Hunt Group rings internal >> extensions 400,401,404 4. No internal extensions answers and Sales >> Hunt Group and falls back to extension 382(Sales Auto Attendant) 5. >> Sales Auto Attendant answers call and external caller chooses option >> 4(General Mailboxx393) 6. Call is Unsuccessful and External caller is >> still connected but dead air. >> >> tcpdumps are attached. > > Can you provide also a snapshot or a call flow to be analyzed with > sipviewer (http://wiki.sipfoundry.org/display/sipXecs/Display+SIP+message+flow+using+S ipviewer)? > George > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 _______________________________________________ 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/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices! -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices! _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices!
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
