I think tony put up a fix for this can you try latest trunk /b On May 29, 2007, at 10:12 AM, Mike Murdock wrote:
I am dealing with the same problem... Brian, there is something wrong here. The effect is my calls get terminated every two minutes +hen my sipura re-registers. I have a trace with full debug captured if you want to see.
Michael Murdock VP Operations & Development Switchmaxx Product Line 125 N. Market. Suite 1520 Wichita KS. 67202 (316) 932-2693
-----Original Message----- From: Brian West [mailto:brian.west@mac.com] Sent: Tuesday, May 29, 2007 10:14 AM Eastern Standard Time To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] SIP Timeout waiting for 200 ACK
I think that since we are a B2BUA tech_pvt->profile->url is the right way. The other way is correct if you're a proxy. Remember FreeSWITCH NOT a proxy.
/b
On May 29, 2007, at 8:58 AM, freeswitch@dalethatcher.com wrote:
I'm seeing an issue during a bridge where the '200' from freeswitch is not being ACK'd and Freeswitch is correctly dropping the connection. However I belive that the Contact header in the 200 packet is causing the problem. Am I missing a config parameter?
If I back out the revision 5208 change to mod_sofia.c from the trunk source then the problem goes away. (SIPTAG_CONTACT_STR(tech_pvt-
to_uri) back to SIPTAG_CONTACT_STR(tech_pvt->profile->url)).
My test setup is (Freeswitch is behind a NAT):
External SIP -> Freeswitch -> Gizmo
The freeswitch config for the extension is:
<extension name="test"> <condition field="destination_number" expression="^test$"> <action application="bridge" data="sofia/gizmo/ 17470355893@proxy01.sipphone.com"/> </condition> </extension>
I've put a full copy of the log here:
http://pastebin.freeswitch.org/3008
My internet facing profile is:
<profile name="internet"> <settings> <param name="debug" value="1"/> <param name="rfc2833-pt" value="101"/> <param name="sip-port" value="5060"/> <param name="dialplan" value="XML"/> <param name="dtmf-duration" value="100"/> <param name="codec-prefs" value="$${global_codec_prefs}"/> <param name="codec-ms" value="20"/> <param name="use-rtp-timer" value="true"/> <param name="rtp-timer-name" value="soft"/> <param name="rtp-ip" value="$${bind_server_ip}"/> <param name="sip-ip" value="$${bind_server_ip}"/> <param name="accept-blind-reg" value="true"/> <param name="nonce-ttl" value="60"/> <param name="ext-rtp-ip" value="80.189.98.58"/> <param name="ext-sip-ip" value="80.189.98.58"/> <param name="sip-domain" value="sip.dalethatcher.com"/> </settings> </profile>
With the current trunk the SIP packet that does not get a response is:
send 1182 bytes to udp/[193.111.201.32]:5060 at 13:05:15.136189:
----------------------------------------------------------------------
-- SIP/2.0 200 OK Via: SIP/2.0/UDP 193.111.201.32;branch=z9hG4bK614f.db2cc426.0 Via: SIP/2.0/UDP 193.111.200.182;branch=z9hG4bK614f.9dbef354.0 Via: SIP/2.0/UDP 194.145.189.10:3670;branch=z9hG4bK00E0F556495005A857E00000230F Record-Route: <sip: 193.111.201.32;lr=on;ftag=00E0F556495005A857E00000222A> Record-Route: <sip: 193.111.200.182;lr=on;ftag=00E0F556495005A857E00000222A> From: <sip: 02085555129@194.145.189.10>;tag=00E0F556495005A857E00000222A To: <sip:442070968842@193.111.200.182>;tag=r5ae93vm8aK1p Call-ID: 00E0F556495005A857E000001549@194.145.189.10 CSeq: 35816 INVITE Contact: <sip:442070968842@193.111.200.182:5060> User-Agent: FreeSWITCH(mod_sofia) Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, precondition Content-Type: application/sdp Content-Disposition: session Content-Length: 290
v=0 o=FreeSWITCH 6489556414011969222 9057524047013517960 IN IP4 192.168.93.5 s=FreeSWITCH c=IN IP4 80.189.98.58 t=0 0 a=sendrecv m=audio 10002 RTP/AVP 0 96 13 a=rtpmap:0 PCMU/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=rtpmap:13 CN/8000 a=ptime:20 m=image 0 UDPTL 9
----------------------------------------------------------------------
--
Backing out the change modifies the Contact header to:
Contact: <sip:mod_sofia@80.189.98.58:5060>
Which gets an ACK packet and doesn't drop the call.
thanks,
- Dale
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/ freeswitch-dev http://www.freeswitch.org
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org