"Non responding proxy" failure when adding proxy

[gunnelsunder]

When attempting to add a SIP proxy for my domain firstreef.net to SIP Broker I get the following response:

>firstreef.net appears to be a non responding proxy. Please email support@sipbroker.com to confirm.

Would really like to resolve this to provide access through the excellent SIP Broker service.

The domain's SIP service is hosted at iptel.org and working fine - a test SIP URI is sip:echotest [at] firstreef.net which forwards to the Voxalot echo test.

One thing to note is this setup relies on DNS SRV records as the A record for firstreef.net points at a web server:

_sip._tcp.firstreef.net 3600 IN SRV 0 0 5060 sip.firstreef.net
_sip._udp.firstreef.net 3600 IN SRV 0 0 5060 sip.firstreef.net
_sips._tcp.firstreef.net 3600 IN SRV 0 0 5061 sip.firstreef.net

Any help much appreciated.

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

[emoci]

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

[gunnelsunder]

Thanks, emoci. Getting that confirmed is a great help.

Originally Posted by emoci

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

Yes that's what it looks like - and If I'd known that to start with I could have probably got my proxy in without troubling any one... Oh, well, next time.

Originally Posted by emoci

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

Workaround all ready to go - just couldn't be sure if it was going to be temporary or permanent. Temporary from what you say, which is excellent news.

Originally Posted by emoci

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

That would be great. Yes, please, and thanks very much in advance. A couple of emails into support@sipbroker.com didn't get me anywhere. Popular service, I guess.

[martin]

Sorry for the delay processing this request. I have made the changes as requested. Please test and let me know if it is OK.

[gunnelsunder]

Just checked back here.

Between the workaround I'd put in and the changes working perfectly I hadn't even noticed any difference.

Workaround now retired - perfect, thanks.