Configuring SIP clients (softphones) for singlestage dialing through my OBi100

[Atrocia]

Hi,

I am comfortable with computers (Linux), but a telephony noob. I have my OBi100 set up with GV (SP1), and I'm trying to setup singlestage dialing (via RonR's method). I'm not sure if I've gotten everything right (some of those substitutions RonR mentions are a bit confusing, and in any event, I can't get any of my Linux SIP clients to dial out through the OBi. Most seem to need a connection to a SIP server, only some of them seem to have entries for a SIP proxy, and in most of them I can't figure out exactly how to set a userid.

With some configurations in some clients, I seem to be somehow connecting to the OBi - the phone connected to it rings. I checked the OBi call history, and those calls appear thus:

Code Select Expand

Terminal ID SP2 PHONE1
Peer Name John Doe
Peer Number john
Direction Inbound Inbound
22:14:58 Ringing
22:15:01 End Call

Can anyone provide a basic tutorial for configuring a software SIP client (on Debian stable I've tried twinkle, sflphone, empathy, ekiga, and linphone, with no luck)?

[azrobert]

You are almost there with the softphone you used that got the results you posted.

RonR is making the config more complicated than it needs to be.

Remove all the changes you made except for the following:

Service Providers -> ITSP Profile B -> SIP -> ProxyServer : 127.0.0.1
Voice Services -> SP2 Service -> AuthUserName : (any userid)
Voice Services -> SP2 Service -> X_RegisterEnable : (unchecked)
Voice Services -> SP2 Service -> X_ServProvProfile : B

Replace your ITSP B X_InboundCallRoute with following:
{(john)>(1?xxxxxxxxxx|<480>xxxxxxx):sp1},{ph}

The above rule is checking the incoming call for a peer number = "john" AND a dialed number with 10 digits with or without a prefix of "1" or a 7 digit dialed number. if there is a match it routes the call out SP1. If it's a 7 digit number it will prefix it with "480" (your local area code).

If there is no match it will ring your OBI100 Phone port.

[Atrocia]

Thanks much - it's working perfectly now, with twinkle! This really needs to go into a FAQ somewhere.

And just FTR, for clarity in case anyone stumbles across this thread, the reference to

Replace your ITSP B X_InboundCallRoute

is to

Voice Services -> SP2 -> X_InboundCallRoute

[Atrocia]

I'm still pretty frustrated trying to get SIP clients to dial out through the OBi; here are my results so far ('userid' below is as set on the OBi, 'obi' is the hostname [or IP] of the OBi):

• 
  Twinkle - works with the following settings:
  
  

  
  Edit -> User Profile -> User -> User name: userid
  Edit -> User Profile -> SIP Server -> Registrar: [blank]
  Edit -> User Profile -> SIP Server -> Outbound Proxy -> Use outbound proxy: [checked]
  Edit -> User Profile -> SIP Server -> Outbound Proxy -> Outbound proxy: obi:5061
  

  
  


• Kphone - connects with the following settings, but no sound in either direction:
  
  

  
  File -> Identity -> User Part of SIP URL: userid
  File -> Identity -> Host Part of SIP URL: obi
  File -> Identity -> Outbound Proxy (optional): obi:5061
  File -> Auto Register: [unchecked]
  

  
  

• 
  sflphone, linphone, yate-qt, empathy / telepathy-sofiasip, ekiga - could not get to connect
  

[Why is the Linux SIP client situation so bad - all the clients are poorly documented, untouched for years, and / or don't work very well (at least without proper documentation ...).]

[azrobert]

I have Yate-qt working on Windows connected directly to GV with these parms:

Provider: none
UserName: GV_ID
Password: GV_PW
Domain: gmail.com
Server: talk.google.com
Resource: Yate
Allow plain password: Checked

[azrobert]

Most softphones on any platform require registration and therefore will not work with an OBi.
I posted the following as a solution for an IPhone, but will work with any softphone requiring registration:

http://www.obitalk.com/forum/index.php?topic=5411.0

I would not recommend this for you since you have a softphone working and the path for the above is out to a server and then back to the OBi. Try it if you just want to play.

[Atrocia]

I have Yate-qt working on Windows connected directly to GV with these parms:

Provider: none
UserName: GV_ID
Password: GV_PW
Domain: gmail.com
Server: talk.google.com
Resource: Yate
Allow plain password: Checked

Thanks - may try this, but I'd really like to go through the OBi ...

[Atrocia]

Most softphones on any platform require registration and therefore will not work with an OBi.
I posted the following as a solution for an IPhone, but will work with any softphone requiring registration:

http://www.obitalk.com/forum/index.php?topic=5411.0

I would not recommend this for you since you have a softphone working and the path for the above is out to a server and then back to the OBi. Try it if you just want to play.

Thanks. Once again, why is the (linux?) SIP situation so bad? I know, if I want this, I should code it myself, but is my use case really so unusual? Why can't the linux clients do this?

I may check out your suggestions (particularly the second one you post - http://www.obitalk.com/forum/index.php?topic=6145.0 - when I have a chance - thanks for figuring it out and posting.

[hwittenb]

Thanks. Once again, why is the (linux?) SIP situation so bad?

I'm not sure it is anything special with the Linux sip clients.  You can encounter problems with any sip client.  I recently setup my Android phone (using CSipSimple) to communicate using single stage dialing thru my OBi110.  I have also setup a softphone on my local pc (XLite) which can communicate in a similiar manner but there is a difference in how you setup SPx to communicate with these two clients.

The problems you encounter in configuring for sip clients, such as softphones, android phones, etc., dialing thru an OBi using direct ip calling mostly relate to ip addresses and port numbers carried in the sip signalling packets between the sip client and the OBi.  The problem often is the OBi is using its local network address when it should be using its external ip address or vice versa.  Problems often occur with the addresses for the exchange of the rtp sound packets, although it could also be with the sip signalling exchange itself.  The necessary addresses used can be either external or local network and the OBi seems to use external or local network addresses depending on how SPx is configured.  Troubleshooting is easier if you can use a packet sniffing program such as Wireshark where you can examine the packet exchange of the OBi.

With the OBi there is a difference in packet formation depending on whether the SPx you are using is registered or not registered.

Of course you first need to find a sip client that allows you to configure the client to make calls without registration.  Azrobert has an excellent posting on how to configure the Android client, CSipSimple, to operate without registration (http://www.obitalk.com/forum/index.php?topic=4647.msg33746#msg33746).  Without his posting it is not obvious how you do that. 

The current version of XLite has a straight forward setting to Register or not Register.  I don't believe they have a Linux version, though. 

Generally you setup the sip client's proxy with the OBi's ip address (either external or local network as the case may be) including the SPx sip port number (unless the port number is the default 5060).  The UserID you setup on the client will be the caller id of the incoming call to the OBi.  Of course the SPx on the OBi you are calling needs to be configured for sip.  If your sip client is external to the OBi's local network (external ip address) then the OBi's SPx generally needs to be registered to somebody's external server.  If your sip client is on the local network then the OBi's SPx should not be registered.

If the sip client is external and is itself behind a local network router with a local network address of it's own, the client should be configured to use it's external ip address.  This is often done configuring the client to use a STUN server.

For the single stage dialing on SPx you setup the SPx's X_InboundCallRoute with an element like this:
{(hwittenb)<(xxxxxxxxxx):sp1},
where hwittenb is the UserID you setup on your sip client and sp1 is the outgoing SPx configuration you want to use for the bridged outgoing call.

[QBZappy]

Atrocia,

Hi. After reading this thread, I couldn't help thinking how the OBi webRTC avoids all the above mentioned issues. This seems the like the perfect use case to convince users of the usefulness of the new webRTC technology. It seems that everyone replying here is still using "old school" methods to make a call using the OBi as the gateway. I imagine that Google Chrome with webRTC is or will be available on the linux platform. That should be a working solution.