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 <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/
