- FreeSWITCH-dev - FreeSWITCH Mailing Lists

How to get Peer Session after Bridge (Originate)
by Achim Stamm 29 Oct '10

29 Oct '10

Hello, I have following problem: I used following code for bridging my current session to multiple Voip Phones in a freeswitch thread (same as bgapi): switch_ivr_originate(session, &peer_session, &cause, "user/60@192.168.1.50,user/61@192.168.1.50", timelimit, NULL, NULL, NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) Both Phones with number 60 and 61 rings. In a special case I need to know when the peer_session hanged up (channel is not ready any more). I use following code for controling my bridged session (The peer_session) in another Thread: while (!peer_session) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO, "Session Nebenstelle is NULL ... Wait\n"); Sleep(200); } switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO, "Session Nebenstelle is created from originate call! \n"); channelNebenstelle = switch_core_session_get_channel(peer_session); while(switch_channel_ready(channel) && switch_channel_ready(channelNebenstelle)) { // Communication : Sleep(200); } switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO, "Session or Peer Session hangsup!\n"); // doing something special ... My peer_session is NULL, but Communication is possible. Why is my peer_session always NULL ? Is there a better solution (example a core-function) for getting my current connected peer_session ? I have tried switch_ivr_find_bridged_uuid(my_uuid, other_uuid,255 ); and sessionNebenstelle = switch_core_session_locate(other_uuid); ... but I get the session, which have loosed the race. regards Achim Stamm -- Achim Stamm, Dipl.-Inform. (FH) Lyncker & Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/9006951 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 04323897052 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis

2 1

Searching for a valid extension.
by Geovani Ricardo Wiedenhoft 29 Oct '10

29 Oct '10

Hello, We are completing development of the mod_khomp endpoint for Khomp boards: - FXS - FXO - E1 - GSM (boards and usb devices) - Passive record - kommuter However, we are constrained in our implementation. We needed to verify that a given set of digits has a valid extension or if can wait for more digits at some points of our code, without making the call. In our implementation for Asterisk (our Khomp channel), we use the functions provided by the Asterisk: ############################## ############################################### ASTERISK: /* \brief Looks for a valid matching extension */ - ast_canmatch_extension /* \brief Looks to see if adding anything to this extension might match something. (exists ^ canmatch) */ - ast_matchmore_extension ############################################################################# Searching for a solution, we implemented within mod_khomp the reading and checking functions of digits and expressions in XML, but our implementation limits us to XML dialplans, which it would not be compatible if the user need the database or other constructions of the dialplan. So, I would like to know what is the possibility of similar functions to be implemented in the core? Thanks :) Geovani Ricardo Wiedenhoft

3 5

INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite
by Achim Stamm 29 Oct '10

29 Oct '10

Hello, I have following problem: An external Call from LinkSys 3102 (Analog phone) is bridged to a X-Lite Phone. X-Lite Phone is ringing and after pickup sometimes I get an error INCOMPATIBLE_DESTINATION (see snippet of logfile). Mostly all works fine, but I can't understand why this error INCOMPATIBLE_DESTINATION sometimes occurs. Is there a solution for avoiding INCOMPATIBLE_DESTINATION or an explanation why this error sometimes occurs? regards Achim Stamm snippet of logfile: 2010-10-25 17:00:58.296875 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:60@192.168.1.114:52111 entering state [ready][200] 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:3585 Audio Codec Compare [PCMA:8:8000:20]/[PCMA:8:8000:20] 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:2354 Set Codec sofia/internal/sip:60@192.168.1.114:52111 PCMA/8000 20 ms 160 samples 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:3518 Set 2833 dtmf send payload to 101 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/internal/sip:60@192.168.1.114:52111] 192.168.1.114 port 26696 -> 192.168.1.114 port 58588 codec: 8 ms: 20 2010-10-25 17:00:58.296875 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2010-10-25 17:00:58.296875 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2010-10-25 17:00:58.296875 [DEBUG] switch_channel.c:2324 Send signal sofia/internal/50(a)192.168.1.114 [BREAK] 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel [sofia/internal/sip:60@192.168.1.114:52111] has been answered 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup sofia/internal/50(a)192.168.1.114 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2010-10-25 17:00:58.312500 [INFO] mod_ebv.cpp:1264 leavin ebv_process_call_extern 2010-10-25 17:00:58.312500 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/50(a)192.168.1.114 [KILL] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/50(a)192.168.1.114) State EXECUTE going to sleep 2010-10-25 17:01:05.375000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50(a)192.168.1.114 [BREAK] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50(a)192.168.1.114) Running State Change CS_HANGUP 2010-10-25 17:01:05.375000 [DEBUG] switch_ivr_originate.c:3111 sofia/internal/50(a)192.168.1.114 Media Establishment Failed. 2010-10-25 17:01:05.375000 [NOTICE] switch_ivr_originate.c:3113 Hangup sofia/internal/sip:60@192.168.1.114:52111 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION] 2010-10-25 17:01:05.375000 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/sip:60@192.168.1.114:52111 [KILL] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60@192.168.1.114:52111 [BREAK] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60@192.168.1.114:52111) Running State Change CS_HANGUP 2010-10-25 17:01:05.375000 [DEBUG] switch_ivr_originate.c:3228 Originate Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION] 2010-10-25 17:01:05.375000 [INFO] mod_ebv.cpp:2218 Originate Failed. Cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.375000 [INFO] mod_ebv.cpp:154 .... Bridge-Call Thread beendet!! 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/50(a)192.168.1.114) State HANGUP 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/50(a)192.168.1.114 hanging up, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:60@192.168.1.114:52111) State HANGUP 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/sip:60@192.168.1.114:52111 hanging up, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:476 Responding to INVITE with: 488 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 sofia/internal/50(a)192.168.1.114 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/50(a)192.168.1.114) State HANGUP going to sleep 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/50(a)192.168.1.114) State Change CS_HANGUP -> CS_REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50(a)192.168.1.114 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50(a)192.168.1.114) Running State Change CS_REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/50(a)192.168.1.114) State REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 sofia/internal/50(a)192.168.1.114 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/50(a)192.168.1.114) State REPORTING going to sleep 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/50(a)192.168.1.114) State Change CS_REPORTING -> CS_DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50(a)192.168.1.114 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 (sofia/internal/50(a)192.168.1.114) Locked, Waiting on external entities 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1182 Session 23 (sofia/internal/50(a)192.168.1.114) Ended 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close Channel sofia/internal/50(a)192.168.1.114 [CS_DESTROY] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 (sofia/internal/50(a)192.168.1.114) Running State Change CS_DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/50(a)192.168.1.114) State DESTROY 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 sofia/internal/50(a)192.168.1.114 SOFIA DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 sofia/internal/50(a)192.168.1.114 Standard DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/50(a)192.168.1.114) State DESTROY going to sleep 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:457 Sending BYE to sofia/internal/sip:60@192.168.1.114:52111 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 sofia/internal/sip:60@192.168.1.114:52111 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:60@192.168.1.114:52111) State HANGUP going to sleep 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/sip:60@192.168.1.114:52111) State Change CS_HANGUP -> CS_REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60@192.168.1.114:52111 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60@192.168.1.114:52111) Running State Change CS_REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:60@192.168.1.114:52111) State REPORTING 2010-10-25 17:01:05.406250 [DEBUG] switch_core_state_machine.c:53 sofia/internal/sip:60@192.168.1.114:52111 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2010-10-25 17:01:05.406250 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:60@192.168.1.114:52111) State REPORTING going to sleep 2010-10-25 17:01:05.406250 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/sip:60@192.168.1.114:52111) State Change CS_REPORTING -> CS_DESTROY 2010-10-25 17:01:05.406250 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60@192.168.1.114:52111 [BREAK] 2010-10-25 17:01:05.406250 [DEBUG] switch_core_session.c:1164 Session 24 (sofia/internal/sip:60@192.168.1.114:52111) Locked, Waiting on external entities -- Achim Stamm, Dipl.-Inform. (FH) Lyncker & Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/9006951 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 04323897052 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis

3 7

Language files - French, German, Spanish, etc.
by Michael Collins 28 Oct '10

28 Oct '10

Hello all! I have heard about several of our intrepid community members creating sound sets in various languages. If you have created a sound set in any language other than US English please contact me off list. I want to help get this sound prompts organized so that the global community can use them. Thanks! -Michael

1 0

FS Conference Call Recordings
by Michael Collins 28 Oct '10

28 Oct '10

Hello all! I just wanted to let everyone know that I have started putting the recordings for the conference calls on the main conference page: http://wiki.freeswitch.org/wiki/Weekly_Conference_Call#Past_Calls I've got them in mp3, ogg, and wave formats. Enjoy! -MC

1 0

Handling of multiple 183 responses with different SDP
by Irina Ivanova 28 Oct '10

28 Oct '10

Hi! We are getting the same problem as described in the jira ticket with key FS-715: http://jira.freeswitch.org/browse/FS-715?page=com.atlassian.jira.plugin.sys… Our provider is also sending us more than one 183 Session progress response, each of them with SDP where destination IP address is the same but the UDP ports are different. If is needed I can provide the pcap file where you can see that after receiving of second 183 Session progress response (with updated SDP) Freeswitch continues to listen on an old port. As a consequence, no audio can be heard. Our provider assures us that sending of more than one 183 Session progress responses is completely standard behavior that does not violate SIP RFC 3261 and is handled correctly by any ATA VoIP. We verified the Asterisk behavior in this case, and can say that it handles receiving of multiple 183 Session progress responses without any problems and changes the UDP port each time it gets changed in session description inside of 183 response. Our provider gave us a reference to SIP RFC 3261: 13 Initiating a Session 13.1 Overview "Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response." "one or more provisional responses" was underlined by our provider and in addition to this was said that there is no any place in RFC from which you can conclude that you can not send more than one SIP 183 Session Progress response. We also found a document regarding 183 response: http://tools.ietf.org/html/draft-ietf-sip-183-00 Here are some references to the parts talking about temporary media and session description change: 4.2. Change of Temporary Media After a temporary media stream has been established, its parameters can be changed by sending further provisional responses that also contain session descriptions. Upon receipt of such a response, the client MUST immediately cease transmission of media relating to the old temporary stream. As before, the new temporary media stream is established after acknowledgement of the provisional response. Provisional responses which contain no session description SHOULD NOT have an effect on any currently established temporary media stream. 5.11.7 Caller Receives 183 Response When the calling UA receives a 183 response that contains a session description and an indication that the session description is for early media, it SHALL setup the associated media session and present any media received from the called UA to the user. Again nothing is said about multiple 183 responses specifically, only about multiple provisional responses in general. So, is there anything that can be done to resolve this issue? Thanx, Irina -- ================================================================ Distinti saluti -- Irina Ivanova Settore Sviluppo MasterVoice tel: +39 0522 1846007 fax: +39 0522 331673 mob: +39 334 6449290 e-mail: i.ivanova(a)mastervoice.it web: www.mastertraining.it - www.registroelettronico.com Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy ================================================================ Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax.

3 3

Support for RFC 4575 - SIP Event Package for Conference State
by Fowler, Peter (Peter) 27 Oct '10

27 Oct '10

Does FreeSWITCH support this RFC (I can't find any reference to it in the code). If not, how would one go about adding support (at a high level)? Peter

1 0

FreeSWITCH Conference Call Today
by Michael Collins 27 Oct '10

27 Oct '10

Hey folks, Our FreeSWITCH conference call is coming up in less than an hour. Here's the agenda: http://wiki.freeswitch.org/wiki/FS_weekly_2010_10_27 We don't have a specific presentation today but there are a few things I need to discuss with you and we also have a few user tips and tricks that I'd like to have everyone try and give their feedback. Talk to you shortly. -MC

1 0

Presence questions
by Beeton, Carolyn (Carolyn) 26 Oct '10

26 Oct '10

In an attempt to understand better what FS is doing, I have registered a couple of sets directly to FS. One (46, a Polycom) subscribes for presence events (RFC3856), and another (48, a Snom) subscribes for dialog events (RFC4235). Both are monitoring extension 45 (another Polycom set) as well as extension 44 (a FS application extension which just plays back a music file). 46 is another Polycom. One thing I notice right away: a call from 45 to 46 (i.e. from monitored to unmonitored extension) causes the light to stick "on" on both the Polycom and Snom set. The query around sofia_presence line 762 has the wrong user (i.e. not the monitored set). The light goes out properly if you call from 46 to 45 and release (i.e. if the monitored set is the callee). The dialog event that is sent when a call from 45 (monitored) to 46 (not monitored) is answered looks like this: 2010-10-25 15:34:45.885611 [DEBUG] sofia_presence.c:1654 send payload: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="full" entity="sip:45@cbeetonscs.ca.nortel.com"> <dialog id="fdc62b22-0ad9-491a-b1bb-9be30459dc10" direction="recipient"> <state>confirmed</state> <local> <identity display="45">sip:45@47.135.152.158</identity> <target uri="sip:45@47.135.152.158"> <param pname="+sip.rendering" pvalue="yes"/> </target> </local> <remote> <identity display="45">sip:45@47.135.152.158</identity> <target uri="sip:**45@47.135.152.158"/> </remote> </dialog> </dialog-info> - ** in the remote target uri? Does it mean something? - both the local and remote target identity uri's are the same. Obviously not. >From 46 (not monitored) to 45 (monitored): 2010-10-25 15:55:05.649783 [DEBUG] sofia_presence.c:1655 send payload: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="9" state="full" entity="sip:45@cbeetonscs.ca.nortel.com"> <dialog id="67220171-54e0-4adb-abfe-790b6a7dd066" direction="recipient"> <state>confirmed</state> <local> <identity display="45">sip:45@47.135.152.158</identity> <target uri="sip:45@47.135.152.158"> <param pname="+sip.rendering" pvalue="yes"/> </target> </local> <remote> <identity display="46">sip:46@47.135.152.158</identity> <target uri="sip:**45@47.135.152.158"/> </remote> </dialog> </dialog-info> - note the remote display is correct, but the remote target uri is not. Part of my confusion is that FS is sending TWO dialog events, one for each leg of the call (both labelled "full"!). But it really shouldn't be. It should only be sending the leg that is TO the monitored extension. (And the direction should reflect that). (Of course, if both ends are monitored, two events would be appropriate). Restarting FS seems to mess up the dialog subscriptions. Until the sets get around to resubscribing, no events are sent. The presence subscriptions seems to survive restart. Not sure how that makes sense, but that's what I see. Carolyn

1 1

How to hangup bridged sessions
by Achim Stamm 26 Oct '10

26 Oct '10

How to hangup bridged sessions Hello, i have following problem: I used following code for brdiging my current session to multiple Voip Phones in a freeswitch thread (same as bgapi): switch_ivr_originate(session, &peer_session, &cause, "user/60@192.168.1.50,user/61@192.168.1.50", timelimit, NULL, NULL, NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) Both Phones with number 60 and 61 rings. In a special case I need to force hangup both Phones (stop ringing). I use following code for hangup bridged sessions: char * my_uuid = switch_core_session_get_uuid(session); char other_uuid[255]; switch_ivr_find_bridged_uuid(my_uuid, other_uuid,255 ); sessionNebenstelle = switch_core_session_locate(other_uuid); if (sessionNebenstelle) { channelNebenstelle = switch_core_session_get_channel(sessionNebenstelle); switch_channel_hangup(channelNebenstelle,SWITCH_CAUSE_NO_ANSWER); if (switch_core_session_private_event_count(sessionNebenstelle)) { switch_ivr_parse_all_events(sessionNebenstelle); } } This Code works only for one phone, so Phone 61 stops ringing, but Phone 60 continue ringing. It is possible, that i can hangup the other phone ? Is there a better solution for cancel switch_ivr_originate (hangup all originating sessions ?) Greetings Achim Stamm -- Achim Stamm, Dipl.-Inform. (FH) Lyncker & Theis GmbH Wilhelmstr. 16 65185 Wiesbaden Germany Fon +49 611/9006951 Fax +49 611/9406125 Handelsregister: HRB 23156 Amtsgericht Wiesbaden Steuernummer: 04323897052 USt-IdNr.: DE255806399 Geschäftsführer: Filip Lyncker, Armin Theis

3 4