News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Why do I get "....has not received a response from the service provider"?

Started by tome, August 27, 2011, 07:35:02 AM

Previous topic - Next topic

tome

I am using SP2 to call sip uri's.  I do not have a sip provider yet, but with RonR's help I have the OBi110 set up to  do this, I guess through the OBiTalk service.  I can call, for example, 800 directory service at:  **218005551212*204*74*220*162  This seems to work every time.

But, a friend has a sip account on sip2sip.info.  When I dial his number, after 30 seconds or so, I get "The number you dialed **22.... has not received a response from the service provider".  Shouldn't I either get a ring or a busy?  What exactly does this message mean and why would I get it?  If the Obi can dial other sip uris, why not this one?

I believe his number is valid and that it should ring, he gets calls on this number from other people but has not seen a missed call from me, so it appears it isn't getting to him at all.

Tom

RonR

The only thing that uses the OBiTALK service is OBiTALK calls (**9 + number).  SIP URI's simply go across the Internet from you to the destination server (sip2sip.info in this case).  The response "The number you dialed **22.... has not received a response from the service provider" message means just that.

I just set up Speed Dial's for **2test@conference.sip2sip.info and SP2(test@conference.sip2sip.info).  Both formats successfully reach the sip2sip.info conference bridge as expected.  If you can do the same, the problem must be related to your friends URI.

tome

Quote from: RonR on August 27, 2011, 10:09:19 AM
The only thing that uses the OBiTALK service is OBiTALK calls (**9 + number).  SIP URI's simply go across the Internet from you to the destination server (sip2sip.info in this case).  The response "The number you dialed **22.... has not received a response from the service provider" message means just that.

I just set up Speed Dial's for **2test@conference.sip2sip.info and SP2(test@conference.sip2sip.info).  Both formats successfully reach the sip2sip.info conference bridge as expected.  If you can do the same, the problem must be related to your friends URI.

Hey RonR,
Thanks.  Yes, the test worked.  I wonder if using the primary sip2sip.info ip address (81.23.228.140) is not correct?  I can reach him using  USERNAME@sip2sip.info.  But not using **2XXXYYYZZZ*81*23*228*140.

Can you mix them in the speed dial like:  **2XXXYYYZZZ@sip2sip.info ?

Also, on a related front...  When I called him successfully he saw my caller id info as FOO@127.0.0.1.  Where FOO was the bogus info I had put into
Voice Services -> SP2 Service -> SIP Credentials -> AuthUserName
and 127.0.0.1 was what I put into
Service Providers -> ITSP Profile B -> SIP -> ProxyServer

This gave me an idea and I put my dyndns.org address into the proxy server and had him try to call me back.  But it didn't work, he was getting request timeouts.  Should this work, or is there something else missing in order to receive calls in this way?

And also, if I get a sip2sip.info URI can I configure the Obi to work with it, Google Voice, and a regular VOIP provider like voip.ms, or am I limited to just Google Voice and one other provider (sip2sip OR voip.ms)?

Thanks again,
Tom

RonR

You should be able to use any normal SIP URI format.

It may be that sip2sip.info has a DNS SRV record that returns a different IP address than the DNS A record.

I prefer to use TK format: SP2(user@hostname)

When your friend tried calling you back, did he put :5061 at the end of the SIP URI he used?  SIP URI's default to port 5060, which is SP1 on the OBi and would not be responded to since you have SIP configured on SP2.

You are limited to two registered ITSP accounts on the OBi.  With Google Voice on SP1, you could register VOIP.ms or sip2sip.info on SP2 (instead of the dummy setup you now have), but not both.  With VOIP.ms on SP2, you can continue to use SIP URI's as you are now.

RonR

BTW, you can reverse the SIP User Agent Ports on the OBi such that SP2 will be listening on port 5060 instead of port 5061:

Voice Services -> SP1 Service -> X_UserAgentPort : 5061

Voice Services -> SP2 Service -> X_UserAgentPort : 5060

This will probably make it easier for others to call you without having to tack a port address onto your URI.

I like the idea of putting your DynDNS hostname in for ProxyServer.  Please let me know if this all works out for your friend returning your calls.

tome

Quote from: RonR on August 27, 2011, 12:03:23 PM
BTW, you can reverse the SIP User Agent Ports on the OBi such that SP2 will be listening on port 5060 instead of port 5061:

Voice Services -> SP1 Service -> X_UserAgentPort : 5061

Voice Services -> SP2 Service -> X_UserAgentPort : 5060

This will probably make it easier for others to call you without having to tack a port address onto your URI.

I like the idea of putting your DynDNS hostname in for ProxyServer.  Please let me know if this all works out for your friend returning your calls.


Yes, the port number was the problem!  It works if he calls FOO@BAR.dnydns.org:5061
I don't suppose sending the port number as part of the "callerid" info is part of the spec?

And thanks for the info on re-mapping the port numbers.  I may or may not do this.  I need to decide if I am going to get a "real" voip provider at all or just keep GV + sip2sip.info.

Can there just be an implied "many thanks!" in all my messages to you ;)
Tom

ps:  Does Google Voice even care about the port number?

RonR

Google Voice doesn't use SIP, so X_UserAgentPort isn't of interest on SP1.  I don't think you'll see any problems reversing them (they're reversed here).  Then you don't have to worry about port 5061.

The alternative is to put Google Voice on SP2 and your VoIP provider (real or dummy) on SP1.  Just remember to change your PrimaryLine and review any references you've made to SP1, like {(Mcot)>(Msp1):sp1} in the OBiTALK Service InboundCallRoute.



tome

There is also X_KeepAliveServerPort, should I change those as well?

Tom

RonR


tome

Quote from: RonR on August 27, 2011, 11:37:20 AM
It may be that sip2sip.info has a DNS SRV record that returns a different IP address than the DNS A record.

FYI - "dig" doesn't reveal any SRV records for the domain so I am not sure what is happening.

Tom

RonR

Quote from: tome on August 27, 2011, 11:15:48 AM
I can reach him using  USERNAME@sip2sip.info.  But not using **2XXXYYYZZZ*81*23*228*140.

Where are you having trouble, the OBiON App, the OBi, or both (please verify if you haven't tested both)?  Since we can both successfully use **218005551212*204*74*220*162 and **218005551212@tf.callwithus.com, it appears both formats are being handled correctly from both places.

I'm not sure I understand what the mystery is you're trying to solve.

USERNAME above is the same as XXXYYYZZZ above, correct?

A SIP URI is username@hostname.  If your friends username is XXXYYYZZZ and the hostname it's associated with is sip2sip.info, then the SIP URI would be XXXYYYZZZ@sip2sip.info.  Since there's only digits, *, and # on a keypad, the OBi has a User Defined DigitMap (ipd) to allow IP dialing.  The IP address for sip2sip.info is 81.23.228.140.  An * is used signify the @ and . (and : if needed) in the ipd DigitMap.  This allows dialing a SIP URI from a keypad as:

XXXYYYZZZ*81*23*228*140*5060

The ipd DigitMap restores that to XXXYYYZZZ@81.23.228.140:5060.

Unless you're dialing it by hand from a keypad, it doesn't make sense to use the *81*23*228*140 notation for @sip2sip.info (although it should and does work).  In Speed Dials, you can use:

**218005551212@tf.callwithus.com
**218005551212@204.74.220.162
**218005551212*204*74*220*162
SP2(18005551212@tf.callwithus.com)
SP2(18005551212@204.74.220.162)

You cannot use SP2(18005551212*204*74*220*162) in a Speed Dial because no DigitMap's are used when TK (trunk) format is used.

What's the problem, again?   :)

tome

Quote from: RonR on August 27, 2011, 07:02:33 PM
Quote from: tome on August 27, 2011, 11:15:48 AM
I can reach him using  USERNAME@sip2sip.info.  But not using **2XXXYYYZZZ*81*23*228*140.

Where are you having trouble, the OBiON App, the OBi, or both (please verify if you haven't tested both)?  Since we can both successfully use **218005551212*204*74*220*162 and **218005551212@tf.callwithus.com, it appears both formats are being handled correctly from both places.

I'm not sure I understand what the mystery is you're trying to solve.

USERNAME above is the same as XXXYYYZZZ above, correct?

A SIP URI is username@hostname.  If your friends username is XXXYYYZZZ and the hostname it's associated with is sip2sip.info, then the SIP URI would be XXXYYYZZZ@sip2sip.info.  Since there's only digits, *, and # on a keypad, the OBi has a User Defined DigitMap (ipd) to allow IP dialing.  The IP address for sip2sip.info is 81.23.228.140.  An * is used signify the @ and . (and : if needed) in the ipd DigitMap.  This allows dialing a SIP URI from a keypad as:

XXXYYYZZZ*81*23*228*140*5060

The ipd DigitMap restores that to XXXYYYZZZ@81.23.228.140:5060.

Unless you're dialing it by hand from a keypad, it doesn't make sense to use the *81*23*228*140 notation for @sip2sip.info (although it should and does work).  In Speed Dials, you can use:

**218005551212@tf.callwithus.com
**218005551212@204.74.220.162
**218005551212*204*74*220*162
SP2(18005551212@tf.callwithus.com)
SP2(18005551212@204.74.220.162)

You cannot use SP2(18005551212*204*74*220*162) in a Speed Dial because no DigitMap's are used when TK (trunk) format is used.

What's the problem, again?   :)


Problem is on the Obi110 (not sure about phone app yet, but lets stick to one thing at a time)...

I want to call my friend, his sip2sip.info username is fred and associated alias is 1231231234.
If I do a dns lookup on sip2sip.info I get the A record 81.23.228.140.  I also talked to my friend and he gave me two other valid addresses they use which are 81.23.228.150, and 81.23.228.129

These work on my OBi110:
SP2(fred@sip2sip.info)
**21231231234@sip2sip.info


These do not work on my OBi110:
**21231231234*81*23*228*140
**21231231234*81*23*228*150
**21231231234*81*23*228*129
**21231231234@81.23.228.140

Just to be clear, I am able to dial **218005551212*204*74*220*162 (which you gave me previously).
Tom

RonR

Quote from: tome on August 27, 2011, 08:11:21 PM
These work on my OBi110:
**21231231234@sip2sip.info

These do not work on my OBi110:
**21231231234@81.23.228.140

I see the mystery now.  Assuming there is no DNS SRV, those should be identical, shoudn't they?

If you're up for some detective work, run a Syslog server on your PC and set your OBi:

System Management -> Device Admin -> Syslog -> Server : (your PC's LAN IP address)

Voice Services -> SP2 Service -> X_SipDebugOption : Log All Except REGISTER Messages

Then make each of the two calls above and see what's different at the SIP level between the one that works and the one that doesn't.

RonR

Wait a minute!

I just did an nslookup on sip2sip.info:

D:\Work>nslookup
Default Server:  tomato-1
Address:  192.168.1.1

> set type=srv
> _sip._udp.sip2sip.info
Server:  tomato-1
Address:  192.168.1.1

Non-authoritative answer:
_sip._udp.sip2sip.info  SRV service location:
          priority       = 0
          weight         = 0
          port           = 5060
          svr hostname   = proxy.sipthor.net
> quit

D:\Work>

It appears sip2sip.info does have an SRV record: proxy.sipthor.net

Try using an IP address of 85.17.186.7 and see if you can call your friend.

tome

Quote from: RonR on August 27, 2011, 08:41:47 PM
Wait a minute!

I just did an nslookup on sip2sip.info:

D:\Work>nslookup
Default Server:  tomato-1
Address:  192.168.1.1

> set type=srv
> _sip._udp.sip2sip.info
Server:  tomato-1
Address:  192.168.1.1

Non-authoritative answer:
_sip._udp.sip2sip.info  SRV service location:
          priority       = 0
          weight         = 0
          port           = 5060
          svr hostname   = proxy.sipthor.net
> quit

D:\Work>

It appears sip2sip.info does have an SRV record: proxy.sipthor.net

Try using an IP address of 85.17.186.7 and see if you can call your friend.


Hmm, apparently my use of Dig is rusty. Anyway, when I try that address I get a message immediately that the number dialed was "rejected by the service provider. reason is 403"

I am trying syslog...
Tom

tome

I PM'd the logs to you.
Tom

RonR

It's clear that the SIP server is proxy.sipthor.net as defined by a DNS SRV record for sip2sip.info.  That's why there's no response when using the A-record IP address for sip2sip.info.

I'm not an expert at the SIP protocol level, but I suspect things are a little unusual because proxy.sipthor.net isn't acting as a normal SIP server but is instead linking one SIP client to another SIP client.  I'm sure they don't want to be proxying the RTP (audio) as it would be costly to foot the bill for the bandwidth required.

I don't think there's anything wrong.  There's three IP addresses for proxy.sipthor.net:

81.23.228.129
81.23.228.150
85.17.186.7

If none of these result in a successful call, then someone more familiar with SIP protocol will have to explain your successful log and why sip2sip only works with a hostname and not an IP address.

tome

Quote from: RonR on August 27, 2011, 10:35:50 PM
It's clear that the SIP server is proxy.sipthor.net as defined by a DNS SRV record for sip2sip.info.  That's why there's no response when using the A-record IP address for sip2sip.info.

I'm not an expert at the SIP protocol level, but I suspect things are a little unusual because proxy.sipthor.net isn't acting as a normal SIP server but is instead linking one SIP client to another SIP client.  I'm sure they don't want to be proxying the RTP (audio) as it would be costly to foot the bill for the bandwidth required.

I don't think there's anything wrong.  There's three IP addresses for proxy.sipthor.net:

81.23.228.129
81.23.228.150
85.17.186.7

If none of these result in a successful call, then someone more familiar with SIP protocol will have to explain your successful log and why sip2sip only works with a hostname and not an IP address.


Thanks for looking at it.  To be honest, I have made you spend more time than it is worth.  Since "sip2sip.info" works fine and can be used in the speed dial lists I am fine using it.  In fact, it is sort of the beauty of sip!  

If someone knows the answer it would be good to know on an engineering level.  I suspect you are very close and it has to do with how sip2sip is using the protocol to connect calls between the clients.  I think they may be able to both act as a proxy if needed, and to allow clients to connect directly if possible.

Tom

M888

Rebooting the ObiHai device worked to clear this problem for me on 8/8/2018. Check if the Phone LED is blinking. If so this might work.