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] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
