News:

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

Main Menu

can receive but can't make calls

Started by rasel_tr, October 24, 2015, 10:53:41 AM

Previous topic - Next topic

rasel_tr

Hello,

I put my Obi200 behind my router (Asus DSL-AC68U). Configured it with DMZ so no port issue will happen. Also I disabled the firewall of my router. Now I can receive calls from other numbers but when I tried to make a call, after 1 minute I get SIP_TS:INVITE Times out error. I'm new to these SIP stuff. I'm attaching my syslog. Can someone help me to solve my problem?


rasel_tr

I captured a working invite session using my ISP's modem. Attaching to this message. As I can see SDP identifier Owner Username and session name are filled with "-" while using obi200. Can this be the problem? How can I set these with a static text?


ianobi

If you can receive calls, then you are successfully registered to your voip service provider. This means that your SIP credentials must be correct.

From your syslog:
QuoteINVITE sip:4442515@superonline.com:5060 SIP/2.0

This shows that you sent the number 4442515 to your voip provider superonline. This seems to have received no response. The OBi200 repeated the INVITE several times, then timed out. This suggests that the OBi200 is behaving correctly.

I don't think there is anyone on the forum that has experience of superonline, which I believe is in Turkey. You may wish to check the number format. Most voip providers expect to receive all numbers in full national format. Some expect to receive all numbers in full international format. If there is a superonline forum, then you should check there.

If the number format is the problem, then this forum can explain how to change the digits you wish to dial into the format that superonline wish to receive.



rasel_tr

Hello ianobi, thank you for your reply. Yes, superonline is in Turkey. It is not a dialed number thing. Attaching the log of an unsuccessful  outbound call of the same number with Obi200.

While I'm comparing the wireshark dump of a successful call vs syslog of an unsuccessful call, I can see that in SDP protocol session desc:

for o:
ISP modem= ATP-VOICE 0 0 IN IP4
Obi200= - 2573 1 IN IP4  (- for username field)

for s:
ISP modem= Sip Call
Obi200=- (- for session name field)

for m:
ISP modem= audio 50002 RTP/AVP 9 0 18 8 97
Obi200= audio 50000 RTP/AVP 0 8 18 104 101

for a:
ISP:
rtpmap:9 G722/8000
rtpmap:0 PCMU/8000
rtpmap:18 G729/8000
rtpmap:8 PCMA/8000
rtpmap:97 telephone-event/8000
fmtp:97 0-15
ptime:20
sendrecv

Obi:
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:104 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian

Since I don't know SDP, can this difference be the problem? If so, how can I setup Obi to send these values?





ianobi

I think that I may be getting close to the limit of my expertise here – remember that we are all amateurs on this forum.

A few notes on SDP. They don't have to be the same. The caller will send an INVITE which includes SDP and, if the call is accepted, the callee will send a 200 OK message back to the caller which also includes SDP. The important lines in the SDP are:
(c) – connection information. The ip address of where to send the RTP stream (audio)
(m) – media. The port to send RTP to and a list of CODECs that are being offered.

The list of CODECS  may well be different between any caller and callee. This is OK, so long as there is at least one common to both. The (a) lines list what each device is offering in detail and by priority. The caller and callee will negotiate and pick the highest priority CODEC that both can agree on.

If you are using Wireshark, then I would recommend looking at Telephony > Voip Calls > Call Flow. This can be very useful to seeing what is missing in a failed call. I have attached a typical call that I have just made to a sip2sip test number. The basics are:

Caller sends INVITE which includes SDP
Callee challenges caller with a 407 message asking for authentication – username/password etc.
Caller resends INVITE with the required information.
Callee sends 200 OK which includes SDP
At this point caller and callee have each others ip address/port to send RTP streams to, so the RTP (audio) starts. As you can see, the audio does not necessarily have to go to the same address as the SIP messages.

This call flow is typical, but there are many variations in the detail.


rasel_tr

Thank you for your reply ianobi. Today I read a lot about SIP/SDP and solved my problem. It was so simple but I didn't see it at first because I tried to copy the exact same settings of my ISP modem and on that, there was no outbound proxy defined. But after I entered the same values of my registrar server to this field, now everything works as excepted :)

Last two days, I learned a lot about this voice stuff and this also makes me feel good.

I read somewhere that we can make routes so that we can direct specific numbers to specific SP services ( I have a voipraider account also). Now I will try to route my international outbound calls to my SP2  :)

Thanks again, it is always a pleasure too see amateurs like you try to help people like me by giving their own personal time.


ianobi

I'm glad you found the solution. Sometimes it just helps to talk to someone, even if that someone does not have the exact answer   ;)


QuoteI read somewhere that we can make routes so that we can direct specific numbers to specific SP services ( I have a voipraider account also). Now I will try to route my international outbound calls to my SP2   :)

Digit maps and call routing is quite a big subject, but there are lots of examples in this forum. Post again if you wish any help on that subject.

It looks like you might now be our foremost expert on superonline and voip in Turkey   :)

rasel_tr

Yes, you are right. Talking with someone that has knowledge on the subject helps :)

And for the call routing part, I just removed international calling maps from Msp1 (for Turkey it is the standard 00+country_code+number) and added <**2>00xx.S3 to the beginning. Also added 00xx.S3 to Msp2. I don't know if this is the best solution for user experience but it works. Do you have any other suggestion?

ISPs in Turkey don't share SIP passwords with their customers. Users like me must brute force their md5 hashes or hack their modems in order to gain this info. So I don't think anyone will need my expertise in the near future :)



ianobi

Your call routing looks good to me. It works and it's simple, which is always good. The only slight downside is that you cannot force international calls back to sp1 by dialling **100xx. if voipraider on sp2 fails.

I'm sure that you are aware that the default digitmaps are designed for North American number formats. Adjusting them to Turkish number formats will reduce delays in routing calls.


QuoteISPs in Turkey don't share SIP passwords with their customers. Users like me must brute force their md5 hashes or hack their modems in order to gain this info.

Looks like you have had to overcome more problems than most of us to get your OBi working! It is an interesting point that when any of us use SIP providers our passwords are sent to the SIP providers' servers using MD5 encryption - usually in the second INVITE message following the 407 authentication request from the server. MD5 is known to be quite easy to decrypt. Just something to think about   :-\