I made an independent query. One of the guru's deeply involved in RFC's and wrote a few himself that are being used in sipx chimed in and confirmed the behavior you are seeing is not compliant. It's troubling FR sees more of the transaction than the server is seeing, which explains how out of touch (pardon the pun) they are with this whole thing.
No, the carrier can't send a re-INVITE until it has responded to your INVITE. See RFC 3261 section 14: Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. So I think you need to get FR to fix it or go somewhere that works. 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/
