Routing OBi202 calls to OBi1032 IP Phone...
ianobi:
@ 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.
drgeoff:
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.
ianobi:
Quote
I 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.
N7AS:
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.
ianobi:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page