Obi110 won't disconnect calls when people hang up.

[str8jkt]

I am using freephoneline (fongo) with an Obi110.  It looked like it was working ok.  I was able to call out and receive a call.  But it looks like when the other party hangs up (tested on a land line, blackberry and iphone), the call will not disconnect properly.  If I log into the OBiHai web interface for the device the line shows connected until I manually terminate that session.

Any idea what I can tweak to get this fixed?  Thanks in advance.

[hwittenb]

How did you interface the OBi110 to freephoneline?  Did you setup the OBi110 SP1 or the SP2 sip interface for freephoneline?

[str8jkt]

SP1 is setup for freephoneline.  I don't have anything setup on SP2.  Thanks for the response hwittenb.

[hwittenb]

str8jkt,

The connection you describe is strictly over the voip line thru the freephoneline server.  When the distant phone hangs up the freephoneline server gets a signal from their connection to the distant phone and they then send a Sip BYE signal to the OBi110.  The OBi110 would hang up your leg when they receive the BYE.  I don't know of anything to tweak that concerns normal signalling.  My guess is it is some sort of network or NAT failure where the BYE packet isn't received by the OBi110.

For troubleshooting I would check the call history on your freephoneline account and see if that looks normal, I would check the call history on the OBi110 web page which is found under Status-->Call History.

To make sure the sip signalling is communicating your correct external ip address and port number in the call I would setup a STUN server and see if that makes any difference.  On the ITSP Profile A (if that pertains to SP2):
STUN Enable (check) Default (uncheck)
STUNServer stun.callwithus.com Default (uncheck) (or any other STUN server)
on the SP2 Sip Tab
X_KeepAliveEnable: (check) Default (uncheck)

I'm not sure what else to try.  Of course the problem could lie with freephoneline's provider not signalling to them that the distant party hung up but that seems remote.

Reviewing the OBi Admin Guide about NAT Transversal it says:

NAT Traversal Considerations
If the device sits behind a NAT (typically the case), it can discover the mapped external address corresponding to its local SIP contact address as seen by the server in one of the following ways:
- From the "received=" and "rport=" parameters of the VIA header of the REGISTER response sent by the server; these two parameters tells the device its mapped IP address and port number respectively. This method is used if periodic registration is enabled on the device
- From the response to a STUN binding request the device sent to a STUN server. This method is used by enabling X_KeepAliveEnable and setting the X_KeepAliveMsgType parameter to "stun". In that case, the STUN server is taken from the X_KeepAliveServer parameter, if it is specified. Otherwise, the keep-alive messages are sent to the same server where a REGISTER request would be sent to. The latter is the most effective way of using STUN to discover the mapped external contact address