can receive but can't make calls
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:
Quote
INVITE 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 dont 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.
Navigation
[0] Message Index
[#] Next page