Direct SIP dialing & direct IP dialing question

[VOIP_JoeSummy]

I did some experimentation with direct SIP address dialing and direct IP address dialing.

First I installed the Linphone softphone app to my Laptop.

Then I set my OBI110 SP1 to register with a SIP account, let's say, abc@iptel.org, and I set SP2 to be not registered, but still with a local dummy proxy and a user name of "1", and I set up router port forwarding for it.

Now, if I add and register a SIP account to my Linphone softphone app, I can call both my OBI SP1 ( using:  sip: abc@iptel.org ) and SP2 ( using:  1@My_Modem_Public_IP:5061 ) from this app from my laptop.

But if I remove this SIP account from my Linphone softphone app, to make it make outgoing calls with some default SIP identity, like  sip:1@192.168.0.2,  then I can still call my OBI SP1, but no longer the SP2.

Can someone give me some clues on it?  What extra steps do I need for direct IP->IP dialing?  Or is this softphone app inherently unable to do it?

[azrobert]

First, I'm not familiar with Linphone. I use Phonerlite on my Windows computers.

I don't understand what you are trying to do.
Is Linphone register to a different service and you don't want to use that service?
You can define multiple accounts on Phonerlite.
You would define the 1st account to register to your service connected to SP1.
The 2nd you would point the Proxy to your public IP address and port 5061.
Use the 1st account to call SP1 and the 2nd to call SP2.

Edit:
Is the computer and OBi on the same LAN?

[ianobi]

But if I remove this SIP account from my Linphone softphone app, to make it make outgoing calls with some default SIP identity, like  sip:1@192.168.0.2,  then I can still call my OBI SP1, but no longer the SP2.

I'm guessing that the Linphone / SIP account was using some sort of STUN arrangement to resolve the routing to sp2. The problem with an unregistered spX is that it normally sends back its internal ip address as its contact in the "OK" message. One way of getting it to send back its external ip address is described in this post - note the "keep-alive" settings.

http://www.obitalk.com/forum/index.php?topic=8511.0

The calling softphone needs to be able to "call without registration". I'm not familiar with Linphone. I do find that Phonerlite is good for this type of testing from laptop or pc as it can have registered or unregistered accounts and has a good debug facility. It's free, so no harm in trying.

Edit: posted before I read azrobert's comments. I'm assuming that you took the laptop to some remote place away from your local subnet and used a wifi hotspot or similar.

[VOIP_JoeSummy]

The Linphone softphone app is able to make outgoing calls without registration. Otherwise it won't be able to call the sip account at my OBI SP1.

Why do we need the KeepAlive stuff here? The caller, the Linphone softphone app, already knows the public IP of the callee, since it is calling to:    1@My_Modem_Public_IP:5061.  It does not need the callee to tell it the callee public IP address AGAIN. Is there some inefficiency in the whole SIP protocol  specification/design?

[ianobi]

Time to get a bit SIP nerdy here (and I'm missing out lots of details)

The caller (Linphone) sends an "INVITE" message using SIP protocol which contains a header with its "contact" details, that is its ip address and port to send the RTP protocol (speech) to. This message may be routed through many servers along the way depending on your ISP and it gets routed to:

1@My_Modem_Public_IP:5061

That's the ip address and port  of your OBi110 sp2. So far so good. Then your OBi110 sp2 will answer with an "OK" message using SIP protocol most likely back along the same route and many servers with its "contact" details, that is its ip address and port to send the RTP protocol (speech) to.

Now comes the clever part. Speech using RTP protocol needs the most direct path possible to keep latency etc to a minimum. Both devices now have each others actual ip address and port via the "contact" headers so they can send the speech (RTP) directly from one ip address and port to the other, not using the same route as the SIP protocol, which is used to set up, control and tear down the call.

An example of this is calling one OBi device to another using the OBiTALK network with both devices in your home router subnet. The call will be set up using the Obihai servers which may be very remote depending where you are in the world, but the speech will stay within your home subnet because the "contact" details of both devices will see that this is the most direct route.

I hope that helps - I have left out lots of detail, but the basics are SIP signalling routes like most computer data stuff, then the RTP speech stuff goes direct. This is why it can go wrong if the unregistered OBi110 spX gives out its private ip address and port rather than its public address and port as its contact.

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

( 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   

[azrobert]

I installed Linphone on a test computer connected to the same network as my OBi110.
I defined an SIP account on Linphone pointing to the OBi110 like:
SIP Identity: sip:robert@192.168.1.100:5060
SIP Proxy: sip:192.168.1.100:5060
Register: Unchecked

I dialed 0 on the Linphone.
The call was successful with 2 way audio.

I created a 2nd network by connecting the WAN port of a test router to a switch port on the original network.
I connected the computer running Linphone to the 2nd network.
I repeated the test.
The call was successful, but with 1 way audio.

I enabled Symmetric RTP on the OBi110's SP1.
I repeated the test.
The call was successful with 2 way audio.

I know this is not the same as calling from a hotspot, but this is how I diagnosed the problem calling from an Android/CSipSimple. I received similar results from Android/CSipSimple, but I believe there was no audio from a hotspot without Symmetric RTP enabled.

I'm running DD-WRT FW on both routers.

Edit:
When I was testing Android/CSipSimple I displayed the Call Status on the OBi110. It showed the RTP packets flowing in both directions. I'm not a network expert, but I think when there is a NAT problem you don't see the RTP packets flowing. This led me to try the Symmetric RTP.

[ianobi]

Yes, I agree that Symmetric RTP is helpful in this direct ip to ip situation. Also, I enable ICE on both the OBi and CSipSimple and this helps for some networks that do not otherwise work.

It is difficult setting up test situations. From my home I can connect to a British Telecom wifi hotspot, so I can observe calls coming into my network and record them using Wireshark. Using this setup I have solved many problems, but then I go out to a coffee shop or pub and sometimes it does not work from their wifi hotspot     When visiting my brother I found that I had to enable "Aggressive ICE" on CSipSimple to make it work. There's lots of variations out there when it comes to wifi hotspots!

By the way, CSipSimple does have a good call logging facility. If you enable it, then it will log the SIP interactions during a call setup etc and place them in a folder on your phone called CSipSimple > Logs. Easier to view if you download them to a pc.

I may have a look at Linphone. There's not many softphones around that allow calling with no registration.

[azrobert]

I may have a look at Linphone. There's not many softphones around that allow calling with no registration.

When I started testing Linphone there was no audio.
Linphone was defaulting to the wrong Playback and Ring device.
Under Help/Audio Assistant you can test these settings.