<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi.<br>
<br>
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:<br>
<blockquote>Session-Expires: 300;refresher=uac<br>
Min-SE: 120<br>
</blockquote>
Yes, I have read
<a class="moz-txt-link-freetext" href="http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options">http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options</a>
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:<br>
<blockquote> <param name="enable-timer" value="false"/><br>
<param name="minimum-session-expires" value="3000"/> <br>
</blockquote>
... 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.<br>
<br>
At this point, I just need to remove those header lines. I will
explain why below, in case you'd like to know.<br>
<br>
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:
<a class="moz-txt-link-freetext" href="http://pastebin.freeswitch.org/14479">http://pastebin.freeswitch.org/14479</a>). 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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
I hope I explained myself well. Thanks for your help!<br>
<br>
Yasuro<br>
<br>
<br>
Yasuro wrote (11/15/2010 4:09 PM):
<blockquote cite="mid:4CE0DCAE.7010903@yasuro.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Peter and David, thanks for trying to help out.<br>
<br>
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 <a
moz-do-not-send="true"
href="http://pastebin.freeswitch.org/14457">the trace of packet
exchange between AsteriskWin32 and the VoIP adapter</a>. 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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
By the way, my home LAN is set up in a weird way (please see <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup-1.jpg">http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup-1.jpg</a>).
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.<br>
<br>
I would welcome any input. Thanks again for your help!<br>
<br>
Yasuro<br>
<br>
<br>
<br>
Peter Steinbach wrote (11/15/2010 9:01 AM):
<blockquote cite="mid:4CE07843.8040209@telefaks.de" type="cite">
<pre wrap="">Thanks David,
missed the "C".
But anyway, I am wondering why .250 sends a BYE right after reception of
"Destination unreachable (Port unreachable)".
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>