asterisk users - Dec 2005 - config Polycom with both SIP provider and Asterisk

Hi,

I have some SoundPoint IP 501 phones, running SIP 1.6.2.
I would like to configure them so that line 1 connects
directly to a SIP provider, and line 2 connects to a local
Asterisk PBX.  That should be simple enough, but this
provider requires URIs like sip:12125551212@provider.com .
However, the DNS A record for provider.com points to their
Web server, and there are no SRV records, so one must supply
the server IP address explicitly.  There seems to be a
couple of ways to do that, but I can't get either to work.

In these examples, it is assumed that my number with the
provider is 2123334444, and their server IP is 11.22.33.44 .
First, I tried:
<phone1> <reg reg.1.address="2123334444@provider.com"
  reg.1.server.1.address="11.22.33.44"/> </phone1>

Unfortunately, the phone generates a URI like
sip:12125551212@11.22.33.44 , and the call fails.  In section
4.6.2.1 of the manual, it says "For user part only
registration (reg.x.address="1002"), the registration
will be userPart@proxyHostNameOrIPAddress ...".  I would
assume that when reg.1.address is *not* user part only, the
supplied domain name is used, but that seems not to be the
case.

Next, I tried:
<phone1> <reg reg.1.address="2123334444"
  reg.1.server.1.address="provider.com"/>
<dialplan> <routing>
<server dialplan.1.routing.server.1.address="11.22.33.44"/>
</routing> </dialplan> </phone1>

This time, the correct URI is generated, but it is sent to
the provider's Web server -- the routing parameter seems to
be ignored.  Why?

Finally, I tried:
<phone1> <reg reg.1.address="2123334444"
  reg.1.server.1.address="provider.com"/> </phone1>
<sip> <voIpProt> <SIP> <outboundProxy
  voIpProt.SIP.outboundProxy.address="11.22.33.44"/>
</SIP> </voIpProt> </sip>

In that case, calls via the provider work fine, but there is
then no access to Asterisk, because outbound proxy is a
global setting.

I suspect that the problem could be fixed by pointing the
phones to a doctored DNS server that returned 11.22.33.44
for provider.com.  However, we don't want the added
complexity and unreliability of such a solution.

Any suggestions will be gratefully appreciated.

Thanks,

Stewart