Registering phone VIA SBC

Discussion:

Saad

2012-08-21 12:44:52 UTC

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.

Tony Graziano

2012-08-21 13:01:29 UTC

Permalink

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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
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: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net

Saad

2012-08-21 13:27:31 UTC

Permalink

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

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Tony Graziano

2012-08-21 14:02:10 UTC

Permalink

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?

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Saad

2012-08-21 14:13:32 UTC

Permalink

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 <

Post by Tony Graziano
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?

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Michael Picher

2012-08-21 14:24:47 UTC

Permalink

see split dns in the wiki.

Post by Saad
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 <

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
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.

Saad

2012-08-21 14:53:58 UTC

Permalink

Will do , Thank you :)

Post by Michael Picher
see split dns in the wiki.

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Tony Graziano

2012-08-21 14:30:26 UTC

Permalink

You can either nat this to a firewall (FTP) to sipx or pass it through the
SBC to sipx (FTP). As long as the SBC sees ANY traffic from a UA, it should
pass it through to sipx (essentially pass all traffic on one interface to
sipx, leaving the other to trunking FROM sipx as an unmanaged gateway).

i.e.

Interface_ITSP - unmanaged gateway and handles all trunking in to ITSP and
sipx simply sends calls there as a result of its own dialplans.
Interface_USERS - All user/registrations, outbound calls, etc. get passed
to sipx from the UA. Inbound calls come from Interface_ITSP and get sent to
the registered UA accordingly.

In your case split DNS may not help since everything is actually private.

If your clients (UA's do not traverse a firewall) then you can simply use
the Server Menu on the handset to input the TFTP address there, as an
example, but if no nat is involed you should be able to send that via dhcp
and not get involved in configuring the phones manually.

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Saad

2012-08-21 19:40:10 UTC

Permalink

Understood! and lot of work to be honest.
My question now is: which polycom file needs to be tweacked and what
parameter?

Thank you
Saad

On Tue, Aug 21, 2012 at 10:30 AM, Tony Graziano <

Post by Tony Graziano
You can either nat this to a firewall (FTP) to sipx or pass it through the
SBC to sipx (FTP). As long as the SBC sees ANY traffic from a UA, it should
pass it through to sipx (essentially pass all traffic on one interface to
sipx, leaving the other to trunking FROM sipx as an unmanaged gateway).
i.e.
Interface_ITSP - unmanaged gateway and handles all trunking in to ITSP and
sipx simply sends calls there as a result of its own dialplans.
Interface_USERS - All user/registrations, outbound calls, etc. get passed
to sipx from the UA. Inbound calls come from Interface_ITSP and get sent to
the registered UA accordingly.
In your case split DNS may not help since everything is actually private.
If your clients (UA's do not traverse a firewall) then you can simply use
the Server Menu on the handset to input the TFTP address there, as an
example, but if no nat is involed you should be able to send that via dhcp
and not get involved in configuring the phones manually.

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Tony Graziano

2012-08-21 19:44:34 UTC

Permalink

I'm not sure any polycom profile needs to be tweaked. This is usually
handed out via DHCP, so you can hand out via DHCP if it is TFTP without nat.

Post by Saad
Understood! and lot of work to be honest.
My question now is: which polycom file needs to be tweacked and what
parameter?
Thank you
Saad
On Tue, Aug 21, 2012 at 10:30 AM, Tony Graziano <

Post by Tony Graziano
You can either nat this to a firewall (FTP) to sipx or pass it through
the SBC to sipx (FTP). As long as the SBC sees ANY traffic from a UA, it
should pass it through to sipx (essentially pass all traffic on one
interface to sipx, leaving the other to trunking FROM sipx as an unmanaged
gateway).
i.e.
Interface_ITSP - unmanaged gateway and handles all trunking in to ITSP
and sipx simply sends calls there as a result of its own dialplans.
Interface_USERS - All user/registrations, outbound calls, etc. get passed
to sipx from the UA. Inbound calls come from Interface_ITSP and get sent to
the registered UA accordingly.
In your case split DNS may not help since everything is actually private.
If your clients (UA's do not traverse a firewall) then you can simply use
the Server Menu on the handset to input the TFTP address there, as an
example, but if no nat is involed you should be able to send that via dhcp
and not get involved in configuring the phones manually.

Post by Saad
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 <

Post by Tony Graziano
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).
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.

Post by Saad
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
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>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Joe Micciche

2012-08-21 15:27:55 UTC

Permalink

Post by Saad
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 ?

Saad, you can use sipX to host your TFTP for the external phones. This
will require you to build a static flow in the APKT SBC. Please
remember that TFTP over the interwebz is a security risk, so look into
HTTPS provisioning via your SBC.

I threw a sample APKT sbc config up on the sipX wiki:
http://wiki.sipfoundry.org/display/sipXecs/Acme+Packet+SBC+sample+config+for+Remote+Workers

The pertinent part for provisioning, which is not in this document:

static-flow
in-realm-id outside
description tftp_passthrough
in-source 0.0.0.0
in-destination <public_ip_of_sbc>:69
out-realm-id inside
out-source <internal_ip_of_sbc>
out-destination <sipX_ip>:69
protocol UDP
alg-type TFTP
start-port 8080
end-port 8099
flow-time-limit 0
initial-guard-timer 60
subsq-guard-timer 60
average-rate-limit 0

If you are not using the sbc for SIP trunking, you do not need any
dial plan entries pointing to it.

- --
==================================================================
Joe Micciche ***@redhat.com
Red Hat, Inc. http://www.redhat.com
Senior Communications Engineer X (81) 44554
+1.919.754.4554 Key: 65F90FE1
==================================================================

Saad

2012-08-21 19:38:11 UTC

Permalink

Thanks alot, very good information, keep them coming :)
I went carefully through the steering-pool / Local-Policy / session Agent
.. etc and looks like we are not missing any things on the SBC.
Now if I configured an Unmanaged TFTP on SIPX I think I only need to
change the parameter (reg.1.server.1.address=" " ) in phone1.cfg file to
point to the SBC registration IP address correct? Am I missing anythings?

Thank you
Saad

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Saad
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 ?

Saad, you can use sipX to host your TFTP for the external phones. This
will require you to build a static flow in the APKT SBC. Please
remember that TFTP over the interwebz is a security risk, so look into
HTTPS provisioning via your SBC.
http://wiki.sipfoundry.org/display/sipXecs/Acme+Packet+SBC+sample+config+for+Remote+Workers
static-flow
in-realm-id outside
description tftp_passthrough
in-source 0.0.0.0
in-destination <public_ip_of_sbc>:69
out-realm-id inside
out-source <internal_ip_of_sbc>
out-destination <sipX_ip>:69
protocol UDP
alg-type TFTP
start-port 8080
end-port 8099
flow-time-limit 0
initial-guard-timer 60
subsq-guard-timer 60
average-rate-limit 0
If you are not using the sbc for SIP trunking, you do not need any
dial plan entries pointing to it.
- --
==================================================================
Red Hat, Inc. http://www.redhat.com
Senior Communications Engineer X (81) 44554
+1.919.754.4554 Key: 65F90FE1
==================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAzqPsACgkQJHjEUGX5D+HslQCbBy9SrACD+HEokdzeY1BwZUAY
5/gAn1YkjXZQw3W01awKHWTgbb1bFm4w
=N/Ih
-----END PGP SIGNATURE-----
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/