I forgot to mention I had sent profiles several times before over a 
period of several months on all the sipX components in an attempt to fix 
the previous problems, to no avail. What essentially fixed the issue was 
clearing out and re-entering all of the intranet information in 
System>>Internet Calling and then resending profiles on everything.

Tony Graziano wrote:
>
>
> On Sat, Oct 31, 2009 at 5:58 PM, Josh Patten <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Well it seems I found out why this was happening, and it was
>     related to
>     sipXbridge and the media relay.
>
>     Even though I had my domains and subnets defined in System>>Internet
>     Calling, sipX was sending all my sip and media session to my sipX
>     installations' external address (1-to-1 NAT) which then sent them
>     to the
>     necessary devices. The reason this was happening is because for some
>     reason neither my intranet domains or subnets settings had actually
>     taken effect since the day I installed the system. Here is what I
>     did to
>     fix the system:
>
>     Go to System>>Servers>>"server.domain.tld">>Confgure. From there I
>     disabled SIP Trunking and after that I resent the server profile and
>     restarted the server. At that point I was still having media path
>     issues
>     with an Asterisk server that I host some custom applications on. I
>     changed the RTP port values in the NAT area of the server and then
>     went
>     and redid all of my intranet settings in System>>Internet Calling,
>     resent server profiles, re-enabled SIP trunking (after installing
>     patch17), resent server profiles, and restarted the server completely
>     (warm reboot). After doing all of that I was able to make a 1.5 hour
>     phone call over a VPN connection with no audio issues or hangup
>     issues.
>
>
>     Josh Patten wrote:
>     > OK, here is my snapshot and tcpdump (links, no file attachments):
>     >
>     >
>     
> http://www.filefactory.com/file/a07ef89/n/sipx-snapshot-it_ippbx_co_brazos_tx_us_tar_gz
>     >
>     > http://www.filefactory.com/file/a07egb8/n/sipx-tcpdump_cap_bz2
>     >
>     > Seems now the calls are being one-wayed anywhere from 25-35 minutes,
>     > time varies on each call.
>     >
>     > Happy hunting. Thanks for your time.
>     >
>     > M. Ranganathan wrote:
>     >>
>     >>
>     >> On Tue, Oct 27, 2009 at 11:49 PM, Josh Patten
>     <[email protected] <mailto:[email protected]>
>     >> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>     >>
>     >>     It's is the weirdest thing; Using sipXbridge between sipX
>     and my
>     >>     Adtran
>     >>     TA 908e, which is on the same subnet as my sipX installation,
>     >> randomly
>     >>     causes one-way audio. I am using sipXbridge patch17. The
>     original
>     >>     4.0.2
>     >>     sipXbridge would only occasionally have a one way audio
>     problem, but
>     >>     when I implemented patch14 I had a lot more issues with one way
>     >> audio
>     >>     and dropped calls, and patch17 made the one way audio
>     consistent for
>     >>     each call albeit at different times throughout the call.
>     >> Sometimes the
>     >>     call would go for 10 minutes before going one way audio,
>     sometime
>     >>     3 minutes.
>     >>
>     >>     Here is something I did that made the audio last for 40 minutes
>     >> on one
>     >>     call: under system>>servers>>"name.of.server">>Services>>Media
>     >> Relay I
>     >>     changed "Media Relay Temperament" from conservative to
>     aggressive.
>     >>
>     >>     Can someone give me a clue what I should do next?
>     >>
>     >>
>     >>
>     >>
>     
> http://sipx-wiki.calivia.com/index.php/SIP_Trunking_with_sipXecs:_Overview_and_Configuration#Problem_reporting
>     >>
>     >>
>     >>
>     >>
>     >> You can mail me a  snapshot. I will look as time permits.
>     >>
>     >> Ranga
>     >>
>     >>
>     >>     _______________________________________________
>     >>     sipx-users mailing list [email protected]
>     <mailto:[email protected]>
>     >>     <mailto:[email protected]
>     <mailto:[email protected]>>
>     >>     List Archive: http://list.sipfoundry.org/archive/sipx-users
>     >>     Unsubscribe:
>     http://list.sipfoundry.org/mailman/listinfo/sipx-users
>     >>     sipXecs IP PBX -- http://www.sipfoundry.org/
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >> M. Ranganathan
>     >>
>     >
>
>     _______________________________________________
>     sipx-users mailing list [email protected]
>     <mailto:[email protected]>
>     List Archive: http://list.sipfoundry.org/archive/sipx-users
>     Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
>     sipXecs IP PBX -- http://www.sipfoundry.org/
>
> Any changes (like installing a patch), changing a gateway (ITSP 
> profile) or SBC, has a function to "send profiles", The reason this is 
> there is because it is "plannable" by the admin as to when to do this, 
> because then some services will prompted to restart, and unloike a 
> separate hardware gateway, will break any call in progress to a remote 
> worker or connecting to an ITSP via the built in SBC.
>
> You have to decide when to do this, of course. Also, I think the 
> instructions for patch17 should include what services to restart 
> (sipXconfig (because of a running java process, and sipxbridge).
>
> I also noticed changing a dialplan with a remote user connected caused 
> the registration to drop when testing a Bria Pro configuration. I 
> think if I had given it a few seconds it might have reconnected, but I 
> was trying to get through some tests so I just restarted the PC app. I 
> think that's a functionality within the Bria and not sipx 
> specifically. It's just the way it is.
>
>

_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to