I'd like my Obi202 to take advantage of my Obi110's Line port.
What would be the best way to connect them.
I don't want routing out of the local network.
Mr Joe,
A modified version of this could be used:
http://www.obitalk.com/forum/index.php?topic=2459.msg33156#msg33156
The downside is that it would need a sp on each device to form the link. If you already have an sp using calling without registration, then that can probably be used for this purpose also.
I know you have a very complex setup using OBi's, other ATA's, GSM gateways, etc etc .. so I'm sure that you would cope with the more complex DigitMaps etc needed to make it work as you want.
ianobi,
I have something you can try.
As you know I just purchased a 2nd OBi110.
I setup mine with a Voice Gateway like this:
VG1 AccessNumber sp2(192.168.1.10:5471)
VG1 AuthUserID = WhatEver
Phone OutboundCallRoute = {(xxxxxxxxxx):vg1}
This way you can use SP2 for something else.
I had this setup working but had no audio.
My new OBi110 died before I could resolve this issue.
azrobert,
I'll have to have a look at the vg idea. It would be good not to need to use an sp.
Sorry to hear about a death in your OBi family :'( Is there anything we can learn from the postmortem?
Quote from: ianobi on January 27, 2013, 07:25:18 AM
Sorry to hear about a death in your OBi family :'( Is there anything we can learn from the postmortem?
It sucks that NEWEGG forces you to pay for the return UPS label for a defective item.
I suppose it's standard practice.
There goes my sale price savings.
I had trouble printing the UPS label from NEWEGG's WEB site.
The label printed as a blank rectangle with an "x" in the upper left corner.
If I right clicked on the label image and selected "PRINT", it printed full page truncating the bottom portion of the label. I won't bore you with all the things I tried. What worked was using the Sniping Tool to cut and paste the label into PAINT, then resizing the image by 50%.
I wouldn't call it standard practice. Every company, including Newegg, has return policies. I don't order from anyone without checking those first. I also make sure that the credit card I'm using has coverage if the company won't take it back.
In my experience, Amazon takes back defective items and pays the return shipping, even if you don't rebuy.
For anybody who cares, you can access an OBi with an ATA.
Assuming OBi's address is 192.168.1.10 with default SP2 port 5061.
ATA setup:
Server = 192.168.1.10:5061
UserID = ATA1
Password = WhatEver
Registration = off
OBi SP2 X_InboundCallRoute = {(ATA1)>(xxxxxxxxxx):sp1}
Quote from: Rick on January 27, 2013, 08:59:15 AM
In my experience, Amazon takes back defective items and pays the return shipping, even if you don't rebuy.
Rick,
Thanks for the info. I didn't know Amazon didn't charge return shipping.
In the past I've been very happy with both Amazon and NEWEGG and this is the first time I had to return a defective product.
In the future I'm going to check Amazon first.
azrobert,
I have done some testing on the Voice Gateway idea. I'm also having trouble getting audio to work. Odd really as it's all in the same LAN subnet. I was using a "registered" sp as gateways in both OBi's as this would make the best savings of trunks. It seems ok for the vg to use a "registered" sp for outgoing, but the incoming sp in the other OBi needs to be unregistered.
Testing using "unregistered" sp's as gateways works fine both ways, but is not a great saving of trunks. However, it would mean that you could use several vg's in both OBi's using each others trunks all using one "unregistered" sp in each OBi to create the link. CallerID seems to work fine in both directions.
It looks like a good idea that probably needs more work.
Did any of that make sense?
ianobi,
I was testing by calling my ISP and getting no audio and didn't get to test incoming before my second OBi110 died. I probably got the same result as you. I don't understand why being registered makes a difference. I tried using different RPT ports on the second OBi110. It didn't make a difference.
Before I purchased the 2nd OBi110 I was using an ATA to access the OBI110 as described in my reply #6 above. In this setup the OBi110 could ring an unregistered ATA using a Voice Gateway when SP2 was registered. I'll have to test if the OBi110 can still call a registered ATA.
Update:
I registered the 2nd port on my ATA to a provider. I successfully called that port via VG3/SP2 on my OBi110 with SP2 registered to a provider. I know this is different than one OBi110 making an outbound call on the other, but this should work.
I find I cannot hear the other Party unless I use an Outbound Proxy.
Is it just me at is there a lot of static/white noise when connecting 2 ATAs over A Local connection?
I thought it was just my PAP2 because it was a Chinese imitation but I'm havering the same problem with an Obi202 connected to a Obi110!
Can anyone shed some light on the issue?
Quote from: azrobert on January 27, 2013, 09:04:48 AM
For anybody who cares, you can access an OBi with an ATA.
Assuming OBi's address is 192.168.1.10 with default SP2 port 5061.
ATA setup:
Server = 192.168.1.10:5061
UserID = ATA1
Password = WhatEver
Registration = off
OBi SP2 X_InboundCallRoute = {(ATA1)>(xxxxxxxxxx):sp1}
I can confirm that the above technique posted by azrobert works for one stage dialing with an OBi100 to an OBi110. You can just setup the local net address under a VoiceGateway, setup the VoiceGateway with an AuthUserID for the caller id, and setup the DigitMap and OutboundCallRoute for the call, and setup the inbound call routing on the OBi110 as shown.
It also works from a SPA3102 to the OBi110.
I can not get this to work with an OBi202 to an OBi110. The firmware is different. The call completes but there is one-way audio because the rtp voice stream is not received from the OBi110 by the OBi202.
Edit: See http://www.obitalk.com/forum/index.php?topic=5141.msg33309#msg33309 (http://www.obitalk.com/forum/index.php?topic=5141.msg33309#msg33309).
I'm interested in doing this too, this was my next project. Any help would be appreciated!
Can I run the Obi202 in switch/bridge mode and connect the 202 to router and then the 110 to 202's second port? Would such a setup work even if network router was down (assuming static IP's on both)?
Quoteauthor=hwittenb link=topic=5141.msg33254#msg33254 date=1359336399
I can confirm that the above technique posted by azrobert works for one stage dialing with an OBi100 to an OBi110.
hwittenb,
ianobi and I are getting one way audio with 2 OBi110s.
In my case the firmware levels were the same, but the hardware versions were different.
Any ideas?
Thanks
Edit: ianobi's worked when SP2 was unregistered.
For any newbie that doesn't understand why we want to do the above.
The path for 2 OBi's on the same LAN to talk to each other using OBitalk is:
OBi#1 => LAN => WEB => OBitalk server => WEB => LAN => OBi#2
The path using the above config:
OBi#1 => LAN => OBi#2
Quote from: azrobert on January 27, 2013, 05:44:04 PM
ianobi and I are getting one way audio with 2 OBi110s.
In my case the firmware levels were the same, but the hardware versions were different.
Any ideas?
Thanks
Edit: ianobi's worked when SP2 was unregistered.
I don't have two OBi110's to test out. Just an OBi110, an OBi100, and an OBi202. I don't know why you would get the one-way audio between the two OBi110's. One way audio usually occurs because one adapter doesn't communicate correctly the ip address or port number to be used for the rtp data stream.
Edit: See http://www.obitalk.com/forum/index.php?topic=5141.msg33309#msg33309 (http://www.obitalk.com/forum/index.php?topic=5141.msg33309#msg33309)
In my tests I was calling from SP2 to SP2, both were registered to a voip provider but I don't think that makes any difference, one way or the other. In fact I just ran a test with both unregistered and the result was the same. It worked between the OBi100 and the OBi110. Now I moved the OBi100 to some other ip address and now it gets one-way audio. Flakey
If it doesn't work it is due to some setting or environment factor we haven't discovered. I think this method of direct ip communication is something that really isn't supported or tested by OBi and that's why we get flakey results.
The units appear to accept calls from unregistered sources. The OBi202 has a setting to stop unregistered calls but the default allows it. If fact I tried the setting the OBi202 to stop unregistered calls and it does just that. A voice comes on to scold me.
For 2 way Audio you must us an Outbound Proxy.
Trust me, I've tried all types of Configurations..
You can also use this method to define an OBi as a trunk on PBX in a Flash.
I'm a total novice with PIAF, but this Trunk definition works:
type=friend
username=PIAF
host=192.168.1.10
port=5061
fromuser=PIAF
canreinvite=no
insecure=invite,port
qualify=yes
nat=yes
I wonder if putting PIAF between the 2 OBi's would correct the audio problems.
Point a VG on OBi#1 to a PIAF extension and route the call out the OBi#2 trunk.
I can't do any testing until my dead OBi gets replaced.
Has anyone tried mrjoe's outbound proxy suggestion?
I have consistant results in my setup as follows:
Using two OBi110s both with Hardware Version 2.8 and Software Version 1.3.0 (Build: 2274). (R) = registered to a Service Provider. (U) = unregistered using 127.0.0.1 etc.
OBiA sp(U) > < LAN > < OBiB sp(U)
Call routing and audio ok in both directions. CallerID passed ok in both directions.
vg > OBiA sp(U) > LAN > OBiB sp(U)
Call routing and audio ok. CallerID passed ok.
vg > OBiA sp(R) > LAN > OBiB sp(U)
Call routing and audio ok. CallerID passed ok.
vg > OBiA sp(U) > LAN > OBiB sp(R)
Call routing ok. no audio tx or rx. CallerID passed ok.
vg > OBiA sp(R) > LAN > OBiB sp(R)
Call routing ok. no audio tx or rx. CallerID passed ok.
In this setup Outbound Proxy makes no difference for the unregistered calling. I accept that it may well be needed in some setups. If you are using an sp with a registered service provider, then you cannot mess with the Outbound Proxy without affecting that voip service.
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.
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.
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.
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
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.
Quote from: infin8loop on January 29, 2013, 07:16:40 PM
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.
Anything inside a lan would not need any port forwarding.
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?
Quote from: azrobert on February 26, 2013, 09:05:04 PM
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?
Quote from: Ostracus on February 26, 2013, 09:34:00 PM
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.
Quote from: hwittenb on January 28, 2013, 09:19:10 PM
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.
Quote from: azrobert on March 01, 2013, 08:43:37 AM
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.
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.
Quote from: ianobi on March 03, 2013, 06:12:28 AM
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.
Quote from: ianobi on March 03, 2013, 06:12:28 AM
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. :)
QBZappy - I am most humbly contrite :-[ A person of your great experience and knowledge should never be ignored :)