Polycom outbound proxy

[Marco Colaneri]

Hello,

we deployed a hundred users SipXecs system on release 4.4
with Polycom Phones.

We found out that outbound proxy default value is
automatically set to sip domain for each phone line.

We use Audiocodes SAS in "redundant mode" and set the sas
agent as secondary sip registrar on polycom phones.
Therefore outbound proxy default value prevent phones from
registering to sas agent.

So the question is: how to set the outbound proxy default
value to "null" for each line? Until now the only solution I
found was to manually set this parameter to null for each
line in each phone. Though this method is inconvenient for a
medium or large system. Besides every time we configure a
new phone, we have to remember to reset outbound proxy
parameter.

Any further ideas or advice?

Thank you very much for the support.

Marco

[Ali Ardestani]

Hi,
Create phone groups and make those phones member of that group with the sip
proxy set to null

Post by Marco Colaneri
Hello,
we deployed a hundred users SipXecs system on release 4.4
with Polycom Phones.
We found out that outbound proxy default value is
automatically set to sip domain for each phone line.
We use Audiocodes SAS in "redundant mode" and set the sas
agent as secondary sip registrar on polycom phones.
Therefore outbound proxy default value prevent phones from
registering to sas agent.
So the question is: how to set the outbound proxy default
value to "null" for each line? Until now the only solution I
found was to manually set this parameter to null for each
line in each phone. Though this method is inconvenient for a
medium or large system. Besides every time we configure a
new phone, we have to remember to reset outbound proxy
parameter.
Any further ideas or advice?
Thank you very much for the support.
Marco
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

[phone] Office
[phone] x2654 Office
[phone] Mobile
[phone] Fax

***@pnmac.com

[Marco Colaneri]

Hi Ali,

we tried to follow your advice.

However setting to null the group outbound proxy parameter
doesn't affect phone line parameter because in the group
profile, the default value of that parameter is null.

I found a workaround by changing the default value to sip
domain in /etc/sipxpbx/polycom/line.xml.

<setting name="outboundProxy.address">
<type>
<string />
</type>
<value>sipdomain.it</value>
</setting>

Then I logged in the web interface and set the group
outbound proxy parameter to null. In this way all phones
which belong to that group have outbound proxy parameter set
to null.

Thanks for your advice.

Marco

[Josh Patten]

The way Audiocodes SAS is generally deployed is that the outbound proxy for
the primary registrar is set to your Audicodes gateway, port 5080. This way
the Audiocodes has a record of all registrations and can service them in
the event of an outage. See
http://wiki.sipfoundry.org/display/sipXecs/AudioCodes+5.80a+Stand-Alone+Survivability

Post by Marco Colaneri
Hi Ali,
we tried to follow your advice.
However setting to null the group outbound proxy parameter
doesn't affect phone line parameter because in the group
profile, the default value of that parameter is null.
I found a workaround by changing the default value to sip
domain in /etc/sipxpbx/polycom/line.xml.
<setting name="outboundProxy.address">
<type>
<string />
</type>
<value>sipdomain.it</value>
</setting>
Then I logged in the web interface and set the group
outbound proxy parameter to null. In this way all phones
which belong to that group have outbound proxy parameter set
to null.
Thanks for your advice.
Marco
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Marco Colaneri]

Thank you Josh,

I know that way to configure SAS.

We didn't choose it because all sip signaling traffic goes
through the gateway.
So if the gateway fails or becomes unreachable, all the
phone can't register and reach SipXecs servers.

Maybe we could get over this problem by defining a new SRV
record on DNS (e.g. gwsite1.sipdomain) which points
primarily to the audiocodes gateway and secondarily to the
sipxecs servers. This configuration should fix problems due
to Audiocodes failures. Am I right or I'm missing something?
If we didn't deploy a DNS server locally, would this
solution still work when the site WAN link fails? How could
phones resolve outbound proxy address? Perhaps using DNS
records caching?

Thank you very much for help.

Marco

[Michael Picher]

From my recollection, SAS does not support using a SRV record.

This is a bit of a problem as I see it. Trading one point of failure for
another. I guess you just need to ask yourself, is it more likely that an
ITSP will go down or your gateway will fail. I think the former is more
likely.

Mike

Thank you Josh,
I know that way to configure SAS.
We didn't choose it because all sip signaling traffic goes
through the gateway.
So if the gateway fails or becomes unreachable, all the
phone can't register and reach SipXecs servers.
Maybe we could get over this problem by defining a new SRV
record on DNS (e.g. gwsite1.sipdomain) which points
primarily to the audiocodes gateway and secondarily to the
sipxecs servers. This configuration should fix problems due
to Audiocodes failures. Am I right or I'm missing something?
If we didn't deploy a DNS server locally, would this
solution still work when the site WAN link fails? How could
phones resolve outbound proxy address? Perhaps using DNS
records caching?
Thank you very much for help.
Marco
_______________________________________________
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

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Tony Graziano]

I think it would help a lot if sipxbridge could send a failure message to
the proxy so the proxy could try another gateway (i.e. put these in a
dailplan). Though the gateways (if this is a pstn gateway) or sipxbridge
needs to be able to discern this is a transport issue and generate maybe a
302 versus a 486 busy.

I think if the proxy has the ability to detect "conclusively" that
something is down it can route calls. Conversely, the UA's can do the same
thing by registering one line to each (one line to sipx, the other to the
gateway).

Post by Michael Picher

From my recollection, SAS does not support using a SRV record.

This is a bit of a problem as I see it. Trading one point of failure for
another. I guess you just need to ask yourself, is it more likely that an
ITSP will go down or your gateway will fail. I think the former is more
likely.
Mike

Thank you Josh,
I know that way to configure SAS.
We didn't choose it because all sip signaling traffic goes
through the gateway.
So if the gateway fails or becomes unreachable, all the
phone can't register and reach SipXecs servers.
Maybe we could get over this problem by defining a new SRV
record on DNS (e.g. gwsite1.sipdomain) which points
primarily to the audiocodes gateway and secondarily to the
sipxecs servers. This configuration should fix problems due
to Audiocodes failures. Am I right or I'm missing something?
If we didn't deploy a DNS server locally, would this
solution still work when the site WAN link fails? How could
phones resolve outbound proxy address? Perhaps using DNS
records caching?
Thank you very much for help.
Marco
_______________________________________________
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
------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

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

[Michael Picher]

well, isn't the point of SAS that you can't reach the proxy in the first
place, so what's the sense in this discussion anyway...


On Fri, Dec 7, 2012 at 6:36 AM, Tony Graziano

Post by Tony Graziano
I think it would help a lot if sipxbridge could send a failure message to
the proxy so the proxy could try another gateway (i.e. put these in a
dailplan). Though the gateways (if this is a pstn gateway) or sipxbridge
needs to be able to discern this is a transport issue and generate maybe a
302 versus a 486 busy.
I think if the proxy has the ability to detect "conclusively" that
something is down it can route calls. Conversely, the UA's can do the same
thing by registering one line to each (one line to sipx, the other to the
gateway).

Post by Michael Picher

From my recollection, SAS does not support using a SRV record.

This is a bit of a problem as I see it. Trading one point of failure for
another. I guess you just need to ask yourself, is it more likely that an
ITSP will go down or your gateway will fail. I think the former is more
likely.
Mike

Thank you Josh,
I know that way to configure SAS.
We didn't choose it because all sip signaling traffic goes
through the gateway.
So if the gateway fails or becomes unreachable, all the
phone can't register and reach SipXecs servers.
Maybe we could get over this problem by defining a new SRV
record on DNS (e.g. gwsite1.sipdomain) which points
primarily to the audiocodes gateway and secondarily to the
sipxecs servers. This configuration should fix problems due
to Audiocodes failures. Am I right or I'm missing something?
If we didn't deploy a DNS server locally, would this
solution still work when the site WAN link fails? How could
phones resolve outbound proxy address? Perhaps using DNS
records caching?
Thank you very much for help.
Marco
_______________________________________________
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
------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
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: [phone]
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/

--
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

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Tony Graziano]

I was not indicating a possible path overcome a down gateway AND an
unavailable proxy.

However if both are down...

Post by Michael Picher
well, isn't the point of SAS that you can't reach the proxy in the first
place, so what's the sense in this discussion anyway...
On Fri, Dec 7, 2012 at 6:36 AM, Tony Graziano <

Post by Tony Graziano
I think it would help a lot if sipxbridge could send a failure message to
the proxy so the proxy could try another gateway (i.e. put these in a
dailplan). Though the gateways (if this is a pstn gateway) or sipxbridge
needs to be able to discern this is a transport issue and generate maybe a
302 versus a 486 busy.
I think if the proxy has the ability to detect "conclusively" that
something is down it can route calls. Conversely, the UA's can do the same
thing by registering one line to each (one line to sipx, the other to the
gateway).

Post by Michael Picher

From my recollection, SAS does not support using a SRV record.

This is a bit of a problem as I see it. Trading one point of failure
for another. I guess you just need to ask yourself, is it more likely that
an ITSP will go down or your gateway will fail. I think the former is more
likely.
Mike

Thank you Josh,
I know that way to configure SAS.
We didn't choose it because all sip signaling traffic goes
through the gateway.
So if the gateway fails or becomes unreachable, all the
phone can't register and reach SipXecs servers.
Maybe we could get over this problem by defining a new SRV
record on DNS (e.g. gwsite1.sipdomain) which points
primarily to the audiocodes gateway and secondarily to the
sipxecs servers. This configuration should fix problems due
to Audiocodes failures. Am I right or I'm missing something?
If we didn't deploy a DNS server locally, would this
solution still work when the site WAN link fails? How could
phones resolve outbound proxy address? Perhaps using DNS
records caching?
Thank you very much for help.
Marco
_______________________________________________
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
------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
Fax: [phone]
~~~~~~~~~~~~~~~~~~
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: [phone]
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/

--
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
------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/