Using OBi Voice Gateways with SIP Providers
oleg:
**N is not the only dialing prefix. I used to have #N (e.g. '#2' rather than '**2') - it worked with Linksys adapters and works with OBi. Phone Port DigitMap and OutboundCallRoute have to be changed accordingly (just replace '**' with '#').
Someone may find it more convenient...
RonR:
Quote from: oleg on March 29, 2011, 04:51:27 pm
**N is not the only dialing prefix. I used to have #N (e.g. '#2' rather than '**2') - it worked with Linksys adapters and works with OBi. Phone Port DigitMap and OutboundCallRoute have to be changed accordingly (just replace '**' with '#').
Someone may find it more convenient...
Of course. That's one of the nice things about the PHONE Port DigitMap/OutboundCallRoute processing scheme - you can throw the current one's out the window and make up a totally new dialing syntax if you wish.
RonR:
Quote from: murzik on March 29, 2011, 04:48:44 pm
Can you actually place a call through sipbroker or voxalot gateways?
If you mean a free call to a PSTN phone, the answer is no. You can, however, place free calls to others whose service provider peers with Sip Broker.
murzik:
Quote from: RonR on March 29, 2011, 07:26:06 pm
Quote from: murzik on March 29, 2011, 04:48:44 pm
Can you actually place a call through sipbroker or voxalot gateways?
If you mean a free call to a PSTN phone, the answer is no. You can, however, place free calls to others whose service provider peers with Sip Broker.
What I meant if sipborker and voxalot are work for you, because what I get is just one way audio.
Especially calling any peers through sipbroker.
oleg:
I believe the reason is that OBi110 build 2101 does NOT use STUN for outgoing SIP calls via alternative providers (only use STUN for the provider configured in corresponding SPx service). In other words OBi110 sends your local IP:port in RTP stream information.
For most of us OBi adapter is located on local network behind NAT. Some destinations are smart enough to recognize local IP sent by OBi, disregard it and try to send RTP just in opposite direction (to the same IP/port where your voice stream comes from). Often this works, sometimes not...
Build 1892 used STUN in the same situation. I've suggested developers to re-think STUN usage decision, waiting for response...
P.S. Please let me know if someone needs more details / explanations.
Navigation
[0] Message Index
[#] Next page
[*] Previous page