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/
