Hi.

I am wondering how I can remove the following headers from the SIP OK messages FreeSWITCH sends in response to INVITE messages it receives from a SIP gateway:
Session-Expires: 300;refresher=uac
Min-SE: 120
Yes, I have read http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options and it reads like you're supposed to add relevant configuration lines to the profile of the gateway under conf/sip_profiles/external/. I added the following two lines:
  <param name="enable-timer" value="false"/>
  <param name="minimum-session-expires" value="3000"/>
... but I do not see any changes to the header lines. I must be missing something, please do let me know. If there I am using November 6 weekly git build, Windows version.

At this point, I just need to remove those header lines. I will explain why below, in case you'd like to know.

I subscribe to a SIP-based VoIP service. They supply you with a hardware SIP gateway/proxy/ATA. I have FS register with it as a SIP client. When a call comes in, the gateway sends an INVITE to FS, which responds with an OK. What's odd is that the gateway immediately terminates the call with a BYE right after it sends an ACK, with no explicit reason (in case you're curious, here's a log: http://pastebin.freeswitch.org/14479). I have thought about many possible reasons, but my current theory is that the gateway passes the OK to its superior, which somehow does not like what it sees and immediately decides to end the call.

We all know their service is built around SIP, but it is never an advertised feature. Officially, you're only supposed to plug in analog phones, or use a small number of particular hardware IP phones and a softphone they created. Officially they do not support anything else, although they do not prohibit the use of other SIP-compliant software or devices either. So they have no obligation to adhere to the SIP standard rigidly. I think that's why they do not give you a helpful message.

I want FS to work as IVR or AA. And my setup works perfectly with incoming calls through Gizmo. So now I am guessing the reason why it does not work with the other VoIP service provider is something specific to their service. A similar setup with AsteriskWin32 works fine even with this provider, so now I am trying to eliminate differences in the messages FS sends.

I hope I explained myself well. Thanks for your help!

Yasuro


Yasuro wrote (11/15/2010 4:09 PM):
Peter and David, thanks for trying to help out.

I did wonder about that too, Peter, but it seems to me that my VoIP adapter at 192.168.11.250 sends out an RTCP receiver report right before it ends a call. This is shown in the trace of packet exchange between AsteriskWin32 and the VoIP adapter. In case you did not see my original posting, AsteriskWin32 does do what I want to achieve, i.e., automatically answers incoming calls to my DID number.

I have FreeSWITCH at 192.168.11.11 register with the VoIP adapter, which is a SIP gateway provided by my SIP service provider. When I call FS's extension number from another softphone, also on the home LAN, which is also registered with the same VoIP adapter, FS answers automatically as I expect it to. The RTP steam is established between FS and the softphone directly. This part is different from incoming calls' case, where the VoIP adapter seems to act as a proxy and tries to establish an RTP stream between itself and FS.

The VoIP adapter sends an ACK back to FS when FS accepts an INVITE with an OK. I'd think everything is hunky dory up to that point. What I do not get is why the VoIP adapter decides to end the call immediately after (and sends an RTCP receiver report). I am guessing it is because there is something wrong with the RTP communication that is supposed to follow.

I am thinking it is either because: A. the VoIP adapter somehow couldn't send RTP packets, or B. the VoIP adapter didn't like the RTP packets that it received from FS. I don't think A. is the case. The firewall of the PC on which FS runs was turned off during testing and the VoIP adapter has no problem sending RTP packets to AsteriskWin32 on the same PC (I did not run FS and Asterisk simultaneously). Since I could not find anything particularly odd about RTP packets sent by FS, I have no idea if B. is a possibility.

By the way, my home LAN is set up in a weird way (please see http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup-1.jpg). Double NAT layers are understandably a concern, but since both the VoIP adapter and FS (and the softphone too) are accessible on the inner layer of NAT, this should not be a problem... I would think (Correct me if I am wrong). I do not need to and thus am not trying to access FS from the Internet.

I would welcome any input. Thanks again for your help!

Yasuro



Peter Steinbach wrote (11/15/2010 9:01 AM): 
Thanks David,

missed the "C".

But anyway, I am wondering why .250 sends a BYE right after reception of
"Destination unreachable (Port unreachable)".