April 2008 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Freeswitch win32 error (Procedure entry point inet_pton could not be located in the dynamic link library WS2_32.dll)
by B Karthik 14 Apr '08

14 Apr '08

Hi, Over the days, my interest in FreeSwitch is overwhelmingly increasing. I love this software. I am sure that one day i will be competent enough to contribute to this project. I get this error when i compile and run freeswitch using visual studio 2008 express edition. (Procedure entry point inet_pton could not be located in the dynamiclink library WS2_32.dll) This is happening in svn revision 8099. Any help will be deeply appreciated. Thanks in advance. Warm Regards, B Karthik

4 3

Re: [Freeswitch-users] [Freeswitch-dev] bad REGISTER processing
by Anthony Minessale 14 Apr '08

14 Apr '08

The main reason we write the port in that case is because the idea of that nat hack is to make the contact be the exact ip/port the register came from. Because of NAT it's some random port so putting the port in the contact is the only way we can get the packet back to the phone from our scope of the SIP stack. Any more advanced techniques need to be applied by a router such as openser or from the sofia stack itself. You can visit them in #sofia-sip on the same irc server as ours. First of all I would like to complement us on our ability to keep up with you. Just as a hint, you are starting to abuse our help by asking for an average of 3 incidents a day this week. Do people you pay money even help you that much? Let me give you a few pointers on how to get along with us. You may or may not have done all of these things but I am listing them for your information. I am not telling you to stop bringing up issues but be careful about dominating our time. You may want to also use http://jira.freeswitch.org as a more formal way to track your problems. 1) Please do not take the extra time to provide any justification to why you think we *should* do something just to help your case. Feel free to ask but do not use what someone else does as an excuse. If everyone in Europe was jumping off a cliff, should we too? This includes used car salesman techniques like using statements like "I have this simple app and it doesn't work how I want. If this were a real soft-switch it would do this....." 2) Do not use RFC as a bible. When someone wants something they tend to stand up on a soapbox and wave it in the air. Meanwhile when something else inconvenient happens like NAT where breaking the RFC usually fixes it, then it's ok. We all know we should try to work as close to the RFC as possible. We also all know it's impossible to actually work right at 100% RFC compliance unless you live on a commune full of SIP purists. So avoid quoting the RFC to prove your point. Save it for rare occasions. The Sofia SIP stack does a lot of work to comply and they do a good job you should thank them. 3) Keep it in mind that FreeSWITCH is developed primarily by me and I only have so many hours in a day. I am more than happy to answer questions and help people but be sure to give others a turn too. Try asking more questions on the users list or the irc channel to give others a chance to help too. 4) When you feel yourself crossing the line from testing the waters to going in production, consider getting a support contract or the visiting the donation and/or wishlists so you can give back to the project and put smiles on underprivileged developer's faces for pennies a day. On Fri, Apr 11, 2008 at 2:22 AM, kokoska rokoska <kokoska.rokoska(a)post.cz> wrote: > > Just for completion of my previous e-mail: > > May be I miss something significant and all my thesis are completly > wrong. If yes, I apologize and ask you for correction of my thoughts :-) > Thank you. > > Best regards, > > kokoska.rokoska > > > kokoska rokoska napsal(a): > > Thank you very much, Michael, for your answer! > > > > My comments are included in the e-mail body: > > > > Michael Jerris napsal(a): > >> The NDLB-connectile-dysfunction is a paramater to explicitly break the > >> rfc > > > > My be, but only internaly - i.e. all your public communication could be > > RFC compliant if you want. > > > >> and re-write our behavior as if we got a contact of the same > >> address that we received the packet from. > > > > Yes, in the same manner as all VoIP TSP (at least all bigger VoIP TSP in > > Europe) do :-) > > > >> If it comes from 5060, it > >> will have 5060 in the contact. > > > > And this brakes the RFC and UAC should refuse your 200 OK. There are a > > lot of broken clients which accepts this but not all of them :-) > > > >> If you would like to handle nat and > >> still be rfc compliant, then you need to use a client that follows the > >> rfc's > > > > I'm sorry but I don't know what is RFC noncomplient if UAC behind NAT > > sends private IP in contact. Could you point me to relevant part of some > > RFC, please? It will be very helpful for me... > > > > > >> so you don't have to use non compliant hacks. > >> > > > > Like I wrote before, I can't remember any real (and not marginal) VoIP > > telco provider in Europe which doesn't internaly rewrite contact URI in > > case of UAC behind NAT. Even thou, a lot of them rewrite EVERY contact > > URI and don't try to detect NAT, because a lot of SOHO routers have > > SIP-ALG support (god dammed) which makes thing even complicated. > > > > But there is - IMO - no reason why to rewrite contact URI in 200 OK > > response to REGISTER request. > > > > ---------------- > > > > All at all, from my point of view there is a big drawback if I couldn't > > use FreeSWITCH for UACs behind NAT. > > It forces me to use OpenSER as registrar (what I want to avid to because > > of performance and harder setup to keep good interoperability) which has > > no problem with clients behind NAT. > > > > I believe that improvement in NAT handling could help FreeSWITCH users a > > lot. Thus I will be glad to help you as much as I can do. > > Please let me know if I can do something handy (other than rewrite FS by > > myself :-). > > > > Thanks once more, Michael, for your answer! > > > > Best regards, > > > > kokoska.rokoska > > > > > > _______________________________________________ > > Freeswitch-dev mailing list > > Freeswitch-dev(a)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(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale(a)hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale(a)gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888(a)conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888(a)conference.freeswitch.org> pstn:213-799-1400

3 9

Problem playing media
by Nicolas Brenner 13 Apr '08

13 Apr '08

On Wed, Apr 9, 2008 at 7:36 AM, Brian West <brian(a)freeswitch.org> wrote: > > On Apr 9, 2008, at 1:17 AM, Nicolas Brenner wrote: > > > Hello everyone, > > > > I'm having some trouble with FS :( apparently with mod_shout. I want > > to play an mp3 file after answering a call so I compiled mod_shout > > following the wiki, then configured an extension to answer a call and > > play an mp3 file I uploaded to the server. The thing is, FS supposedly > > plays the file, but I can't hear it on the softphone with which I'm > > calling, and also, after playing the file, FS seems to freeze and then > > I get a lot of: > > > > sofia_event_callback() event [nua_r_bye] status [408][Request Timeout] > > session: n/a > > sofia_event_callback() event [nua_i_state] status [408][to BYE] > > session: n/a > > > > lines on the console/log. > > Well I can't see enough of the log with the two lines you posted to > many any kinda of educated guess. > Ok, attached is a console log with sip traces as well. What I did was: - start freeswitch - register softphone (xlite) with extension 1000 - call 9998: FS answered the call and played the tetris sound, although I was only able to hear it for 3 secs - hanged up: FS received the hang_up and terminated the call - call 9998 again: FS answered the call and supposedly played the tetris sound, but I didn't hear anything on my side - hanged up: FS did not recieve the hang_up signal, and kept the call 'open' - tried calling 9998 again: FS didn't show any sip packets being received or anything, the call could not be made - shutdown FS > > > Also, after I try to call once, the softphone does not work anymore, > > and I have to make it register again with FS. After all this, when I > > shutdown FS, it takes some time, and while it's trying to shutdown it > > prints a lot of the same lines as above. > > I can only guess you're using x-lite or eyebeam. > Yes, I'm using x-lite > > > I thought it was mod_shout, so I commented it from > > autoload_configs/modules.conf.xml so it does not load, and replaced > > the mp3 file with a wav file (FS has permission to read both of them), > > but I'm getting the same behaviour. Now I'm even getting that > > behaviour when dialing 9999 or 9998 (default dialplan pre-configured > > extensions). > > Is this a real server or virtual server? ie vmware or xen? > This is a virtual server I think, made with virtuozzo. Is a dedicated virtual server hosted by mediatemple (www.mediatemple.net) > > > Now I can't get FS to work right, everytime I try to make a call, > > either initiating it from the console, the softphone or js, I get the > > same weird behaviour. Any clues? > > I'm sorry if this is trivial or a known issue, but I haven't been able > > to figure it out, thanks a lot for your time and help. > > Your best bet at this point is to join the IRC channel and ask for > help in realtime... Have you tried "make current" to ensure you don't > have any code skew? > I tried make current several times. For the tests above (for which the attachment log file is), I removed /usr/local/freeswwitch, then checked out FS source from svn and compiled with default options (did not add mod_shout), and used default config files with no modifications (also installed audio and music files). Additionally, the server has a public IP address, and I'm connected directly to Internet (not nat involved whatsoever). > > -- > > Nicolás Brenner > > > > _______________________________________________ > > Freeswitch-users mailing list > > Freeswitch-users(a)lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > Brian West > sip:brian@freeswitch.org > > > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > The files attached are: - consolelog.txt: What I saw on the FS console while doing the test - siptrace.log: Output of sip trace to a file using TPORT_DUMP env var - freeswitch.log: log/freeswitch.log on FS folder for this test My email was rejected by the list moderator, the files are here (user/pass: freeswitch/mailing): - http://www.medularis.com/fs/freeswitch.log - http://www.medularis.com/fs/consolelog.txt - http://www.medularis.com/fs/siptrace.log Thanks for your help! -- Nicolás Brenner

2 2

TBCT Followup
by Michael Collins 12 Apr '08

12 Apr '08

FYI, I spoke with my primary carrier - TWTC - and they report that there are no additional costs for setting up TBCT functionality. However, they require a provisioning request (aka paperwork) so I can't set it up right away. I'll probably get it set up in the next few months so that I can play with it using my NEC 2400 or possibly my IAT dialer... When I go to sign the paperwork that's when I'll get all the nitty-gritty details like how many concurrent calls, etc. I'll report back to the lists when I have that info. -MC

1 0

woomera
by Josip Djuricic 12 Apr '08

12 Apr '08

Hi there, I know mod_woomera is deprecated, but is there any way to make it work with current stable release of fs? I would need it for simplest task, nothing too fancy... just to be sure incoming and outgoing calls work stable... I'm currently using yate as a sip-to-h323 converter, because my as5300 has some problems talking with freeswitch (when we are making incoming calls), and now I have incoming fax problems as mentioned yesterday. It's definetely not FS issue, now I just ain't sure anymore if it's a yate or as5300 issue, will try direct h323 to patton interconnect to see it more closely. Best regards, Josip

2 1

Lucent Max TNT
by Brandon Shiers 12 Apr '08

12 Apr '08

2 1

IuUP support question
by Anya 11 Apr '08

11 Apr '08

Hi all, can someone tell me if this project supports IuUP interface? I am mainly interested in support for Iu-CS. I am looking for a small MSC that supports A and IuUP interfaces for 2g & 3g networks respectively. thank you, Anna

2 4

Dingaling In Component Mode "How To Call Jingle To SIP"
by Ali Jawad 11 Apr '08

11 Apr '08

Dear All First I would like to state that dingaling is working in client mode with gtalk perfectly. I can call from gtalk to my sip extension "1000". I have setup component mode now I am using FS with Openfire, open does show the following: 1 fs.jabber2.mydomain.net LibDingaLing gateway However stats on the jabber server are Session Statistics: Packets Received/Sent: 1/1 So the component is REGISTERED, so far so good my problem now is how to initiate a call from XMPP to a SIP extension. Using client mode I would do the following: 1. Setup GTALK account and assign extension to it 2. Login with another gtalk account and dial the first gtalk account 3. The assigned extension rings I don't know how to do the same using component mode. Adding sip+1000@mydomain to the jabber client "Jabbin" does not popup an "add contact" on XTEN. Anything I missed here ? Thanks for any hints or suggestions The Freeswitch server logs are below: 2008-04-11 13:57:32 [NOTICE] libdingaling.c:1276 on_log() SEND: ------------------------------------------------------------------------ ------- <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:component:accept" to="fs" version="1.0"></stream:stream> 2008-04-11 13:57:32 [INFO] libdingaling.c:1274 on_log() RECV: ------------------------------------------------------------------------ ------- <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:component:accept" from="fs.jabber2.MyDomain" id="69fcaa7b"></stream:stream> 2008-04-11 13:57:32 [NOTICE] libdingaling.c:1276 on_log() SEND: ------------------------------------------------------------------------ ------- <handshake>72dac833190326bb82dddedae558b2b794df5e1b</handshake> 2008-04-11 13:57:32 [INFO] libdingaling.c:1274 on_log() RECV: ------------------------------------------------------------------------ ------- <handshake></handshake> 2008-04-11 13:57:32 [INFO] libdingaling.c:1274 on_log() RECV: ------------------------------------------------------------------------ ------- <iq type="get" id="970-504" from="component.jabber2.MyDomain" to="fs.jabber2.MyDomain"> <query xmlns="http://jabber.org/protocol/disco#info"></query> </iq> 2008-04-11 13:57:32 [NOTICE] libdingaling.c:1276 on_log() SEND: ------------------------------------------------------------------------ ------- <iq from="fs" to="component.jabber2.MyDomain" id="970-504" type="result"> <query xmlns="http://jabber.org/protocol/disco#info"> <identity category="gateway" name="LibDingaLing"></identity> <feature var="http://jabber.org/protocol/disco"></feature> <feature var="http://jabber.org/protocol/disco#info"></feature> <feature var="jabber:iq:version"></feature> <feature var="vcard-temp"></feature> <feature var="http://www.google.com/xmpp/protocol/voice/v1"></feature> <feature var="jabber:iq:last"></feature> </query> </iq>

1 0

Freeswitch and Openser
by Pete Kay 11 Apr '08

11 Apr '08

Hi all, I am currently evaluating either using Freeswitch or Openser for my SIP server. I am trying to look for information that can tell me the difference between the two in terms of ease-of-maintain, ease-of-implement, and scalability. If you have such kind of information, would you please share with me? Thank you very much for your input. Best Regards, Pete

4 4

Incoming fax problems
by Josip Djuricic 11 Apr '08

11 Apr '08

Hi there I wanted to ask for advice on my incoming fax receive problem. When I send the fax to a Patton smartnode FXS gateway behind FS (and the call goes PSTN < -DSS1- > AS5300 <-h323> Yate <-sip-> FS <-sip-> PATTON). I needed to add yate to act as h323 to sip converter because my AS5300 had problems with sip (not only to FS, but to almost every device, seams like a sw issue). So now my fax behind FS answers, but the call fails after a while. What I've noticed on FS output, though not sure if it's related is: [DEBUG] switch_ivr_bridge.c:275 audio_bridge_thread() read: sofia/default/38514001702 Bad Frame.... Bubye! I'm including entire FS debug output of that call. I need to also notice that outgoing fax sending works just perfect. Thank you all, Josip #irc jdjurici 2008-04-11 13:46:46 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/38514001702 entering state [ready] 2008-04-11 13:46:46 [DEBUG] sofia.c:1599 sofia_handle_sip_i_state() Remote SDP: v=0 o=MxSIP 0 81 IN IP4 89.18.37.100 s=SIP Call c=IN IP4 89.18.37.100 t=0 0 m=audio 5024 RTP/AVP 8 a=rtpmap:8 PCMA/8000 2008-04-11 13:46:46 [DEBUG] sofia_glue.c:2011 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMA:8:8000]/[PCMA:8:8000] 2008-04-11 13:46:46 [DEBUG] sofia_glue.c:1333 sofia_glue_tech_set_codec() Set Codec sofia/default/38514001702 PCMA/8000 20 ms 160 samples 2008-04-11 13:46:46 [DEBUG] sofia_glue.c:1523 sofia_glue_activate_rtp() AUDIO RTP [sofia/default/38514001702] 89.18.32.19:25440->89.18.37.100:5024 codec: 8 ms: 20 2008-04-11 13:46:46 [DEBUG] switch_rtp.c:716 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-04-11 13:46:46 [DEBUG] switch_channel.c:1506 switch_channel_perform_mark_answered() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:46:46 [NOTICE] sofia.c:1945 sofia_handle_sip_i_state() Channel [sofia/default/38514001702] has been answered 2008-04-11 13:46:46 [DEBUG] sofia_glue.c:1523 sofia_glue_activate_rtp() AUDIO RTP [sofia/outbound/38516184904(a)10.0.3.220] 89.18.32.19:29046->10.0.3.220:17396 codec: 8 ms: 20 2008-04-11 13:46:46 [DEBUG] switch_rtp.c:716 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-04-11 13:46:46 [DEBUG] mod_sofia.c:376 sofia_answer_channel() Local SDP sofia/outbound/38516184904(a)10.0.3.220: v=0 o=FreeSWITCH 1207885360 1207885361 IN IP4 89.18.32.19 s=FreeSWITCH c=IN IP4 89.18.32.19 t=0 0 a=sendrecv m=audio 29046 RTP/AVP 8 101 13 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 2008-04-11 13:46:46 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:46:46 [NOTICE] switch_ivr_originate.c:1171 switch_ivr_originate() Channel [sofia/outbound/38516184904(a)10.0.3.220] has been answered 2008-04-11 13:46:46 [DEBUG] switch_ivr_originate.c:1205 switch_ivr_originate() Originate Resulted in Success: [sofia/default/38514001702] 2008-04-11 13:46:46 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/default/38514001702 [BREAK] 2008-04-11 13:46:46 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:46:46 [DEBUG] switch_ivr_bridge.c:756 switch_ivr_multi_threaded_bridge() sofia/default/38514001702 State Change CS_HOLD -> CS_LOOPBACK 2008-04-11 13:46:46 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/38514001702 [BREAK] send 897 bytes to udp/[10.0.3.220]:5090 at 11:46:46.446911: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.3.220:5090;rport=5090;branch=z9hG4bK293463607 From: "10.0.3.10" <sip:38516184904@10.0.3.220>;tag=1005463975 To: <sip:38514001702@89.18.32.19:5080>;tag=2Sgt80aptejjg Call-ID: 1414260367(a)10.0.3.220 CSeq: 19 INVITE Contact: <sip:mod_sofia@89.18.32.19:5080;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8058 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, precondition, timer Allow-Events: talk Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 272 v=0 o=FreeSWITCH 6013977101500251822 7042482777030961138 IN IP4 89.18.32.19 s=FreeSWITCH c=IN IP4 89.18.32.19 t=0 0 a=sendrecv m=audio 29046 RTP/AVP 8 101 13 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 ------------------------------------------------------------------------ 2008-04-11 13:46:46 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/outbound/38516184904(a)10.0.3.220 entering state [completed] recv 404 bytes from udp/[10.0.3.220]:5090 at 11:46:46.459555: ------------------------------------------------------------------------ ACK sip:mod_sofia@89.18.32.19:5080;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.0.3.220:5090;rport;branch=z9hG4bK1807442927 From: "10.0.3.10" <sip:38516184904@10.0.3.220>;tag=1005463975 To: <sip:38514001702@89.18.32.19:5080>;tag=2Sgt80aptejjg Call-ID: 1414260367(a)10.0.3.220 CSeq: 19 ACK Max-Forwards: 20 Contact: <sip:38516184904@10.0.3.220:5090> User-Agent: sip-to-h323/0.9.0 Content-Length: 0 ------------------------------------------------------------------------ 2008-04-11 13:46:46 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/outbound/38516184904(a)10.0.3.220 entering state [ready] 2008-04-11 13:46:46 [DEBUG] switch_core_state_machine.c:440 switch_core_session_run() (sofia/default/38514001702) State HOLD going to sleep 2008-04-11 13:46:46 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/38514001702 Running State Change CS_LOOPBACK 2008-04-11 13:46:46 [DEBUG] switch_core_state_machine.c:431 switch_core_session_run() (sofia/default/38514001702) State LOOPBACK 2008-04-11 13:46:46 [DEBUG] mod_sofia.c:314 sofia_on_loopback() SOFIA LOOPBACK freeswitch@softsw00> freeswitch@softsw00> recv 440 bytes from udp/[89.18.37.100]:5062 at 11:47:25.493537: ------------------------------------------------------------------------ BYE sip:mod_sofia@89.18.32.19:5060 SIP/2.0 Via: SIP/2.0/UDP 89.18.37.100:5062;branch=z9hG4bKc22903e25 Max-Forwards: 70 Content-Length: 0 To: "10.0.3.10" <sip:38516184904@89.18.32.19>;tag=KtFgg4Z384S5j From: <sip:38514001702@89.18.37.100:5062>;tag=01ec8a090df17a1 Call-ID: cc981044-825f-122b-1ca9-001e0b83659c CSeq: 802101929 BYE Supported: timer Supported: replaces User-Agent: Patton SN4112 JS EUI MxSF v3.2.8.45 00A0BA02B814 ------------------------------------------------------------------------ send 498 bytes to udp/[89.18.37.100]:5062 at 11:47:25.494066: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 89.18.37.100:5062;branch=z9hG4bKc22903e25 From: <sip:38514001702@89.18.37.100:5062>;tag=01ec8a090df17a1 To: "10.0.3.10" <sip:38516184904@89.18.32.19>;tag=KtFgg4Z384S5j Call-ID: cc981044-825f-122b-1ca9-001e0b83659c CSeq: 802101929 BYE User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8058 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: 100rel, precondition, timer Content-Length: 0 ------------------------------------------------------------------------ 2008-04-11 13:47:25 [DEBUG] sofia.c:1595 sofia_handle_sip_i_state() Channel sofia/default/38514001702 entering state [terminated] 2008-04-11 13:47:25 [NOTICE] sofia.c:1992 sofia_handle_sip_i_state() Hangup sofia/default/38514001702 [CS_LOOPBACK] [NORMAL_CLEARING] 2008-04-11 13:47:25 [DEBUG] switch_channel.c:1355 switch_channel_perform_hangup() Kill sofia/default/38514001702 [KILL] 2008-04-11 13:47:25 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/default/38514001702 [BREAK] 2008-04-11 13:47:25 [DEBUG] switch_ivr_bridge.c:275 audio_bridge_thread() read: sofia/default/38514001702 Bad Frame.... Bubye! 2008-04-11 13:47:25 [DEBUG] switch_ivr_bridge.c:344 audio_bridge_thread() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:47:25 [DEBUG] switch_ivr_bridge.c:347 audio_bridge_thread() BRIDGE THREAD DONE [sofia/default/38514001702] 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:431 switch_core_session_run() (sofia/default/38514001702) State LOOPBACK going to sleep 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/default/38514001702 Running State Change CS_HANGUP 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/38514001702) State HANGUP 2008-04-11 13:47:25 [DEBUG] mod_sofia.c:255 sofia_on_hangup() Channel sofia/default/38514001702 hanging up, cause: NORMAL_CLEARING 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/default/38514001702, cause: NORMAL_CLEARING 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/default/38514001702) State HANGUP going to sleep 2008-04-11 13:47:25 [DEBUG] switch_core_session.c:730 switch_core_session_thread() Session 145 (sofia/default/38514001702) Locked, Waiting on external entities 2008-04-11 13:47:25 [DEBUG] switch_core_session.c:383 switch_core_session_receive_message() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:47:25 [DEBUG] switch_ivr_bridge.c:344 audio_bridge_thread() Kill sofia/default/38514001702 [BREAK] 2008-04-11 13:47:25 [DEBUG] switch_ivr_bridge.c:347 audio_bridge_thread() BRIDGE THREAD DONE [sofia/outbound/38516184904(a)10.0.3.220] 2008-04-11 13:47:25 [NOTICE] switch_core_state_machine.c:156 switch_core_standard_on_execute() Hangup sofia/outbound/38516184904(a)10.0.3.220 [CS_EXECUTE] [NORMAL_CLEARING] 2008-04-11 13:47:25 [DEBUG] switch_channel.c:1355 switch_channel_perform_hangup() Kill sofia/outbound/38516184904(a)10.0.3.220 [KILL] 2008-04-11 13:47:25 [DEBUG] switch_core_session.c:670 switch_core_session_signal_state_change() Kill sofia/outbound/38516184904(a)10.0.3.220 [BREAK] 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:428 switch_core_session_run() (sofia/outbound/38516184904(a)10.0.3.220) State EXECUTE going to sleep 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:364 switch_core_session_run() sofia/outbound/38516184904(a)10.0.3.220 Running State Change CS_HANGUP 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/outbound/38516184904(a)10.0.3.220) State HANGUP send 626 bytes to udp/[10.0.3.220]:5090 at 11:47:25.500778: 2008-04-11 13:47:25 [DEBUG] mod_sofia.c:255 sofia_on_hangup() Channel sofia/outbound/38516184904(a)10.0.3.220 hanging up, cause: NORMAL_CLEARING BYE sip:38516184904@10.0.3.220:5090 SIP/2.0 Via: SIP/2.0/UDP 89.18.32.19:5080;rport;branch=z9hG4bKK5Zr11t0jaS2m Max-Forwards: 70 From: <sip:38514001702@89.18.32.19:5080>;tag=2Sgt80aptejjg To: "10.0.3.10" <sip:38516184904@10.0.3.220>;tag=1005463975 Call-ID: 1414260367(a)10.0.3.220 CSeq: 97838886 BYE Contact: <sip:mod_sofia@89.18.32.19:5080;transport=udp>2008-04-11 13:47:25 [DEBUG] mod_sofia.c:287 sofia_on_hangup() Sending BYE to sofia/outbound/38516184904(a)10.0.3.220 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/outbound/38516184904(a)10.0.3.220, cause: NORMAL_CLEARING User-Agent: FreeSWITCH-mod_sofia/1.0.pre4-8058 2008-04-11 13:47:25 [DEBUG] switch_core_state_machine.c:392 switch_core_session_run() (sofia/outbound/38516184904(a)10.0.3.220) State HANGUP going to sleep Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO 2008-04-11 13:47:25 [DEBUG] switch_core_session.c:730 switch_core_session_thread() Session 144 (sofia/outbound/38516184904(a)10.0.3.220) Locked, Waiting on external entities Supported: 100rel, precondition, timer Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 ------------------------------------------------------------------------ 2008-04-11 13:47:25 [NOTICE] switch_core_session.c:748 switch_core_session_thread() Session 144 (sofia/outbound/38516184904(a)10.0.3.220) Ended 2008-04-11 13:47:25 [NOTICE] switch_core_session.c:750 switch_core_session_thread() Close Channel sofia/outbound/38516184904(a)10.0.3.220 [CS_HANGUP] 2008-04-11 13:47:25 [NOTICE] switch_core_session.c:748 switch_core_session_thread() Session 145 (sofia/default/38514001702) Ended 2008-04-11 13:47:25 [NOTICE] switch_core_session.c:750 switch_core_session_thread() Close Channel sofia/default/38514001702 [CS_HANGUP] recv 336 bytes from udp/[10.0.3.220]:5090 at 11:47:25.511122: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 89.18.32.19:5080;rport=5080;branch=z9hG4bKK5Zr11t0jaS2m;received=89.18.32.19 From: <sip:38514001702@89.18.32.19:5080>;tag=2Sgt80aptejjg To: "10.0.3.10" <sip:38516184904@10.0.3.220>;tag=1005463975 Call-ID: 1414260367(a)10.0.3.220 CSeq: 97838886 BYE Server: sip-to-h323/0.9.0 Content-Length: 0 ------------------------------------------------------------------------ recv 390 bytes from udp/[10.0.3.220]:5090 at 11:47:25.530548: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 89.18.32.19:5080;rport=5080;branch=z9hG4bKK5Zr11t0jaS2m;received=89.18.32.19 Call-ID: 1414260367(a)10.0.3.220 CSeq: 97838886 BYE Server: sip-to-h323/0.9.0 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, OPTIONS, INFO Content-Length: 0 ------------------------------------------------------------------------

3 3