Best way to connect 2 Obis on Local Network

[ianobi]

hwittenb,

That's interesting. Looking at Call Status while the call is set up, I can observe the same thing regarding RTP being sent to the external address. This behaviour seems to depend entirely on whether or not the X_RegisterEnable box is checked or not. If checked an OBi110 seems to assume the call to be external, if unchecked internal RTP addresses are used.

Using my setup of two OBi110s, I could not get your fix regarding using a unique RTP port range to work for me. My results from my previous post remain the same.

It's not a big deal for me, but may be worth a little more time. As you say, we are trying to use the OBi devices for something they are not really designed for.

[hwittenb]

I ran some more tests and you are correct about Registered vs Unregistered affecting the destination of the rtp stream and I see it also affects where the sip signalling is sent after the call is answered. 

My tests were all from an OBi202 Vg  to a SPA110 SP2.  The Obi202 Vg3 setup AccessNumber SP2(192.168.1.108:5069)) where 192.168.1.108:5069 was the local network address for my OBi110 and my Obi202 Phone Port DigitMap and Outbound Routing sent the call to vg3.

The registered vs unregisterd does not in theory have anything to do with a local network address, however as you say it appears that the OBi firmware considers it in formulating packet addresses.  My tests showed the following in how the rtp stream is addressed, as well as the destination of sip signalling packets after the Sip 200 OK call answered packet is received.

The tests confirm your finding that with both SPx unregistered the addressing works without a problem.

My test results:
Obi202  Obi202       Obi110   OBi11
           rtp -->                    rtp<---
         
reg       external        reg       external
reg       local net       not reg   external
not reg  external       reg         local net
not reg  local net       not reg    local net

Whenever the packets were sent to the external ip address you encounter a potential problem.

In my case port forwarding in my router solves the problem of where to deliver the packets that are sent to the network's external ip address.  Since both adapters use the same sip port numbers and the same rtp port number ranges it is necessary to change these numbers to unique numbers before the port forwarding in the router.

If this problem circumvention doesn't work with your router, then the routers must not work in the same manner.

[QBZappy]

A work around might be to fake a lan ip in the public address setting here. Have a look at the info bubble for a description.:

ITSP Profile X
    General
    SIP
X_DiscoverPublicAddress   
X_PublicIPAddress

[infin8loop]

Just wanted to do a quick shoutout of thanks to ianobi, hwittenb, and azrobert and anyone else I may have missed for the info posted here. I've been trying to get Obi1 to Obi2 SIP calls to work since buying the second OBi110 last year.
I've tried various combinations of speed dials and vg, including speed dials with the "op" options like
SP2(1234@192.168.0.42:5063;op=imns) in various combinations of "imns" and with various combinations of STUNEnable, X_ICEEnable, and X_SymmetricRTPEnable enabled or disabled. The best I was able to achieve was 1-way audio, if any audio at all. I had also noticed that sometimes the external IP address was used by RTP in some of the combinations tested and those never had even 1-way audio.

I tried a quick test while the spousal unit was out of the house of the unregistered SPx approach and it worked.

I find it somewhat confusing that I have a free London DID configured at https://www.3c.co.uk/ui/
to go to: sip:4420xxxxxxxx@xxxxxxxx.dyndns.org:5061  My Obi1 is SIP 5060/5061 and Obi2 is SIP 5062/5063. All 4 (2 on each OBi110) RTP ranges are unique and I have port forwards for the SIP and RTP ranges to the appropriate OBi set in the router. Calls to the London DID work fine and they come in on OBi1 SP2 which is registered to voip.ms. The calls do not come through voip.ms and I don't expect them to.  But then internal SIP calls from Obi to Obi fail miserably. I know it's internal addressing but I don't begin to understand why.

[hwittenb]

But then internal SIP calls from Obi to Obi fail miserably. I know it's internal addressing but I don't begin to understand why.

The subject can get very confusing when you are dealing with internal and external ip addresses. The DID that you have forwarding to your dyndns address is coming from an external ip address to the OBi202's external ip address and you have the port numbers forwarded to SP2.  Your router sends the packets on to SP2 via its internal ip address.  Responses from SP2 go back to the caller's external ip address.  When the SP2 responds it places its external ip address and port number inside the response packets.

Internal sip calls are between local network ip addresses.  We find that in certain cases the OBi wants to change the addresses to the local network's external address and since the external address is the same for everything in the local network the only thing unique about the address can be the port number.  Sending a packet that needs to go just inside the network to the external network's ip address is not a normal occurence and the local network's router may or may not handle the situation correctly.

[QBZappy]

Anything inside a lan would not need any port forwarding.

[azrobert]

I discovered the following by accident:

If OBi#1 is calling OBi#2 and
   SP2 on OBi#2 is registered to an Asterisk based system like PBXes.org or PBX in a Flash
   The call completes WITHOUT any audio problems.

Can anybody explain the above?

[Ostracus]

I discovered the following by accident:

If OBi#1 is calling OBi#2 and
    SP2 on OBi#2 is registered to an Asterisk based system like PBXes. org or PBX in a Flash
    The call completes WITHOUT any audio problems.

Can anybody explain the above?

What about #2 to #1?

[azrobert]

What about #2 to #1?

OBi#2 to OBi#1 still has one-way audio.
If OBi#1 is also registered to an Asterisk based system then the call is successful.

[azrobert]

I finally got my wireshark packet trace more or less working correctly and I now see what is happening with the one-way audio when I call the OBi110 from the OBi202 over my local network.  When the OBi110 starts up its rtp voice packet stream instead of sending the packet stream to the OBi202 local network address it sends its rtp packet stream to the (correct port number) at the local network's external ip address.  The router discards the packet and you have one-way audio. To circumvent the problem, I setup a unique rtp port range for the OBi202 and in my router forwarded that unique port range to the OBi202 and the call works correctly.

I was thinking about what hwittenb said about the OBi sending RTP to the external IP address when I saw the following option on the OBi:
ITSP Profile B ==> SIP ==> X_DiscoverPublicAddress

I turned X_DiscoverPublicAddress off just to see what would happen and to my amazement it fixed the one-way audio problem.
My OBi#1 can call OBi#2 because SP2 on OBi#2 is registered to PBXes.org. See my reply#26.
Now OBi#2 can call OBi#1 with the above change to OBi#1.

Anyone know if this setting will cause problems?
Everything seems to work with this change.
Inbound and outbound calls work with my registered provider on SP2.
I can call the OBi externally using me.dyndns.com:5061

Warning:
After you make this change you end up with two registrations on your SP2 provider. The first is the registration you had before the change and will go away when the registration time period expires. I don't think this will cause problems, but I'm not an expert. It didn't cause problems with my provider.

[hwittenb]

I was thinking about what hwittenb said about the OBi sending RTP to the external IP address when I saw the following option on the OBi:
ITSP Profile B ==> SIP ==> X_DiscoverPublicAddress

I turned X_DiscoverPublicAddress off just to see what would happen and to my amazement it fixed the one-way audio problem.

azrobert,

I think you made a major discovery of a setting causing trouble with local network direct ip calling.

I tested it with my OBi100 calling, with a local network ip call, my OBi110 to bridge a call out the line port on the OBi110.  The call was from the OBi100 to the OBi110 SP2 configured for sip.  With X_DiscoverPublicAddress set to the default (checked) the local network call had one-way audio because the rtp packet stream from the OBi110 to the OBi100 was not directed properly when the OBi110's SP2 was registered to a Sip provider.  It worked correctly if SP2 was not registered to a sip provider.  With your discovery to uncheck X_DiscoverPublicAddress the call works correctly now when SP2 is registered to a sip provider.

The unchecking of X_DiscoverPublicAddress does not appear to affect regular incoming or outgoing call on SP2 using the registered sip provider, at least with my testing of CallCentric and Callwithus.

[ianobi]

I have repeated my tests as in Reply #18 after unchecking X_DiscoverPublicAddress. All now work correctly, with all calls using only internal addresses.

azrobert - thanks for making us look again. This does seem to be the answer. It could lead to much more efficient use of OBi trunks and voice gateways spread over several OBis in the same network.

hwittenb - thanks for the clear explanations, which helped me to understand what is going on.

QBZappy - deserves a quick mention as he raised this possibility in Reply #22. I decided not to try it as I thought it would interfere with the normal working of the registered service provider. Looks like I was wrong on that one!

The one question remains - when does X_DiscoverPublicAddress need to be checked? Are there times when it is useful? My tests with sipgate.co.uk and sip2sip seem to indicate that it makes no difference checked or unchecked.

[Ostracus]

The one question remains - when does X_DiscoverPublicAddress need to be checked? Are there times when it is useful? My tests with sipgate.co.uk and sip2sip seem to indicate that it makes no difference checked or unchecked.

It could be something to help the unit deal with a broken NAT.

[QBZappy]

QBZappy - deserves a quick mention as he raised this possibility in Reply #22. I decided not to try it as I thought it would interfere with the normal working of the registered service provider. Looks like I was wrong on that one!

No one ever listens to me! Try it you'll like it. 

[ianobi]

QBZappy - I am most humbly contrite    A person of your great experience and knowledge should never be ignored