News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Setting up an Obi 202 + Obiline in the UK (Draft)

Started by Mouse, July 10, 2015, 04:26:34 AM

Previous topic - Next topic

ianobi

@ NoelB

If the OBi202 sp2 is not presently in use, then it needs to be set as a "fake" voip service as detailed above, except do not check:
Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID

No need to drop the existing voip provider presently on OBi110 sp2. The trick here is identify all calls that are coming into the OBi110 sp2 from the OBi202 sp2 and route them to the OBi110 Line Port.

OBi110 Voice Services > SP2 Service > X_InboundCallRoute:
{12345>(xx.):li},{...existing rules here...

Where 12345 is the CallerID of the OBi202 sp2. This is the value:
OBi202 Voice Services -> SP2 Service -> AuthUserName : 12345
Obviously, substitute what you may already have in place of 12345.

To ensure the existing voip calls and these redirected calls can all be handled at the same time I would increase this setting like so:

OBi110 Voice Services -> SP2 Service -> MaxSessions : 4


Mouse

#61
Quote
Firstly, get the simple rule detailed above working!

Hmm sorry. Well it is sending but nothing is being received by the Obi202.

Here is the Obi110 log
Terminal ID   LINE1   SP2
Peer Name      
Peer Number      192.168.1.21:5062
Direction   Inbound   Outbound
13:39:35   Ringing   Forking to:PHONE1, SP2(192.168.1.21:5062)
13:39:36      Call Connected
13:39:41      End Call

Nothing on the 202 call log. I have checked IP and port. I have also tried setting up a fake service on the 202 as well as one that is currently in use.

Could the 202 be listening on its own network?

ianobi

This address SP2(192.168.1.21:5062) should aim the call at sp3 on the OBi202. sp3 needs to be enabled and its InboundCallRoute needs to be "ph,ph2". Both these should be the default condition, but it is worth checking.

I don't see why it should make any difference if the OBi202 is in router or bridge mode, but you could try both to be certain.

The test call seems to have been very short - answered after 1 second I assume by the phone attached to the OBi110. Maybe try a little longer.

Mouse

#63
Quote from: ianobi on July 23, 2015, 07:16:43 AM
This address SP2(192.168.1.21:5062) should aim the call at sp3 on the OBi202. sp3 needs to be enabled and its InboundCallRoute needs to be "ph,ph2". Both these should be the default condition, but it is worth checking.
Checked those, they are correct

Quote
I don't see why it should make any difference if the OBi202 is in router or bridge mode, but you could try both to be certain.
Checked makes no difference

Quote
The test call seems to have been very short - answered after 1 second I assume by the phone attached to the OBi110. Maybe try a little longer.
Checked with no phone attached to the 110, but a phone directly attached to PSTN socket

Directly attached phone gives one ring, then it appears the 110 answers as well as forking the call.

Puzzling..... Any thoughts?



Mouse

#64
OK now it works.

Your original syntax, not the manual was right:

{ph1,sp2(1@192.168.1.21:5063)}

(I am using SP4 now, a fake service on the 202, and one of my normal services on the 110)

Some echo being heard.. I guess due to the additional delay. Lets see if its better than the 202 alone.

*Log from 110*
Terminal ID   LINE1   SP2
Peer Name      
Peer Number      1@192.168.1.21:5063
Direction   Inbound   Outbound
16:07:44   Ringing   Forking to:PHONE1, SP2(1@192.168.1.21:5063)
16:07:59      Call Connected
16:13:21   End Call


*Log from 202*
16:07:45   From SP4(30184009)   Fork to:
PH1
PH2
16:07:45      Ringing (PH1)
16:07:45      Ringing (PH2)
16:07:58      Call Connected (PH2)
16:13:21   Call Ended   

ianobi

I don't have an OBi202, but I've just simulated your setup using an OBi110 and an OBi1032. Either firmware has changed or I'm just getting senile and forgetful! It seems the "@" format is required.

OBi110 Physical Interfaces > LINE Port > InboundCallRoute:
{ph,sp2(602@192.168.1.23:5062)}

Set up fake OBi202 sp3 as follows:

Service Providers -> ITSP Profile C -> SIP -> ProxyServer : 127.0.0.1

Voice Services -> SP3 Service -> Enable : (checked)
Voice Services -> SP3 Service > X_InboundCallRoute: {>602:ph,ph2}
Voice Services -> SP3 Service -> AuthUserName : (any letters or numbers but not blank)
Voice Services -> SP3 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP3 Service -> X_ServProvProfile : C
Voice Services -> SP3 Service -> CallerIDName : Whatever

This works for me all the time.


QuoteDirectly attached phone gives one ring, then it appears the 110 answers as well as forking the call.

That's very odd. Maybe its a symptom of the wrong setup. See how it goes with the new setup.


Mouse

I think we discovered the same thing at the same time - see above!!!!

ianobi

I was typing at the same time as you! If fake provider needed for sp4 use Profile D and change sp3 to sp 4 in last post.

I don't think this setup should add any delay. I wonder if echo is maybe an impedance matching problem between the OBi110 and line. Is there any echo when answering a call on the OBi110 Phone Port?

Mouse

Quote from: ianobi on July 23, 2015, 08:30:51 AM
I was typing at the same time as you! If fake provider needed for sp4 use Profile D and change sp3 to sp 4 in last post.

I don't think this setup should add any delay. I wonder if echo is maybe an impedance matching problem between the OBi110 and line. Is there any echo when answering a call on the OBi110 Phone Port?

The Obi 110 has less echo typically than the 202+Obiline, and a shorter delay echo, so the canceller copes well

This arrangement seems to create a long delay echo, though the canceller does seem to learn it. Or the jitter buffer reduces.

Echo always has an impedance matching element, in general it is not possible to match impedance exactly as they vary with frequency. But I cannot see how an additional one is being added here - the 110's behavior should be the operative one line-wise I would think, and the 202 phone-wise. The 101 and 202 phone impedances are identical. My line is challenging impedance-wise - I am 2-3 miles from the exchange.

What probably would introduce a further delay would be 1) an analog to digital conversion 2) adaptive jitter buffer starting. large. I think it must be 2. There is a star code to kill the jitter buffer for one call.

Mouse

Quote from: Mouse on July 23, 2015, 08:47:07 AM
Quote from: ianobi on July 23, 2015, 08:30:51 AM
I was typing at the same time as you! If fake provider needed for sp4 use Profile D and change sp3 to sp 4 in last post.

I don't think this setup should add any delay. I wonder if echo is maybe an impedance matching problem between the OBi110 and line. Is there any echo when answering a call on the OBi110 Phone Port?

The Obi 110 has less echo typically than the 202+Obiline, and a shorter delay echo, so the canceller copes well

This arrangement seems to create a long delay echo, though the canceller does seem to learn it. Or the jitter buffer reduces.

Echo always has an impedance matching element, in general it is not possible to match impedance exactly as they vary with frequency. But I cannot see how an additional one is being added here - the 110's behavior should be the operative one line-wise I would think, and the 202 phone-wise. The 101 and 202 phone impedances are identical. My line is challenging impedance-wise - I am 2-3 miles from the exchange.

What probably would introduce a further delay would be 1) an analog to digital conversion 2) adaptive jitter buffer starting. large. I think it must be 2. There is a star code to kill the jitter buffer for one call.

Jitter seems likely from this 202 call status. It also seems to be repacketising, possibly because I have different RTP packet sizes set?

Terminal ID   SP4   PHONE1
State   connected   connected
Peer Name      
Peer Number   30184009   
Start Time   16:50:33   16:50:33
Duration   00:00:07   00:00:07
Direction   Inbound   Inbound
Peer RTP Address   192.168.1.23:16804   
Local RTP Address   192.168.1.21:17110   
RTP Transport   UDP   
Audio Codec   tx=G711A; rx=G711A   
RTP Packetization (ms)   tx=10; rx=20   
RTP Packet Count   tx=731; rx=365   
RTP Byte Count   tx=67252; rx=62780   
Peer Clock Differential Rate   0 PPM   
Packets In Jitter Buffer   5   
Packets Out-Of-Order   0   
Packets (10ms) Interpolated   0   
Packets Late (Dropped)   0   
Packets Lost   0   
Packet Loss Rate   0 %   
Packet Drop Rate   0 %   
Jitter Buffer Length   90 ms   
Received Interarrival Jitter   2 ms   
DTMF Digits Received   0   
Jitter Buffer Underruns   0   
Jitter Buffer Overruns   0   
Sequence number discontinuities   0   
skew compensation   0 ms   
send silence   0   
MOS   4.42   

Mouse

OK same packet size, now it is passed straight thru to 202. No call status.

Mouse

Quote from: Mouse on July 23, 2015, 08:59:12 AM
OK same packet size, now it is passed straight thru to 202. No call status.

Sorry my mistake picked up wrong phone!

Jitter is very high for a lan - what gives I wonder?

Problem remains:
Terminal ID   SP4   PHONE1
State   connected   connected
Peer Name      
Peer Number   30184009   
Start Time   17:02:33   17:02:33
Duration   00:00:05   00:00:05
Direction   Inbound   Inbound
Peer RTP Address   192.168.1.23:16806   
Local RTP Address   192.168.1.21:17118   
RTP Transport   UDP   
Audio Codec   tx=G711A; rx=G711A   
RTP Packetization (ms)   tx=10; rx=10   
RTP Packet Count   tx=548; rx=546   
RTP Byte Count   tx=50416; rx=50232   
Peer Clock Differential Rate   0 PPM   
Packets In Jitter Buffer   9   
Packets Out-Of-Order   0   
Packets (10ms) Interpolated   3   
Packets Late (Dropped)   1   
Packets Lost   3   
Packet Loss Rate   0 %   
Packet Drop Rate   0 %   
Jitter Buffer Length   90 ms   
Received Interarrival Jitter   10 ms   
DTMF Digits Received   0   
Jitter Buffer Underruns   1   
Jitter Buffer Overruns   0   
Sequence number discontinuities   3   
skew compensation   10 ms   
send silence   0   
MOS   4.40   
      

ianobi

I just called from my OBi110 to my OBi1032 using direct ip to ip calling and got these results on same call:

OBi110
Jitter Buffer Length  170 ms
Received Interarrival Jitter  1 ms

OBi1032
Jitter Buffer Length 250 ms 
Received Interarrival Jitter 0 ms

Both devices are in the same lan subnet. Any query to Obihai normally gets the reply "the Jitter Buffer is fully adaptive to network conditions". I would expect my two devices in the same room as the router would be a pretty much perfect network! The OBi110 Jitter Buffer Length does slowly reduce, but I have never seen it below 120. The OBi1032 simply stays at 250 - I think there may need to  be some firmware tweaking on that one!

To be fair, call quality seems very high and MOS is good as it should be over a perfect network!


Mouse

#73
From manual:

$NOEC1 = Disable echo canceller once in the next call on this phone port (phone
-
port specific;
admissible
value: 1) (Not
available on OBi100/OBi110)

$NOJI1
= Disable jitter buffer adjustment once in the next call on this phone port (phone
-
port specific;
admissible
value: 1)
(Not available on OBi100/OBi110)

I am not sure if disabling the adjustment gets you a low value......

ianobi

This has come up before in connection with sending pace maker data over a voip connection!

QuoteOBI200 ATA Unit – See http://www.obihai.com/OBiDeviceAdminGuide
Add a star code *99 as this:
*99, Modem Call, set($Noji1,200),set($Noec1,1),set($Cdm1,1),call(18002975493)
The 3 set() commands tell the obi to do the following for the next outbound call:
1. Disable Jitter Buffer Adjustment, and use a fixed jitter buffer length of 200 ms
2. Disable Echo Canceller
3. Use only G711u codec

Change Codecs
G711U  PacketizationPeriod = 10

I think I'm going to need a beer later   8)

Mouse

#75
Quote from: ianobi on July 23, 2015, 09:51:51 AM
This has come up before in connection with sending pace maker data over a voip connection!

QuoteOBI200 ATA Unit – See http://www.obihai.com/OBiDeviceAdminGuide
Add a star code *99 as this:
*99, Modem Call, set($Noji1,200),set($Noec1,1),set($Cdm1,1),call(18002975493)
The 3 set() commands tell the obi to do the following for the next outbound call:
1. Disable Jitter Buffer Adjustment, and use a fixed jitter buffer length of 200 ms
2. Disable Echo Canceller
3. Use only G711u codec

Change Codecs
G711U  PacketizationPeriod = 10

I think I'm going to need a beer later   8)

Indeed two beers, if not a barrel :)  Can you do that for inbound as well?

(Thanks very much for all your help)

Mike

ianobi

I think that the Star Code approach probably only works for the OBi2xx series. OBi1xx series is a definite no. I've just tried it using an OBi1032 and that does not work. However, with the OBi1032 it is possible to set the maximum jitter buffer length for each individual spX.

Ideas developed by azrobert and Mango seem to suggest that this format also works:
16042999000,Modem Call,set($Noji1,200),set($Noec1,1),set($Cdm1,3),call(16042999000)

In the relevant Star Code Profile / slot use the number to be dialled (16042999000 in this case) instead of an actual *99 type Star Code. I think that you would need to dial manually (not via a "send key") to allow the Star Code DigitMap(?) to pick up the number. That's needs some trials to prove and I don't have an OBI202 to try it out!

I don't know any way to influence jitter buffer length for incoming calls.

Mouse

Quote from: ianobi on July 24, 2015, 03:40:18 AM
I think that the Star Code approach probably only works for the OBi2xx series. OBi1xx series is a definite no. I've just tried it using an OBi1032 and that does not work. However, with the OBi1032 it is possible to set the maximum jitter buffer length for each individual spX.

Ideas developed by azrobert and Mango seem to suggest that this format also works:
16042999000,Modem Call,set($Noji1,200),set($Noec1,1),set($Cdm1,3),call(16042999000)

In the relevant Star Code Profile / slot use the number to be dialled (16042999000 in this case) instead of an actual *99 type Star Code. I think that you would need to dial manually (not via a "send key") to allow the Star Code DigitMap(?) to pick up the number. That's needs some trials to prove and I don't have an OBI202 to try it out!

I don't know any way to influence jitter buffer length for incoming calls.


Interesting indeed but unfortunately if it does not work on the 110 and does not work inbound from the LAN it probably won't allow the echo problem arising from linking the devices to be solved?

The main echo problem I have is on line 1, PSTN. As with many people I need inbound PSTN at reasonable quality and the Obiline 202, while better than an SPA 3102 is marginal. (Outbound can be all SIP except for emergencies). Still trying to decide if it is good enough. The 110 is better, but much more limited in other ways.

I have wondered if you can set any parameter in the Obiline (packet size, jitter buffer etc) as it must translate analog to digital in the Obline device, it must get those values from somewhere!!!!

Thank you very much indeed for all your kind help though.

Mike