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