Direct SIP dialing & direct IP dialing question
azrobert:
I tried ianobi's configuration and it did not work for me (no audio).
Apparently different networks act differently.
See my solution at the end of the link ianobi provided.
You need to port forward the RTP ports.
I'm not as well versed with the SIP protocol as ianobi, so I can't explain why it works.
VOIP_JoeSummy:
But I still cannot understand that, after the SIP protocol sets up the connection, when the RTP protocol kicks in, why cannot the RTP protocol take destination address information from the caller initial SIP session? Why does it have to take that address data from subsequent acknowledgement from the callee? These two address must be the same. So no need to ask for it again.
It is like: A sender sends a parcel to the recipient. The parcel is addressed to 123 Main Street, Unit 203. But when the mailman reaches to Unit 203, he, instead, for strange reason, asks whoever there is the address of owner at Unit 203, and then he delivers the parcel to whatever the place that the stranger at Unit 203 told him, totally ignoring the address that the sender put on the parcel.
Isn't it absurd?
( My port forwarding is done correctly. Otherwise, the registered Linphone softphone app won't be able to call my OBI SP2. )
ianobi:
There are a lot of variables here, so I'm not surprised that different people get different results. Obi devices are not designed for direct ip to ip calling. However, it works for me nine times out of ten.
Quote
( My port forwarding is done correctly. Otherwise, the registered Linphone softphone app won't be able to call my OBI SP2. )
Yes, I agree. However, you are controlling the SIP signalling. The RTP port numbers will be different from the SIP "listening" ports. Some voip providers will use totally different servers for RTP and will put the relevant RTP ip address and ports in their "contact" header details.
I know it's frustrating, but the two devices need to know each others "contact" addresses for RTP. The ip address is the same for direct ip calling, but the ports will not be the same. So it's the devices that need to tell each other where to send the RTP streams.
If you have a static public ip address for your OBi, then its easier. Otherwise, I suggest using the "keep-alive with STUN" method to make sure the unregistered spX sends its public ip address in its "contact" header. I also recommend use of STUN in the caller (Linphone in this case or any other softphone calling into the OBI) to try to resolve routing problems.
I'm with you Joe - I wish it was easy ::) Also, I'm not a world expert on this stuff, just an amateur really, so it might be worth searching on the web for a better written explanation of how voip calls work.
Anyhow its getting late in my time zone, but I'm back tomorrow for more judgements on SIP and RTP protocols and how they work together, or not ;)
drgeoff:
Unfortunately the people who originated SIP did not consider NAT. A lot of problems stem from that.
ianobi:
Very true. In a "normal" situation with a user registered to a voip service provider NAT is less of a problem as register messages are sent at regular intervals from the user to the service provider's server and that server often also sends keep-alive packets back to the user to keep NAT paths open for its services.
Direct ip to ip SIP calls have a real problem with NAT at both ends. At the hot spot end (maybe your local coffee shop) your laptop or wifi smartphone will connect to the local router via wifi and will have a local ip address. The OBi unregistered spX also has a local ip address. Somehow your softphone on your laptop needs to be able to find out the public ip address of the OBi spX and the OBi spX needs to find out the public ip address of the wifi hotspot. If any of the ip addresses are fixed, then that makes things easier, otherwise use of STUN at both ends as described is a reasonable solution.
Finally (maybe!), I did simplify the whole business of "contacts" in the INVITE and OK messages above. In fact both messages have a "message body" containing Session Description Protocol (SDP). This SDP contains the actual ip address (line (c)) and media port and CODEC type to be used (line (m)). This is the precise address for the RTP media to use and may be different from the contact address.
Please read this post late at night - it will help you sleep :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page