(the picture was for todd because he always likes my grade school drawings)
On Mon, Sep 12, 2011 at 7:47 PM, Tony Graziano <[email protected] > wrote: > The invite originated from sipx and specified port 30504. the DOWNSTREAM > provider did a reinvite for a port in the 10000 range. This is JUST this one > provider for that route. The next LD number that goes through a different > downstream provider can use and try to force an entirely different range. FR > is not the provider, they are sitting there passively pointing at your box > and saying its YOU when its their lack of command and control over their > (non) network. They just THINK they are the provider. > > Staying with them and working around one of their vendors is multiple > problems waiting to happen. It will happen again, and again, and again... in > the meantime how much time are you spending when another provider sets up > and works in 5 minutes? > > sipx ---> flowroute --->downstream route provider ---> pstn <-----> > | > <--------------------------------------------- > > see who is missing return path? > > take your toys and go... > > > On Mon, Sep 12, 2011 at 6:49 PM, Todd Hodgen <[email protected]> wrote: > >> 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/ >> > > > > -- > ====================== > 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 > > <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 <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/
