So in this case we cannot rely on SIPX as a file server but we need to setup an external TFTP/FTP correct? Could you please advise the file name that need to be changed for the DNS SRV ?
On Tue, Aug 21, 2012 at 10:02 AM, Tony Graziano < [email protected]> wrote: > Nothing should be changed on sipx or in the phones from a default > installation, at least that has been my experience with other SBC's. > > Perhaps you need a dialplan rule in the Acme SBC to to pass the MOH uri > from it to sipx? > > On Tue, Aug 21, 2012 at 9:27 AM, Saad <[email protected]> wrote: > >> You are absolutely right as I have learned this the hard way.. The >> outbound calls experienced many troubles when sent via the same SBC >> interface that the phones registration coming from. Internal calls stopped >> to work ( SIPX didn't like to have the unmanaged GW talking to the same >> interface that all phones showing registered with)..... What I did as a >> work around was created a separate interface on the SBC to talk to the >> unmanaged GW on SIPX and this worked fine. >> >> I believe, I will open a ticket with ACME dig further on the MOH >> treatment with their NN3820. >> >> Just to recap, are you saying that nothing at all needs to be changed on >> SIPX ( other than using unmanaged GW) ? should everything remain as is? >> >> >> >> Thank you >> >> Saad >> >> >> On Tue, Aug 21, 2012 at 9:01 AM, Tony Graziano < >> [email protected]> wrote: >> >>> Assuming the phone is remote: >>> >>> The DNS SRV records need to point to the public IP of the SBC. The SBC >>> needs to see the registration and pass it through to the sipx server. All >>> registered phones should pass through to the sipx server, period. >>> >>> Outbound calls should not be to the SBC, they should be to the sipx >>> server (otherwise you have a security management headache with call >>> permissions). The SBC should see the phone as registered and send all >>> communications to the sipx server and let the sipx server handle all >>> registrations, permissions, etc. Outbound calls should be sent from sipx to >>> the SBC via an unmanaged gateway/dialplan entry(ies). >>> >>> The most consistent way to make this happen is to: >>> >>> 1. Have an SBC that can perform these functions. >>> 2. Use two different interfaces in the SBC (One facing the public >>> Internet/Where the clients are registering from), and another facing the >>> ITSP. >>> >>> In this way MOH is a function of an ongoing media transaction with the >>> sipx server, it has always worked for me with other SBC's (Ingate, as an >>> example, you can specify the sipx MOH uri so it can utilize it), but MOH is >>> tricky even for SBC's which is why other (like Karoo Bridge) allow you to >>> specify it's own MOH as a workaround. >>> >>> Long story short, MOH may not work depending on the SBC in use, but it >>> is important to be able to segregate traffic for users versus trunking in >>> order to make the routing logic in the SBC work appropriately. >>> On Tue, Aug 21, 2012 at 8:44 AM, Saad <[email protected]> wrote: >>> >>>> Hello All, >>>> >>>> I know many of you succeeded with registering phones VIA SBC. Are you >>>> aware of any SIPX documentation on the proper configuration to have Polycom >>>> phones to register via SBC? >>>> >>>> From the SBC side, the configuration was completed; however, still not >>>> sure if we are doing it the right way on SIPX... What we did on SIPX was to >>>> point the outbound proxy (Phone registration form) to the SBC >>>> (Registration point) and this worked with some minor intermittent troubles >>>> like (Silent on MOH, attended transfer failure.), if we point both the >>>> outbound proxy and the primary registration server to the SBC, then the >>>> unmanaged GW Caller ID doesn't override the users numbers , MWI update >>>> stops working, the attended AND Unattended transfer failed to work... >>>> >>>> Please let me know if there is any documents that explains how to work >>>> the phone registration via SBC on SIPX / IP Phones sides.. >>>> >>>> Thank you >>>> Saad Khankan, P.Eng. >>>> >>>> _______________________________________________ >>>> 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 >>> ~~~~~~~~~~~~~~~~~~ >>> Linked-In Profile: >>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> Ask about our Internet Fax services! >>> ~~~~~~~~~~~~~~~~~~ >>> >>> Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab >>> 2013! >>> <http://sipxcolab2013.eventbrite.com/?discount=tony2013> >>> >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> sip: [email protected].**net<[email protected]> >>> >>> Helpdesk Customers: >>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>> Blog: http://blog.myitdepartment.net >>> >>> _______________________________________________ >>> 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.465.6833 > ~~~~~~~~~~~~~~~~~~ > Linked-In Profile: > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > ~~~~~~~~~~~~~~~~~~ > > Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab > 2013! > <http://sipxcolab2013.eventbrite.com/?discount=tony2013> > > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> > Blog: http://blog.myitdepartment.net > > _______________________________________________ > 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/
