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!
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to