Quote:
Originally Posted by gunnelsunder
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...