I am using an OBi202 and OBi1032 and would like to receive all calls coming into my OBi202 on my OBi1032 IP Phone.
I tried using an OBiLINE to do this, but found that it would not work as I use the OBiBT on my OBi1032 to connect to my cellphone. As both of these devices have to be connected to USB Port2 on the OBi1032 it would not work. I also tried using a non powered USB HUB connected to USB Port2, but that did not work either.
There should be a way to route calls from the OBi202 to the OBi1032 using pp(500xxxxxx) in the InboundCallRoute on the OBi1032.
I also would like to route outbound calls to the OBi202 using a prefix like <8:>1xxxxxxxxxx as I already do to CirckeNET for some US and International numbers via a VoiceGateway
.
I do not have any SP Slots on either device to create any dummy SPs.
Hi Grant – I remember earlier in the year you had a complex setup containing three OBi devices with links between all three. I guess the setup has changed or this is a new setup. Anyhow, I'll ignore your past setup and assume this is new. If the OBi202 and OBi1032 are both in the same router subnet, then the easiest way is to fork incoming calls to the OBi202 as follows:
OBi202 all InboundCallRoutes:
{ph1,ph2,spX(202@192.168.1.20:5063)}
Remove ph1,ph2, if you do not want the OBi202 phones to ring.
spX – any lightly used OBi202 sp.
192.168.1.20:5063 – example of ip address:port of chosen lightly used OBi1032 sp.
OBi1032 InboundCallRoute of sp chosen above:
{>202:ph},{ph}
There may be issues regarding CallerID, but if the above works ok for you, then we can try to sort that out. It's ok to use "in use" spX's for more than one use, but for each spX used this way I would set:
Voice Services -> SPx Service -> MaxSessions : 4
QuoteI also would like to route outbound calls to the OBi202 using a prefix like <8:>1xxxxxxxxxx
Do you mean dialling from the OBi1032 using a service set up on an OBi202 sp? If so, that can be done, but is a little more complex. I'll have a go if you tell me that both devices are in the same router subnet.
Hi Ian,
I figured that I want CID to pass, I would use: {ph,sp1(202@192.168.1.32:5062;ui=$1)}
Would this work?
Now, how about the OBi1032 InboundCallRoute, I use NoMoRobo such as:
ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)
Will that conflict? Would I set it as: {>202:ph},{ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)}
Quote from: N7AS on December 16, 2015, 04:50:08 PM
There should be a way to route calls from the Obi202 to the OBi1032 using pp(500xxxxxx) in the InboundCallRoute on the OBi1032.
That should go in the InboundCallRoute of the 202, not the 1032. The number should be that of the 1032. I believe CID will be forwarded too.
Quote from: drgeoff on December 17, 2015, 05:12:40 PM
Quote from: N7AS on December 16, 2015, 04:50:08 PM
There should be a way to route calls from the Obi202 to the OBi1032 using pp(500xxxxxx) in the InboundCallRoute on the OBi1032.
That should go in the InboundCallRoute of the 202, not the 1032. The number should be that of the 1032. I believe CID will be forwarded too.
So you are saying to put {ph,pp(610xxxxxx)} in the InboundCallRoute of each spx in the 202?
Or maybee {ph,pp(610xxxxxx);ui=$1} to pass CID?
I don't have NoMoRobo confogured on the 202, but may impliment it there in the future. If so, how would I do this?
The NoMoRobo I use on the 1032 is:
X-InboundCallRoute
ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)
@ Grant – if both OBi's are in the same router subnet and you have static local ip addresses for them, then I would keep all routing within your local router subnet. From other posts, I believe this is the case in your setup.
If you choose to use the OBiTALK routing {ph,pp(610xxxxxx)}, then you are using Obihai's servers to set up and control the call, even though the speech should remain local. Seems like added complication to me. It is a useful method if one OBi is remote and not in the same router subnet. If this method is used, then there is no need to use the "ui" operator as OBiTALK will always pass CallerID.
Back to the local method! I find the "ui" operator is not required when forking the call to another OBi, so this should work and pass CallerID:
OBi202 all InboundCallRoutes:
{ph,sp1(202@192.168.1.32:5062)}
OBi1032 InboundCallRoute:
{>202:ph},{ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)}
This would be selective – calls forwarded from the OBi202 would ring the OBi1032 phone, but would not be forked to callwithus.
OBi1032 InboundCallRoute:
{ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)}
This would not be selective – calls forwarded from the OBi202 would ring the OBi1032 phone and be forked to callwithus. This would mean that there is no need to set up NoMoRobo on the OBi202.
I'll post again regarding the second part of your original post.
Quote from: N7AS on December 17, 2015, 05:43:42 PM
Quote from: drgeoff on December 17, 2015, 05:12:40 PM
Quote from: N7AS on December 16, 2015, 04:50:08 PM
There should be a way to route calls from the Obi202 to the OBi1032 using pp(500xxxxxx) in the InboundCallRoute on the OBi1032.
That should go in the InboundCallRoute of the 202, not the 1032. The number should be that of the 1032. I believe CID will be forwarded too.
So you are saying to put {ph,pp(610xxxxxx)} in the InboundCallRoute of each spx in the 202?
Or maybee {ph,pp(610xxxxxx);ui=$1} to pass CID?
Yes, {ph,pp(610xxxxxx)} in the X_InboundCallRoute of SPx will ring both the 202 phone and the 1032. The 1032 will receive the CID. No need for the ui=$1 part.
QuoteI also would like to route outbound calls to the OBi202 using a prefix like <8:>1xxxxxxxxxx
First check that this is really needed. Most voip service providers will allow you to make outgoing calls without the need for registration. It may be easier to set up a VG on the OBi1032 using the same credentials as the ones used for the relevant OBi202 spX.
If you really want to use this sort of setup (OBi202 sp2 as example):
OBi1032 >>> OBi202sp2 >>> voip service
Then I suggest this setup, which I believe will be new to most readers here:
OBi1032
Physical Interfaces > PHONE Port > DigitMap:
( ... existing rules here ... |8(Mabc)| ... existing rules here ... )
Physical Interfaces > PHONE Port > OutboundCallRoute:
... existing rules here ... ,{(8(Mabc)):spX}, ... existing rules here ...
User Settings > User Defined Digit Maps > User Defined Digit MapX >
Label: abc
DigitMap: ((xx.)<:@192.168.1.10:5061>|xx.'@192.168.1.10:5061')
spX = lightly used OBi1032 sp
192.168.1.10:5061 = ip address:port of OBi202 sp2
OBi202
Voice Services > SP2 Service > X_InboundCallRoute:
{>(<8:>(Msp2)):sp2},{ph}
CallerID and CName is passed using this method, but that is not relevant here as you will want to use the credentials of the service set up on sp2, which the OBi202 will do automatically so long as you have not enabled spoofing.
Quote from: ianobi on December 18, 2015, 04:05:35 AM
@ Grant – if both OBi's are in the same router subnet and you have static local ip addresses for them, then I would keep all routing within your local router subnet. From other posts, I believe this is the case in your setup.
If you choose to use the OBiTALK routing {ph,pp(610xxxxxx)}, then you are using Obihai's servers to set up and control the call, even though the speech should remain local. Seems like added complication to me. It is a useful method if one OBi is remote and not in the same router subnet. If this method is used, then there is no need to use the "ui" operator as OBiTALK will always pass CallerID.
Back to the local method! I find the "ui" operator is not required when forking the call to another OBi, so this should work and pass CallerID:
OBi202 all InboundCallRoutes:
{ph,sp1(202@192.168.1.32:5062)}
OBi1032 InboundCallRoute:
{>202:ph},{ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)}
This would be selective – calls forwarded from the OBi202 would ring the OBi1032 phone, but would not be forked to callwithus.
OBi1032 InboundCallRoute:
{ph,sp2(1866xxxxxxx@tf.callwithus.com;ui=$1)}
This would not be selective – calls forwarded from the OBi202 would ring the OBi1032 phone and be forked to callwithus. This would mean that there is no need to set up NoMoRobo on the OBi202.
I'll post again regarding the second part of your original post.
I tried this method. Both my 202 and 1032 ring but get no audio. I also noticed that the CID displayed on the 1032 is my UsedID of SP1 on the 202 which is Localphone and it's my primary line on the 202.
In this rule:
OBi202 all InboundCallRoutes:
{ph,sp1(202@192.168.1.32:5062)}
sp1 can be any of the OBi202 spX. Use one that is not going to be "through-dialled" from the OBi1032 in the ultimate plan and change this:
Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID : checked
This should solve the CallerID problem.
The no audio problem is very odd for two devices in the same router subnet. You might get some clues by looking at Status > Call Status in both devices while the call is in progress. Look for something like this in the OBi202:
Terminal ID SP1 SP2
State connected connected
Peer Name ianphone
Peer Number 832 833@192.168.1.18:20615
Start Time 13:49:56 13:49:56
Duration 00:00:09 00:00:09
Direction Inbound Outbound
Peer RTP Address 192.168.1.16:20222 192.168.1.18:17402
Local RTP Address 192.168.1.10:16000 192.168.1.10:16202
RTP Transport UDP UDP
Audio Codec tx=G711U; rx=G711U (bridged) tx=G711U; rx=G711U (bridged)
RTP Packetization (ms) tx=20; rx=20 (bridged) tx=20; rx=20 (bridged)
RTP Packet Count tx=460; rx=480 tx=480; rx=459
RTP Byte Count tx=79120; rx=82560 tx=82560; rx=78948
Something like this in the OBi1032:
Terminal ID SP5 PHONE1
State connected connected
Peer Name ianphone
Peer Number 832
Start Time 13:49:58 13:49:58
Duration 00:02:28 00:02:31
Direction Inbound Inbound
Peer RTP Address 192.168.1.10:16202
Local RTP Address 192.168.1.18:17402
RTP Transport UDP
Audio Codec tx=G711U;rx=G711U
RTP Packetization (ms) tx=20.0; rx=20.0
RTP Packet Count tx=7427; rx=7447
RTP Byte Count tx=1277444; rx=1280884
In both cases the "Audio Codec" lines will give a good indication if audio is connected in both directions.
There is a potential problem with the way that OBi devices handle codecs when calls are bridged. Try giving both OBi devices G711u codec as their only choice of codec and see if that works.
I feel that I may not be seeing the bigger picture of how your setup looks just now. Maybe you could pm me with a more detailed view of how it's setup and which sp services you want each device to "through-dial" using bridging.
Anyhow, for now let's see if we can get call forking to work from incoming calls to the OBi202 forked onward to the OBi1032.
Is there a reason for not forking via the Obitalk network? I am doing that myself from an OBi110 to a OBi1032 and can confirm it works. Bothway audio and CID of the call into the 110 appearing on the 1032.
Using the OBITALK network is very useful in some circumstances. It does mean that the two OBi devices can be anywhere in the world and it works well. However, when both devices are in the same router subnet, maybe even in the same room as in my case, it does seem to be adding unnecessary points of failure to use the Obihai servers to control the call.
SIP is very easy to simply direct from one OBi to another within the same router subnet, or anywhere with fixed ip addresses. Although this thread may be making it look quite difficult!
Within my router subnet I have two active OBi devices, two softphones on mobile phones (using wifi) and softphones on a pc and laptop. They all can call each other and use all the two OBi's services with no problems using this direct local method. It really works :)
The odd thing here is that Grant has in the past had a setup involving three OBi devices working with this local SIP forking and routing. Something has changed ::)
ianobi,
X_DiscoverPublicAddress ?
@ azrobert - all ideas are welcome :)
I find that when forking calls within the same router subnet X_DiscoverPublicAddress makes no difference. The suggestion being here that unchecking it will help. The problem is that the voip service that is using a particular spX may need it checked to work for outgoing calls.
I have both cases in my setup and internal call forking seems to work very well. However, every setup is different and routers can behave differently, so experimenting is always the way to go.
Another precaution I would also take if there is more than one OBi device in the same router subnet is to make sure that every spX across both devices have a unique X_UserAgentPort and a unique RTP range.