View Single Post
Unread 10-24-2009, 04:58 AM   #3
emoci
 
Join Date: Jul 2007
Location: Toronto, Canada
Posts: 1,422
Thanks: 123
Thanked 369 Times in 282 Posts
emoci is a name known to allemoci is a name known to allemoci is a name known to allemoci is a name known to all
Default

Quote:
Originally Posted by gunnelsunder View Post
So adding sip.firstreef.net as a proxy worked fine - SIP Code is *9691.

This is not as helpful as it could be as the proxy doesn't field requests for user [at] sip.firstreef.net SIP URIs; ie, for the subdomain, so my users are still unreachable through SIP Broker.

(The echo test above is also at 600 [at] firstreef.net - *9691600 doesn't reach it through SIP Broker, though thanks to a e164.org number range allocation *013882990088070600 does.)

I'm also unable to edit the provider details, possibly because I have registered a user [at] firstreef.net logon.

Next steps really depend on whether SIP Broker honours SRV records at all - ie, in routine SIP INVITE processing. If not, I think my options are (1) replicate my users' SIP accounts on the subdomain - a substantial admin headache, or (2) give up on SIP Broker.

(I suspect it won't come to that given that the e164.org ENUM lookup above yields a user [at] firstreef.net SIP URI, and SIP Broker routes that correctly.)

If this is just an issue when adding the proxy an admin might be able to help out?

Please can I have the *9691 SIP Code pointing at firstreef.net itself rather than the subdomain? Thanks very much in advance.

-SipBroker will honour and process SRV records
-However when you add a new proxy it confirms based on the A record rather than SRV records...

I would suggest that for the time being you can adjust your SRV records and IPTEL setup so that you're hosting SIP at sip.yourdomain.com .... or wait a bit

...and will try to get a message in to Martin or Craig to adjust things at SIPBroker otherwise...

Last edited by emoci; 10-24-2009 at 05:03 AM.
emoci is offline   Reply With Quote