Will do , Thank you :) On Tue, Aug 21, 2012 at 10:24 AM, Michael Picher <[email protected]> wrote:
> see split dns in the wiki. > > On Tue, Aug 21, 2012 at 10:13 AM, Saad <[email protected]> wrote: > >> 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/ >> > > > > -- > Michael Picher, Director of Technical Services > eZuce, Inc. > > 300 Brickstone Square**** > > Suite 201**** > > Andover, MA. 01810 > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> > www.ezuce.com > > > ------------------------------------------------------------------------------------------------------------ > There are 10 kinds of people in the world, those who understand binary and > those who don't. > > > _______________________________________________ > 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/
