Bookmark showing examples of X_InboundCallRoute & other interesting tips:
QBZappy:
Quote from: giqcass on February 10, 2014, 07:57:39 pm
After playing with something ianobi posted I realized that the Obi can allow us to make a skype account simultaneously ring on incoming calls. In my example we assume sp2 is set up for sip and sp1 is your inbound provider you want to simulring Skype.
Voice Services > SP1 Service > X_InboundCallRoute:
{ph,sp2(skypUserName@skype.jetnumbers.com)}
I can't say how reliable this trick will be. It needs more testing. So far so good. When I call my GV number all forwarding phones ring and my Skype account rings. If I don't pick up GV Voicemail kicks in.
Here is a little more by ianobi that may be useful in combination with this.
Quote from: ianobi on February 09, 2014, 03:39:12 am
It is possible to make this imitation call hunting a little more sophisticated. Consider an InboundCallRoute such as:
Voice Services > SP1 Service > X_InboundCallRoute:
{ph,sp2(12222222222;d=5),sp2(13333333333;d=15)}
A call coming in to sp1 will ring the phone connected to the OBi. Five seconds later the call will be forked to 12222222222. Fifteen seconds later the call will be forked to 13333333333. All three endpoints will now be ringing, the first to answer takes the call. If a second call comes in while the first call is in progress, then the two free endpoints will receive ringing (after any applicable delays) and either may take the second call.
To use the Oleg Method with this example:
Voice Services > SP1 Service > X_InboundCallRoute:
{>1234567:ph,sp2(12222222222;d=5),sp2(13333333333;d=15)}
Where 1234567 = Voice Services > SP1 Service > SIP Credentials > AuthUserName
QBZappy:
Quote from: ianobi on December 31, 2013, 03:39:18 am
It’s obvious from this thread and the one that you quoted originally that your manual is much needed!
Looks like we are making some progress. As you may know, a SIP call comes in two parts: Firstly, the SIP signalling which routes the call, sets it up , disconnects it etc. This we have now achieved. Secondly, the media part (our voices) which rely on Real Time Protocol (RTP) after SIP has set the call up. This seems to be our problem now. There are two ways to improve RTP connection:
1. Ensure that the correct ports are forwarded in your router. The Obihai FAQ section is out of date on this issue. As you are using sp3 as a “carrier” for Voice Gateway 3, in your router you need to forward the range of RTP ports defined here:
Service Providers > ITSP Profile C > RTP > LocalPortMin
to
Service Providers > ITSP Profile C > RTP > LocalPortMax
The protocol defined in your router need only be UDP.
Also if your router has a SIP ALG (Application Layer Gateway) function, then turn it off.
2. Use a STUN server. You can use any public STUN server, I use ideasip as it seems reliable. Set up as follows:
Service Providers > ITSP Profile C > General > STUNServer: stun.ideasip.com
Service Providers > ITSP Profile C > General > STUNServerPort: 3478 (default)
No need to check STUNEnable. I know this sounds strange, but it is not needed and may confuse later providers using sp3 or other voice gateways that use sp3.
One more change:
Voice Services -> Gateways and Trunk Groups -> Voice Gateway3
Name : Voxbeam
AccessNumber : sp3(sbc.voxbeam.com;op=s)
DigitMap : (ppppppp(91xxxxxxxxxx|xx.S4)|<ppppppp>(91xxxxxxxxxx|xx.S4))
AuthUserID : +1xxxxxxxxxx
When the AccessNumber is used op=s tells sp3 (which you are using as a carrier for Voice Gateway 3) to use the STUN server set up on sp3 (ITSP Profile C).
If you do write the manual, then remember that the DigitMap will depend on what numbers the user wants to use Voxbeam to dial. Good luck!
QBZappy:
Quote from: ianobi on December 23, 2013, 04:16:47 am
1. This seems odd. When you pick up the phone it's the OBi110 dial tone that you hear. Even if you make PSTN your Primary Line, you will not hear PSTN dial tone by simply picking up the phone. Can you try a different phone? A simple corded phone would be best for testing.
2. A second dial tone can be provided in the Phone Port DigitMap. There is a choice of three dial tones:
di = Dial Tone
di2 = Second Dial Tone
od = Outside Dial Tone
If we use second dial tone the format is like this:
Physical Interfaces > PHONE Port > DigitMap:
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|**1{t=di2}(Msp1)|**2{t=di2}(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))
User picks up phone gets dial tone, then dials **1 and gets the second dial tone. Second dial tone disappears when any further digit is dialled.
QBZappy:
Quote from: ianobi on February 09, 2014, 03:39:12 am
It is possible to make this imitation call hunting a little more sophisticated. Consider an InboundCallRoute such as:
Voice Services > SP1 Service > X_InboundCallRoute:
{ph,sp2(12222222222;d=5),sp2(13333333333;d=15)}
A call coming in to sp1 will ring the phone connected to the OBi. Five seconds later the call will be forked to 12222222222. Fifteen seconds later the call will be forked to 13333333333. All three endpoints will now be ringing, the first to answer takes the call. If a second call comes in while the first call is in progress, then the two free endpoints will receive ringing (after any applicable delays) and either may take the second call.
To use the Oleg Method with this example:
Voice Services > SP1 Service > X_InboundCallRoute:
{>1234567:ph,sp2(12222222222;d=5),sp2(13333333333;d=15)}
Where 1234567 = Voice Services > SP1 Service > SIP Credentials > AuthUserName
QBZappy:
Re: Trouble with Credit Card terminal but faxing works great
http://www.obitalk.com/forum/index.php?topic=6625.msg41922#msg41922
Quote from: obiliving on September 13, 2013, 03:58:08 pm
Modem is sensitive to jitter buffer adjustments during a call. Your OBi can detect FAX tone and will switch off jitter buffer adjustment when FAX is detected (it might even switch to T.38/FAX Relay if the call peer also supports it). That makes your FAX work better.
However there is no Modem signal detection support.
There is a new feature in the latest firmware (3.0.1.4109) that may help (do a f/w upgrade first).
It allows you to disable jitter buffer adjustment for the next outgoing call, by dialing a *code (of your choice). This is what you can do: Add a Star Code (under Star Code Profile) like this:
*01, Modem Call, set($Noji1,200),set($Noec1,1),set($Cdm1,3)
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 and G711a codec
Replace *01 with any code you like, as long as it does not conflict with other codes.
Then dial the target number and see if the modem call works better.
Note that this only controls the OBi; the quality will still be affected by the behavior of the call peer and any network impairment. Good luck.
Tag: How to control Jitter Buffer Adjustment
Navigation
[0] Message Index
[#] Next page
[*] Previous page