From stamm at lyth.de Fri Oct 1 09:01:50 2010 From: stamm at lyth.de (Achim Stamm) Date: Fri, 01 Oct 2010 18:01:50 +0200 Subject: [Freeswitch-dev] How to hangup bridged sessions Message-ID: <4CA605EE.10604@lyth.de> 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 at 192.168.1.50,user/61 at 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 From bernhard.suttner at winet.ch Fri Oct 1 09:19:12 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Fri, 1 Oct 2010 18:19:12 +0200 Subject: [Freeswitch-dev] How to hangup bridged sessions In-Reply-To: <4CA605EE.10604@lyth.de> References: <4CA605EE.10604@lyth.de> Message-ID: Hi, Did you try to hangup the session (not the peer session). This should freeswitch force to hangup all related channels (the session + the connected sessions). BR, Bernhard -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Achim Stamm Gesendet: Freitag, 1. Oktober 2010 18:02 An: freeswitch-dev at lists.freeswitch.org Betreff: [Freeswitch-dev] How to hangup bridged sessions 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 at 192.168.1.50,user/61 at 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 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From stamm at lyth.de Fri Oct 1 09:36:04 2010 From: stamm at lyth.de (Achim Stamm) Date: Fri, 01 Oct 2010 18:36:04 +0200 Subject: [Freeswitch-dev] How to hangup bridged sessions In-Reply-To: References: <4CA605EE.10604@lyth.de> Message-ID: <4CA60DF4.7000801@lyth.de> Bernhard Suttner schrieb: > Hi, > > Did you try to hangup the session (not the peer session). This should freeswitch force to hangup all related channels (the session + the connected sessions). > > BR, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Achim Stamm > Gesendet: Freitag, 1. Oktober 2010 18:02 > An: freeswitch-dev at lists.freeswitch.org > Betreff: [Freeswitch-dev] How to hangup bridged sessions > > 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 at 192.168.1.50,user/61 at 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 > > For my special case: I need my session alive for doing read and write frame in a while loop. After hanging up the peer Sessions. I do an answer (for my session) and enter the while loop. The "Connection" to another Session (also in a read and write frame while loop) is done by exchanging manually audio frames. Thanks for your question. -- 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 From anthony.minessale at gmail.com Fri Oct 1 12:17:50 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 1 Oct 2010 14:17:50 -0500 Subject: [Freeswitch-dev] How to hangup bridged sessions In-Reply-To: <4CA60DF4.7000801@lyth.de> References: <4CA605EE.10604@lyth.de> <4CA60DF4.7000801@lyth.de> Message-ID: switch_call_cause_t *cancel_cause is the last arg to originate switch_call_cause_t cancel_cause = SWITCH_CAUSE_NONE; pass &cancel_cause as the final arg to originate. if originate is in some other thread you will need to create the cancel_cause in the other thread and pass it up. Then when you change cancel cause to some cause, all sessions in the originate thread will terminate with that cause. On Fri, Oct 1, 2010 at 11:36 AM, Achim Stamm wrote: > Bernhard Suttner schrieb: >> Hi, >> >> Did you try to hangup the session (not the peer session). This should freeswitch force to hangup all related channels (the session + the connected sessions). >> >> BR, >> Bernhard >> >> -----Urspr?ngliche Nachricht----- >> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Achim Stamm >> Gesendet: Freitag, 1. Oktober 2010 18:02 >> An: freeswitch-dev at lists.freeswitch.org >> Betreff: [Freeswitch-dev] How to hangup bridged sessions >> >> 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 at 192.168.1.50,user/61 at 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 >> >> > For my special case: > I need my session alive for doing read and write frame in a while loop. > After hanging up the peer Sessions. I do an answer (for my session) and > enter the while loop. > The "Connection" to another Session (also in a read and write frame > while loop) is done > by exchanging manually audio frames. > > Thanks for your question. > > -- > 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From wooshie at gmail.com Mon Oct 4 06:33:19 2010 From: wooshie at gmail.com (Bambr) Date: Mon, 4 Oct 2010 15:33:19 +0200 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> Message-ID: Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan. On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < anthony.minessale at gmail.com> wrote: > It doesn't say the call was successful it says the originate was. > The purpose of the originate function is to produce a channel with media. > The call can still end and you can still tell when and why from the > data in the call. > > > On Tue, Sep 28, 2010 at 11:27 AM, Michael Jerris wrote: > > > > On Sep 28, 2010, at 10:46 AM, Bambr wrote: > > > >> As far as I know, when, during the calling, FS recieves 183 responce, > call is considered succesful, it is marked in cdr and so on. While, there's > possibility for this call to be failed, as after ringing the call might be > declined. Asking in IRC on #freeswitch got me answer like "it's a question > of conventions" - and it is right, but our convention (dictated by users) is > that such call can not be marked as successful "a priori" - only when it > really succeeded. I tried looking at sources of FS finding the place where > it is judged, found something like it in switch_ivr_originate.c but i'm not > sure it is the right place and tests i did - they didn't get me needed > result. > >> So here is my question: is it possible to make configurable behavior > upon recieving 183? > >> > >> I'm aware about ignoring all early media, but this is not an option. I'm > interested in managing status of call on recieving 183. > > > > > > thats what ignore_early_media setting does. > > > > > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -- Bambr in da house -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/c220cdb9/attachment.html From brian at freeswitch.org Mon Oct 4 07:10:38 2010 From: brian at freeswitch.org (Brian West) Date: Mon, 4 Oct 2010 09:10:38 -0500 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> Message-ID: <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Might I recommend you open a trouble ticket with your carrier and make them fix their problem since you do PAY them for services and they are clearly screwing up. /b On Oct 4, 2010, at 8:33 AM, Bambr wrote: > Well, I want to ignore only 183, not all the early media responces, it is affecting dialplan, as continue-on-fail is not triggered if 486 is recieved after 183, which ruins failover functionality part of dialplan. > > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale wrote: > It doesn't say the call was successful it says the originate was. > The purpose of the originate function is to produce a channel with media. > The call can still end and you can still tell when and why from the > data in the call. From anthony.minessale at gmail.com Mon Oct 4 07:13:07 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Mon, 4 Oct 2010 09:13:07 -0500 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> Message-ID: once again, that is what setting ignore_early_media=true is for, when set, it keeps the channel in the originate function until either the call is answered or rejected. It does not ignore the responses it ignores the 183 as a possible reason to stop the originate. On Mon, Oct 4, 2010 at 8:33 AM, Bambr wrote: > Well, I want to ignore only 183, not all the early media responces, it is > affecting dialplan, as continue-on-fail is not triggered if 486 is recieved > after 183, which ruins failover functionality part of dialplan. > > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale > wrote: >> >> It doesn't say the call was successful it says the originate was. >> The purpose of the originate function is to produce a channel with media. >> The call can still end and you can still tell when and why from the >> data in the call. >> >> >> On Tue, Sep 28, 2010 at 11:27 AM, Michael Jerris wrote: >> > >> > On Sep 28, 2010, at 10:46 AM, Bambr wrote: >> > >> >> As far as I know, when, during the calling, FS recieves 183 responce, >> >> call is considered succesful, it is marked in cdr and so on. While, there's >> >> possibility for this call to be failed, as after ringing the call might be >> >> declined. Asking in IRC on #freeswitch got me answer like "it's a question >> >> of conventions" - and it is right, but our convention (dictated by users) is >> >> that such call can not be marked as successful "a priori" - only when it >> >> really succeeded. I tried looking at sources of FS finding the place where >> >> it is judged, found something like it in switch_ivr_originate.c but i'm not >> >> sure it is the right place and tests i did - they didn't get me needed >> >> result. >> >> So here is my question: is it possible to make configurable behavior >> >> upon recieving 183? >> >> >> >> I'm aware about ignoring all early media, but this is not an option. >> >> I'm interested in managing status of call on recieving 183. >> > >> > >> > thats what ignore_early_media setting does. >> > >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org > > > > -- > Bambr in da house > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From wooshie at gmail.com Mon Oct 4 08:25:22 2010 From: wooshie at gmail.com (Bambr) Date: Mon, 4 Oct 2010 17:25:22 +0200 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: Carrier support said that sending 183 and then 486 is ok and they don't see the problem. I'm a bit messed with what is wrong and what is ok. So, just to clarify: they should be sending 486 and no 183 before it when needed, right? On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: > Might I recommend you open a trouble ticket with your carrier and make them > fix their problem since you do PAY them for services and they are clearly > screwing up. > > /b > > On Oct 4, 2010, at 8:33 AM, Bambr wrote: > > > Well, I want to ignore only 183, not all the early media responces, it is > affecting dialplan, as continue-on-fail is not triggered if 486 is recieved > after 183, which ruins failover functionality part of dialplan. > > > > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < > anthony.minessale at gmail.com> wrote: > > It doesn't say the call was successful it says the originate was. > > The purpose of the originate function is to produce a channel with media. > > The call can still end and you can still tell when and why from the > > data in the call. > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -- Bambr in da house -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/05f52656/attachment.html From wooshie at gmail.com Mon Oct 4 08:35:25 2010 From: wooshie at gmail.com (Bambr) Date: Mon, 4 Oct 2010 17:35:25 +0200 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: Another clarification, just a simple use case: 1. Calling a number, getting 486 right away -> "continue on fail" is triggered, it's OK 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not triggered, which is not OK So usecase 2 is causing the troubles. On Mon, Oct 4, 2010 at 5:25 PM, Bambr wrote: > Carrier support said that sending 183 and then 486 is ok and they don't see > the problem. I'm a bit messed with what is wrong and what is ok. So, just to > clarify: they should be sending 486 and no 183 before it when needed, > right? > > > On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: > >> Might I recommend you open a trouble ticket with your carrier and make >> them fix their problem since you do PAY them for services and they are >> clearly screwing up. >> >> /b >> >> On Oct 4, 2010, at 8:33 AM, Bambr wrote: >> >> > Well, I want to ignore only 183, not all the early media responces, it >> is affecting dialplan, as continue-on-fail is not triggered if 486 is >> recieved after 183, which ruins failover functionality part of dialplan. >> > >> > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < >> anthony.minessale at gmail.com> wrote: >> > It doesn't say the call was successful it says the originate was. >> > The purpose of the originate function is to produce a channel with >> media. >> > The call can still end and you can still tell when and why from the >> > data in the call. >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> > > > > -- > Bambr in da house > -- Bambr in da house -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/0cc2a7a9/attachment-0001.html From msc at freeswitch.org Mon Oct 4 10:49:47 2010 From: msc at freeswitch.org (Michael Collins) Date: Mon, 4 Oct 2010 10:49:47 -0700 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: What happens in case #2 when you have ignore_early_media=true ? -MC On Mon, Oct 4, 2010 at 8:35 AM, Bambr wrote: > Another clarification, just a simple use case: > 1. Calling a number, getting 486 right away -> "continue on fail" is > triggered, it's OK > 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not > triggered, which is not OK > So usecase 2 is causing the troubles. > > > > On Mon, Oct 4, 2010 at 5:25 PM, Bambr wrote: > >> Carrier support said that sending 183 and then 486 is ok and they don't >> see the problem. I'm a bit messed with what is wrong and what is ok. So, >> just to clarify: they should be sending 486 and no 183 before it when >> needed, right? >> >> >> On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: >> >>> Might I recommend you open a trouble ticket with your carrier and make >>> them fix their problem since you do PAY them for services and they are >>> clearly screwing up. >>> >>> /b >>> >>> On Oct 4, 2010, at 8:33 AM, Bambr wrote: >>> >>> > Well, I want to ignore only 183, not all the early media responces, it >>> is affecting dialplan, as continue-on-fail is not triggered if 486 is >>> recieved after 183, which ruins failover functionality part of dialplan. >>> > >>> > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < >>> anthony.minessale at gmail.com> wrote: >>> > It doesn't say the call was successful it says the originate was. >>> > The purpose of the originate function is to produce a channel with >>> media. >>> > The call can still end and you can still tell when and why from the >>> > data in the call. >>> >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>> http://www.freeswitch.org >>> >> >> >> >> -- >> Bambr in da house >> > > > > -- > Bambr in da house > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/44961870/attachment.html From wooshie at gmail.com Mon Oct 4 12:15:10 2010 From: wooshie at gmail.com (Bambr) Date: Mon, 4 Oct 2010 21:15:10 +0200 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: Well, we can not use ignore_early_media=true, it's dictated by client, so we have it on false, but, for testing purposes i think it's possible to make small test. On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins wrote: > What happens in case #2 when you have ignore_early_media=true ? > -MC > > > On Mon, Oct 4, 2010 at 8:35 AM, Bambr wrote: > >> Another clarification, just a simple use case: >> 1. Calling a number, getting 486 right away -> "continue on fail" is >> triggered, it's OK >> 2. Calling a number, getting 183 and then 486 -> "continue on fail" is not >> triggered, which is not OK >> So usecase 2 is causing the troubles. >> >> >> >> On Mon, Oct 4, 2010 at 5:25 PM, Bambr wrote: >> >>> Carrier support said that sending 183 and then 486 is ok and they don't >>> see the problem. I'm a bit messed with what is wrong and what is ok. So, >>> just to clarify: they should be sending 486 and no 183 before it when >>> needed, right? >>> >>> >>> On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: >>> >>>> Might I recommend you open a trouble ticket with your carrier and make >>>> them fix their problem since you do PAY them for services and they are >>>> clearly screwing up. >>>> >>>> /b >>>> >>>> On Oct 4, 2010, at 8:33 AM, Bambr wrote: >>>> >>>> > Well, I want to ignore only 183, not all the early media responces, it >>>> is affecting dialplan, as continue-on-fail is not triggered if 486 is >>>> recieved after 183, which ruins failover functionality part of dialplan. >>>> > >>>> > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < >>>> anthony.minessale at gmail.com> wrote: >>>> > It doesn't say the call was successful it says the originate was. >>>> > The purpose of the originate function is to produce a channel with >>>> media. >>>> > The call can still end and you can still tell when and why from the >>>> > data in the call. >>>> >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at lists.freeswitch.org >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>> http://www.freeswitch.org >>>> >>> >>> >>> >>> -- >>> Bambr in da house >>> >> >> >> >> -- >> Bambr in da house >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -- Bambr in da house -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/217ef3fb/attachment.html From msc at freeswitch.org Mon Oct 4 13:56:55 2010 From: msc at freeswitch.org (Michael Collins) Date: Mon, 4 Oct 2010 13:56:55 -0700 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? -MC On Mon, Oct 4, 2010 at 12:15 PM, Bambr wrote: > Well, we can not use ignore_early_media=true, it's dictated by client, so > we have it on false, but, for testing purposes i think it's possible to make > small test. > > > On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins wrote: > >> What happens in case #2 when you have ignore_early_media=true ? >> -MC >> >> >> On Mon, Oct 4, 2010 at 8:35 AM, Bambr wrote: >> >>> Another clarification, just a simple use case: >>> 1. Calling a number, getting 486 right away -> "continue on fail" is >>> triggered, it's OK >>> 2. Calling a number, getting 183 and then 486 -> "continue on fail" is >>> not triggered, which is not OK >>> So usecase 2 is causing the troubles. >>> >>> >>> >>> On Mon, Oct 4, 2010 at 5:25 PM, Bambr wrote: >>> >>>> Carrier support said that sending 183 and then 486 is ok and they don't >>>> see the problem. I'm a bit messed with what is wrong and what is ok. So, >>>> just to clarify: they should be sending 486 and no 183 before it when >>>> needed, right? >>>> >>>> >>>> On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: >>>> >>>>> Might I recommend you open a trouble ticket with your carrier and make >>>>> them fix their problem since you do PAY them for services and they are >>>>> clearly screwing up. >>>>> >>>>> /b >>>>> >>>>> On Oct 4, 2010, at 8:33 AM, Bambr wrote: >>>>> >>>>> > Well, I want to ignore only 183, not all the early media responces, >>>>> it is affecting dialplan, as continue-on-fail is not triggered if 486 is >>>>> recieved after 183, which ruins failover functionality part of dialplan. >>>>> > >>>>> > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < >>>>> anthony.minessale at gmail.com> wrote: >>>>> > It doesn't say the call was successful it says the originate was. >>>>> > The purpose of the originate function is to produce a channel with >>>>> media. >>>>> > The call can still end and you can still tell when and why from the >>>>> > data in the call. >>>>> >>>>> >>>>> _______________________________________________ >>>>> FreeSWITCH-dev mailing list >>>>> FreeSWITCH-dev at lists.freeswitch.org >>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>>> http://www.freeswitch.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Bambr in da house >>>> >>> >>> >>> >>> -- >>> Bambr in da house >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > -- > Bambr in da house > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/c1c8d19b/attachment-0001.html From wooshie at gmail.com Mon Oct 4 17:50:05 2010 From: wooshie at gmail.com (Bambr) Date: Tue, 5 Oct 2010 02:50:05 +0200 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins wrote: > Could you remind me why you can't use ignore_early_media? I mean, what does > your client need that ignore_early_media does not provide? > -MC > > > On Mon, Oct 4, 2010 at 12:15 PM, Bambr wrote: > >> Well, we can not use ignore_early_media=true, it's dictated by client, so >> we have it on false, but, for testing purposes i think it's possible to make >> small test. >> >> >> On Mon, Oct 4, 2010 at 7:49 PM, Michael Collins wrote: >> >>> What happens in case #2 when you have ignore_early_media=true ? >>> -MC >>> >>> >>> On Mon, Oct 4, 2010 at 8:35 AM, Bambr wrote: >>> >>>> Another clarification, just a simple use case: >>>> 1. Calling a number, getting 486 right away -> "continue on fail" is >>>> triggered, it's OK >>>> 2. Calling a number, getting 183 and then 486 -> "continue on fail" is >>>> not triggered, which is not OK >>>> So usecase 2 is causing the troubles. >>>> >>>> >>>> >>>> On Mon, Oct 4, 2010 at 5:25 PM, Bambr wrote: >>>> >>>>> Carrier support said that sending 183 and then 486 is ok and they don't >>>>> see the problem. I'm a bit messed with what is wrong and what is ok. So, >>>>> just to clarify: they should be sending 486 and no 183 before it when >>>>> needed, right? >>>>> >>>>> >>>>> On Mon, Oct 4, 2010 at 4:10 PM, Brian West wrote: >>>>> >>>>>> Might I recommend you open a trouble ticket with your carrier and make >>>>>> them fix their problem since you do PAY them for services and they are >>>>>> clearly screwing up. >>>>>> >>>>>> /b >>>>>> >>>>>> On Oct 4, 2010, at 8:33 AM, Bambr wrote: >>>>>> >>>>>> > Well, I want to ignore only 183, not all the early media responces, >>>>>> it is affecting dialplan, as continue-on-fail is not triggered if 486 is >>>>>> recieved after 183, which ruins failover functionality part of dialplan. >>>>>> > >>>>>> > On Tue, Sep 28, 2010 at 6:44 PM, Anthony Minessale < >>>>>> anthony.minessale at gmail.com> wrote: >>>>>> > It doesn't say the call was successful it says the originate was. >>>>>> > The purpose of the originate function is to produce a channel with >>>>>> media. >>>>>> > The call can still end and you can still tell when and why from the >>>>>> > data in the call. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> FreeSWITCH-dev mailing list >>>>>> FreeSWITCH-dev at lists.freeswitch.org >>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>>>> UNSUBSCRIBE: >>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>>>> http://www.freeswitch.org >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Bambr in da house >>>>> >>>> >>>> >>>> >>>> -- >>>> Bambr in da house >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at 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 at lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>> http://www.freeswitch.org >>> >>> >> >> >> -- >> Bambr in da house >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -- Bambr in da house -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101005/911d982c/attachment.html From brian at freeswitch.org Mon Oct 4 18:19:07 2010 From: brian at freeswitch.org (Brian West) Date: Mon, 4 Oct 2010 20:19:07 -0500 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> Message-ID: <793AFE43-EA78-4A03-A66E-5E388569B373@freeswitch.org> check out "ringback" variable... and transfer_ringback. /b On Oct 4, 2010, at 7:50 PM, Bambr wrote: > well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center > > On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins wrote: > Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? > -MC > From mike at jerris.com Mon Oct 4 19:19:22 2010 From: mike at jerris.com (Michael Jerris) Date: Mon, 4 Oct 2010 22:19:22 -0400 Subject: [Freeswitch-dev] responce code 183 related functionality In-Reply-To: <793AFE43-EA78-4A03-A66E-5E388569B373@freeswitch.org> References: <6E85BA00-1667-48FC-AF67-7A460C7C38F1@jerris.com> <9A94D3A7-EFD7-44ED-8ED0-3D66C4A13F8C@freeswitch.org> <793AFE43-EA78-4A03-A66E-5E388569B373@freeswitch.org> Message-ID: <2000A699-DD7E-43AA-91F9-1DD9C2719871@jerris.com> did you try http://wiki.freeswitch.org/wiki/Variable_bridge_early_media ? be aware this comes with additional resource consumption required, but I think will do what your asking for. On Oct 4, 2010, at 9:19 PM, Brian West wrote: > check out "ringback" variable... and transfer_ringback. > > /b > > On Oct 4, 2010, at 7:50 PM, Bambr wrote: > >> well, if we set ignore_early_media to true, then, while the call is getting to other side, there's either silence or we can play some music from our side. silence is not accepted by client, and playing music and then getting busy tone - considered misleading and confusing. client - sort of call center >> >> On Mon, Oct 4, 2010 at 10:56 PM, Michael Collins wrote: >> Could you remind me why you can't use ignore_early_media? I mean, what does your client need that ignore_early_media does not provide? >> -MC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101004/bcfa3b9f/attachment.html From msc at freeswitch.org Wed Oct 6 08:19:18 2010 From: msc at freeswitch.org (Michael Collins) Date: Wed, 6 Oct 2010 08:19:18 -0700 Subject: [Freeswitch-dev] FreeSWITCH Conference Call Today Message-ID: Hello all! Our agenda for today is here: http://wiki.freeswitch.org/wiki/FS_weekly_2010_10_06 We have a few things to discuss, such as some additions to the default configs and some Jira tasks that we could use some help with. Also, we are hoping that Darren Schreiber will be calling in to give us an update from ITExpo down in L.A. Talk to you soon, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101006/cec1f0a8/attachment.html From d at d-man.org Wed Oct 6 10:34:06 2010 From: d at d-man.org (Darren Schreiber) Date: Wed, 6 Oct 2010 10:34:06 -0700 Subject: [Freeswitch-dev] ONE WEEK LEFT - Official FreeSWITCH Training in New York City Message-ID: <07C678A2-7B07-4798-971F-41A1ED0C4E5F@d-man.org> Hi folks, The Official FreeSWITCH Training course in New York is just one week away and is almost full. If you are interested in learning a ton of FreeSWITCH, taught by one of the authors of the FreeSWITCH Book, you should consider signing up. Code FREEVOIP is still valid for $400 off the training. You can register at http://www.voipkb.com/ . There is also a huge discount for registering two or more people together. The course is an in-depth dive into FreeSWITCH with completely different material then is in the book. We will cover: * Understanding configuration files and the default configuration * Call authentication and routing basics * Integration modules (mod_skypiax, mod_dingaling for Skype/GTalk/XMPP integration) * Understanding presence * Load balancing and high availability * FreeSWITCH Internals * How to debug and troubleshoot FreeSWITCH * Building Custom C Modules * Advanced Modules Please let me know if you have any questions. We're excited to continue offering this course and thank the FreeSWITCH team for their continued outstanding work. See you in New York! Thanks, Darren Schreiber Join us in October for FreeSWITCH Training! Visit www.voipkb.com for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101006/ed466413/attachment-0001.html From d at d-man.org Wed Oct 6 10:34:38 2010 From: d at d-man.org (Darren Schreiber) Date: Wed, 6 Oct 2010 10:34:38 -0700 Subject: [Freeswitch-dev] ONE WEEK LEFT - Official FreeSWITCH Training in New York City Message-ID: <24070A5A-1A8A-4C59-8D8C-D3F9647935EB@d-man.org> Hi folks, The Official FreeSWITCH Training course in New York is just one week away and is almost full. If you are interested in learning a ton of FreeSWITCH, taught by one of the authors of the FreeSWITCH Book, you should consider signing up. Code FREEVOIP is still valid for $400 off the training. You can register at http://www.voipkb.com/ . There is also a huge discount for registering two or more people together. The course is an in-depth dive into FreeSWITCH with completely different material then is in the book. We will cover: * Understanding configuration files and the default configuration * Call authentication and routing basics * Integration modules (mod_skypiax, mod_dingaling for Skype/GTalk/XMPP integration) * Understanding presence * Load balancing and high availability * FreeSWITCH Internals * How to debug and troubleshoot FreeSWITCH * Building Custom C Modules * Advanced Modules Please let me know if you have any questions. We're excited to continue offering this course and thank the FreeSWITCH team for their continued outstanding work. See you in New York! Thanks, Darren Schreiber Join us in October for FreeSWITCH Training! Visit www.voipkb.com for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101006/c16d22da/attachment.html From cbeeton at avaya.com Wed Oct 6 07:49:27 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 6 Oct 2010 10:49:27 -0400 Subject: [Freeswitch-dev] Intro Message-ID: Hello all, I am part of the Avaya SCS development team, which uses FreeSWITCH for conferencing and other media services. We continue to be committed to contributing code and fixes back to the FS project. I am currently trying to use SUBSCRIBE/NOTIFY for Dialog events (RFC4235) in order to monitor calls that FreeSWITCH is managing. I've run into some roadblocks and am now exploring in the code base, and I will post about that soon. Just wanted to make a quick intro before getting into the gory stuff. Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101006/575e9ced/attachment.html From msc at freeswitch.org Wed Oct 6 15:03:37 2010 From: msc at freeswitch.org (Michael Collins) Date: Wed, 6 Oct 2010 15:03:37 -0700 Subject: [Freeswitch-dev] Intro In-Reply-To: References: Message-ID: Excellent. This is the correct list for developer questions. Also, if you join #freeswitch-dev on irc.freenode.net you can talk to some of the guys in realtime. -MC On Wed, Oct 6, 2010 at 7:49 AM, Beeton, Carolyn (Carolyn) wrote: > Hello all, > > I am part of the Avaya SCS development team, which uses FreeSWITCH for > conferencing and other media services. We continue to be committed to > contributing code and fixes back to the FS project. I am currently trying > to use SUBSCRIBE/NOTIFY for Dialog events (RFC4235) in order to monitor > calls that FreeSWITCH is managing. I've run into some roadblocks and am now > exploring in the code base, and I will post about that soon. Just wanted to > make a quick intro before getting into the gory stuff. > > Carolyn > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101006/4d44f645/attachment.html From msc at freeswitch.org Fri Oct 8 10:44:46 2010 From: msc at freeswitch.org (Michael Collins) Date: Fri, 8 Oct 2010 10:44:46 -0700 Subject: [Freeswitch-dev] Get on IRC day!! Message-ID: Hey all, we need bodies in IRC! It's Friday, let's have a good group to answer questions and help all the newbies. -MC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101008/a37e7d8e/attachment.html From tculjaga at gmail.com Fri Oct 8 11:25:11 2010 From: tculjaga at gmail.com (Tihomir Culjaga) Date: Fri, 8 Oct 2010 20:25:11 +0200 Subject: [Freeswitch-dev] Get on IRC day!! In-Reply-To: References: Message-ID: On Fri, Oct 8, 2010 at 7:44 PM, Michael Collins wrote: > Hey all, we need bodies in IRC! It's Friday, let's have a good group to > answer questions and help all the newbies. > > -MC > > Firefox can't establish a connection to the server at irc.freenode.net. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101008/dfb141d0/attachment.html From cbeeton at avaya.com Fri Oct 8 12:24:07 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Fri, 8 Oct 2010 15:24:07 -0400 Subject: [Freeswitch-dev] Dialog events Message-ID: I have an application which needs to SUBSCRIBE for Dialog events. I have manage-presence turned on. I place a call to an extension which is configured in the FS dialplan and is answered by FS (for the moment, it is just playing music). If I now SUBSCRIBE for Dialog events for that extension, I get only the top-level element, not the details included in the per-dialog element (e.g. call id, remote display, etc) which are described in RFC4235. In the code, I see that the query in actual_sofia_presence_event_handler does a "join" on sip_registrations to pull out some of the dialog details. This means that extensions which do not register never get dialog details. In my case, sip_registrations and sip_presence databases are empty, but most of the info that should be in the element is stored in the sip_dialogs database. Why does the query need sip_registrations or sip_presence? When I simplify this query to remove the references to these databases, I get much closer to the data I need. Isn't all the data we need in the sip_dialogs database?. Dialog info should not require registration. I've noticed some other problems, such as: - to and from tags are not saved in sip_dialogs - call-id, local-tag, remote-tag are not included in the element - from_user is never used because from_id is never null (it is set to "" by switch_str_nil) - remote identity display is not included - remote target does not come from the dialog Contact I've made some changes and verified that a NOTIFY can be crafted which fully meets RFC4235 and allows my application to pick up this call (by sending an INVITE with REPLACES). The first step though is to understand the link to sip_registrations. Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101008/4eb0376d/attachment.html From anthony.minessale at gmail.com Fri Oct 8 12:44:53 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 8 Oct 2010 14:44:53 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: be aware that you can't simply change the code to do what you want. The presence code is very very battle scarred and designed to work a certain way. It may deserve to be cleaned up, but it can't be changed very easy. Its the messiest and my least favorite part of all the code. We tie in registrations because we have a feature to allow the monitoring of devices that do not support presence by virtue of registration and to support the bootstrapping of the presence of phones who are already idle when a subscriber comes online. The sip_dialogs table is not for the actual sip_dialogs, it's just for a few things we need to keep track of for SCA and other demanding presence protocols. I recommend you get some polycom phones configured for normal blf AND shared line broad soft style SCA, some dialog-info devices and some softphones such as x-lite, eyebeam or bria and register them to FreeSWITCH and learn how it works together. We can't touch one line of code in that file that disturbs the operation of any existing devices that we support. We did not implement all of the features in dialog-info, only the ones that any phone we have used seems to care about and we have had substantial bounties and contributions to get things working. On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) wrote: > I have an application which needs to SUBSCRIBE for Dialog events.? I have > manage-presence turned on.? I place a call to an extension which is > configured in the FS dialplan and is answered by FS (for the moment, it is > just playing music).? If I now SUBSCRIBE for Dialog events for that > extension, I get only the top-level element, not the details > included in the per-dialog element (e.g. call id, remote display, > etc) which are described in RFC4235. > > In the code, I see that the query in actual_sofia_presence_event_handler > does a "join" on sip_registrations to pull out some of the dialog details. > This means that extensions which do not register never get dialog details. > In my case, sip_registrations and sip_presence databases are empty, but most > of the info that should be in the element is stored in the > sip_dialogs database. > > Why does the query need sip_registrations or sip_presence?? When I simplify > this query to remove the references to these databases, I get much closer to > the data I need.? Isn't all the data we need in the sip_dialogs database?. > Dialog info should not require registration. > > I've noticed some other problems, such as: > - to and from tags are not saved in sip_dialogs > - call-id, local-tag, remote-tag are not included in the element > - from_user is never used because from_id is never null (it is set to "" by > switch_str_nil) > - remote identity display is not included > - remote target does not come from the dialog Contact > > I've made some changes and verified that a NOTIFY can be crafted which fully > meets RFC4235 and allows my application to pick up this call (by sending an > INVITE with REPLACES).? The first step though is to understand the link to > sip_registrations. > > Carolyn > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Fri Oct 8 13:11:56 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Fri, 8 Oct 2010 16:11:56 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > > be aware that you can't simply change the code to do what you want. > The presence code is very very battle scarred and designed to > work a certain way. > > It may deserve to be cleaned up, but it can't be changed very easy. > Its the messiest and my least favorite part of all the code. > > We tie in registrations because we have a feature to allow > the monitoring of devices that do not support presence by > virtue of registration and to support the bootstrapping of > the presence of phones who are already idle when a subscriber > comes online. OK, but does that mean that internal endpoints which are not registered should not get full Dialog events? Or does it mean that the FS extension itself should be considered one of these "not presence capable" devices, and an entry should be made for it in the registrations table? > > The sip_dialogs table is not for the actual sip_dialogs, it's > just for a few things we need to keep track of for SCA and > other demanding presence protocols. The dialog events described in RFC4235 need many of these same things. I added (experimentally, for my own edification, of course) a field for local and remote tag, as these are required for full RFC4235 and draft-anil-sipping-bla and draft-ietf-bliss-shared-appearances. > > I recommend you get some polycom phones configured for normal > blf AND shared line broad soft style SCA, some dialog-info > devices and some softphones such as x-lite, eyebeam or bria > and register them to FreeSWITCH and learn how it works together. > > We can't touch one line of code in that file that disturbs > the operation of any existing devices that we support. We > did not implement all of the features in dialog-info, only > the ones that any phone we have used seems to care about and > we have had substantial bounties and contributions to get > things working. > > So if it could be extended to support internal freeswitch endpoints, would it be accepted? Or is it completely off-limits? Given now that our application cares about all of the features in dialog-info. Carolyn > > > On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) > wrote: > > I have an application which needs to SUBSCRIBE for Dialog > events.? I > > have manage-presence turned on.? I place a call to an > extension which > > is configured in the FS dialplan and is answered by FS (for the > > moment, it is just playing music).? If I now SUBSCRIBE for Dialog > > events for that extension, I get only the top-level > > element, not the details included in the per-dialog > element > > (e.g. call id, remote display, > > etc) which are described in RFC4235. > > > > In the code, I see that the query in > > actual_sofia_presence_event_handler > > does a "join" on sip_registrations to pull out some of the > dialog details. > > This means that extensions which do not register never get > dialog details. > > In my case, sip_registrations and sip_presence databases are empty, > > but most of the info that should be in the element > is stored > > in the sip_dialogs database. > > > > Why does the query need sip_registrations or sip_presence?? When I > > simplify this query to remove the references to these > databases, I get > > much closer to the data I need.? Isn't all the data we need > in the sip_dialogs database?. > > Dialog info should not require registration. > > > > I've noticed some other problems, such as: > > - to and from tags are not saved in sip_dialogs > > - call-id, local-tag, remote-tag are not included in the > > element > > - from_user is never used because from_id is never null (it > is set to > > "" by > > switch_str_nil) > > - remote identity display is not included > > - remote target does not come from the dialog Contact > > > > I've made some changes and verified that a NOTIFY can be > crafted which > > fully meets RFC4235 and allows my application to pick up > this call (by > > sending an INVITE with REPLACES).? The first step though is to > > understand the link to sip_registrations. > > > > Carolyn > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Fri Oct 8 14:31:58 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 8 Oct 2010 16:31:58 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: anything can be accepted that keeps things working the way they already do work and more. we can probably add those other things to the dialog table as long as nothing breaks in the process. I am just trying to warn you that this is heavily depended-upon code by many and it's a critical change to manipulate it and changes should be discussed in detail. On Fri, Oct 8, 2010 at 3:11 PM, Beeton, Carolyn (Carolyn) wrote: >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> >> be aware that you can't simply change the code to do what you want. >> The presence code is very very battle scarred and designed to >> work a certain way. >> >> It may deserve to be cleaned up, but it can't be changed very easy. >> Its the messiest and my least favorite part of all the code. >> >> We tie in registrations because we have a feature to allow >> the monitoring of devices that do not support presence by >> virtue of registration and to support the bootstrapping of >> the presence of phones who are already idle when a subscriber >> comes online. > > OK, but does that mean that internal endpoints which are not registered should not get full Dialog events? ?Or does it mean that the FS extension itself should be considered one of these "not presence capable" devices, and an entry should be made for it in the registrations table? > >> >> The sip_dialogs table is not for the actual sip_dialogs, it's >> just for a few things we need to keep track of for SCA and >> other demanding presence protocols. > > The dialog events described in RFC4235 need many of these same things. ?I added (experimentally, for my own edification, of course) a field for local and remote tag, as these are required for full RFC4235 and draft-anil-sipping-bla and draft-ietf-bliss-shared-appearances. > >> >> I recommend you get some polycom phones configured for normal >> blf AND shared line broad soft style SCA, some dialog-info >> devices and some softphones such as x-lite, eyebeam or bria >> and register them to FreeSWITCH and learn how it works together. >> >> We can't touch one line of code in that file that disturbs >> the operation of any existing devices that we support. ?We >> did not implement all of the features in dialog-info, only >> the ones that any phone we have used seems to care about and >> we have had substantial bounties and contributions to get >> things working. >> >> > > So if it could be extended to support internal freeswitch endpoints, would it be accepted? ?Or is it completely off-limits? ?Given now that our application cares about all of the features in dialog-info. > > Carolyn > >> >> >> On Fri, Oct 8, 2010 at 2:24 PM, Beeton, Carolyn (Carolyn) >> wrote: >> > I have an application which needs to SUBSCRIBE for Dialog >> events.? I >> > have manage-presence turned on.? I place a call to an >> extension which >> > is configured in the FS dialplan and is answered by FS (for the >> > moment, it is just playing music).? If I now SUBSCRIBE for Dialog >> > events for that extension, I get only the top-level >> > element, not the details included in the per-dialog >> element >> > (e.g. call id, remote display, >> > etc) which are described in RFC4235. >> > >> > In the code, I see that the query in >> > actual_sofia_presence_event_handler >> > does a "join" on sip_registrations to pull out some of the >> dialog details. >> > This means that extensions which do not register never get >> dialog details. >> > In my case, sip_registrations and sip_presence databases are empty, >> > but most of the info that should be in the element >> is stored >> > in the sip_dialogs database. >> > >> > Why does the query need sip_registrations or sip_presence?? When I >> > simplify this query to remove the references to these >> databases, I get >> > much closer to the data I need.? Isn't all the data we need >> in the sip_dialogs database?. >> > Dialog info should not require registration. >> > >> > I've noticed some other problems, such as: >> > - to and from tags are not saved in sip_dialogs >> > - call-id, local-tag, remote-tag are not included in the >> > element >> > - from_user is never used because from_id is never null (it >> is set to >> > "" by >> > switch_str_nil) >> > - remote identity display is not included >> > - remote target does not come from the dialog Contact >> > >> > I've made some changes and verified that a NOTIFY can be >> crafted which >> > fully meets RFC4235 and allows my application to pick up >> this call (by >> > sending an INVITE with REPLACES).? The first step though is to >> > understand the link to sip_registrations. >> > >> > Carolyn >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From grw.freeswitch at gmail.com Fri Oct 1 08:02:14 2010 From: grw.freeswitch at gmail.com (Geovani Ricardo Wiedenhoft) Date: Fri, 1 Oct 2010 12:02:14 -0300 Subject: [Freeswitch-dev] Searching for a valid extension Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101001/f4eb6901/attachment.html From grw.freeswitch at gmail.com Tue Oct 5 12:14:53 2010 From: grw.freeswitch at gmail.com (Geovani Ricardo Wiedenhoft) Date: Tue, 5 Oct 2010 16:14:53 -0300 Subject: [Freeswitch-dev] Searching for a valid extension In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101005/2ef58e50/attachment-0001.html From grw.freeswitch at gmail.com Mon Oct 11 13:12:56 2010 From: grw.freeswitch at gmail.com (Geovani Ricardo Wiedenhoft) Date: Mon, 11 Oct 2010 17:12:56 -0300 Subject: [Freeswitch-dev] Searching for a valid extension. Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101011/1d46b58f/attachment-0001.html From anthony.minessale at gmail.com Mon Oct 11 13:44:47 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Mon, 11 Oct 2010 15:44:47 -0500 Subject: [Freeswitch-dev] Searching for a valid extension. In-Reply-To: References: Message-ID: We don't have a static monolithic dialplan like asterisk, there can be many dialplans or dynamic dialplans that reach out to external services. The proper way to implement overlap dialing on a per-protocol basis would be: 1) Separate your native channel from the FreeSWITCH channel so you can create a FreeSWITCH session and attach the native channel. 2) send the call to the configured dialplan and allow that dialplan module to work out it's own ambiguities and respond: SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28 3) when you see this cause accept more digits and try again until you get some other cause code. This is how it's done in sip by doing an entire new call each time you need to dial more digits. The other way which we do in FreeTDM is to define 2 regex, one for anything that is valid and one for anything that is invalid and consult this regex on each digit until you know one way or another. On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft wrote: > 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 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From msc at freeswitch.org Mon Oct 11 13:53:02 2010 From: msc at freeswitch.org (Michael Collins) Date: Mon, 11 Oct 2010 13:53:02 -0700 Subject: [Freeswitch-dev] Call For Assistance: Git Gurus Message-ID: If you are a Git guru and are in a position to help us with a few specific mini-projects we would be most appreciative. Right now the current need is to create an email notification system when new commits are made to git HEAD. If you are experienced in this area and can help us out then please email Ray and me offlist. Thanks, Michael msc at freeswitch.org intralanman at freeswitch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101011/f0761bde/attachment.html From cbeeton at avaya.com Tue Oct 12 07:15:43 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 12 Oct 2010 10:15:43 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: Most of my changes are a pretty straight-forward extension to add the call-id, local-tag and remote-tag into the element. But I am blocked by the sql query in actual_sofia_presence_event_handler which pulls out the rows to work on in the first place (in the SWITCH_EVENT_PRESENCE_PROBE case), because it uses the sip_registrations table as the "master" and does a left join on sip_dialogs and sip_presence to get more data. In my case, there is nothing in sip_registrations, so I get no matches to work on. I realize that changing this query (or any of this stuff) is a risky thing - at this point I am just feeling around to see what might be possible. So my main question right now is: - is it correct to build dialog event content primarily based on the sip_registrations table? Could the query be rejigged so that sip_dialogs is the master and sip_registrations is joined where there is a match? To me, this would seem to be correct, as dialog event contents should have little to do with registrations and should not be primarly driven by them. Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Friday, October 08, 2010 5:32 PM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events > > anything can be accepted that keeps things working the way > they already do work and more. > we can probably add those other things to the dialog table as > long as nothing breaks in the process. > > I am just trying to warn you that this is heavily > depended-upon code by many and it's a critical change to > manipulate it and changes should be discussed in detail. > From anthony.minessale at gmail.com Tue Oct 12 07:29:39 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 12 Oct 2010 09:29:39 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: The reason for this is because we don't care about any calls who are not registered to us. The sip_dialogs table are purely for in-call presence information of authenticated users. PRESENCE_PROBE is, in essence a query to see who is currently registered. Maybe if you describe your paradigm to me that does not involve any registrations, I can come up with a better answer. On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) wrote: > Most of my changes are a pretty straight-forward extension to add the call-id, local-tag and remote-tag into the element. ?But I am blocked by the sql query in actual_sofia_presence_event_handler which pulls out the rows to work on in the first place (in the SWITCH_EVENT_PRESENCE_PROBE case), because it uses the sip_registrations table as the "master" and does a left join on sip_dialogs and sip_presence to get more data. ?In my case, there is nothing in sip_registrations, so I get no matches to work on. ?I realize that changing this query (or any of this stuff) is a risky thing ?- at this point I am just feeling around to see what might be possible. > > So my main question right now is: > - is it correct to build dialog event content primarily based on the sip_registrations table? ?Could the query be rejigged so that sip_dialogs is the master and sip_registrations is joined where there is a match? To me, this would seem to be correct, as dialog event contents should have little to do with registrations and should not be primarly driven by them. > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Friday, October 08, 2010 5:32 PM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events >> >> anything can be accepted that keeps things working the way >> they already do work and more. >> we can probably add those other things to the dialog table as >> long as nothing breaks in the process. >> >> I am just trying to warn you that this is heavily >> depended-upon code by many and it's a critical change to >> manipulate it and changes should be discussed in detail. >> > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Tue Oct 12 08:09:42 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 12 Oct 2010 11:09:42 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: OK. I have configured the freeswitch dialplan to answer extension 44 and invoke the playback application: Now I want to be able to subscribe to 44@ to see what calls are being handled there (this is just a first step towards monitoring the calls that FS is handling for us). PRESENCE_PROBE does not sound like quite the right thing, then. But that is what is being triggered by a SUBSCRIBE(dialog) to that extension. From RFC4235: "The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved." Nothing in there about being registered or not. Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Tuesday, October 12, 2010 10:30 AM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events > > The reason for this is because we don't care about any calls > who are not registered to us. > The sip_dialogs table are purely for in-call presence > information of authenticated users. > > PRESENCE_PROBE is, in essence a query to see who is currently > registered. > > Maybe if you describe your paradigm to me that does not > involve any registrations, I can come up with a better answer. > > > On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) > wrote: > > Most of my changes are a pretty straight-forward extension > to add the call-id, local-tag and remote-tag into the > element. ?But I am blocked by the sql query in > actual_sofia_presence_event_handler which pulls out the rows > to work on in the first place (in the > SWITCH_EVENT_PRESENCE_PROBE case), because it uses the > sip_registrations table as the "master" and does a left join > on sip_dialogs and sip_presence to get more data. ?In my > case, there is nothing in sip_registrations, so I get no > matches to work on. ?I realize that changing this query (or > any of this stuff) is a risky thing ?- at this point I am > just feeling around to see what might be possible. > > > > So my main question right now is: > > - is it correct to build dialog event content primarily > based on the sip_registrations table? ?Could the query be > rejigged so that sip_dialogs is the master and > sip_registrations is joined where there is a match? To me, > this would seem to be correct, as dialog event contents > should have little to do with registrations and should not be > primarly driven by them. > > > > Carolyn > > > >> -----Original Message----- > >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of > >> Anthony Minessale > >> Sent: Friday, October 08, 2010 5:32 PM > >> To: freeswitch-dev at lists.freeswitch.org > >> Subject: Re: [Freeswitch-dev] Dialog events > >> > >> anything can be accepted that keeps things working the way they > >> already do work and more. > >> we can probably add those other things to the dialog table > as long as > >> nothing breaks in the process. > >> > >> I am just trying to warn you that this is heavily > depended-upon code > >> by many and it's a critical change to manipulate it and changes > >> should be discussed in detail. > >> > > > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Tue Oct 12 08:27:43 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 12 Oct 2010 10:27:43 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: Try this: change $${domain} to some other value if you have a manually configured domain. if you don't set presence_id, you will never see any presence messages for that call. Setting presence id is critical to get your call to broadcast presence events. The reason we care about registered phones is when you subscribe to an extension, it's assumed to represent a phone and the only way to really know what state a phone is in, is to check if it's involved in a call or is registered, anything else means you have no idea and could not report proper presence. The sip_dialogs table is not part of the dialog-info stuff so RFC quotes would not be appropriate in this case. This table is just a toll FS uses in many instances to track extra info about a sip call for various features including sometimes the dialog-info events. On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) wrote: > OK. ?I have configured the freeswitch dialplan to answer extension 44 and invoke the playback application: > > ? > ? ? > ? ? ? > ? ? ? > ? ? ? > ? ? > ? > > Now I want to be able to subscribe to 44@ to see what calls are being handled there (this is just a first step towards monitoring the calls that FS is handling for us). > > PRESENCE_PROBE does not sound like quite the right thing, then. ?But that is what is being triggered by a SUBSCRIBE(dialog) to that extension. ?>From RFC4235: > > "The dialog package allows users to subscribe to another > ? user and to receive notification of the changes in state of INVITE- > ? initiated dialog usages in which the subscribed-to user is involved." > > Nothing in there about being registered or not. > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Tuesday, October 12, 2010 10:30 AM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events >> >> The reason for this is because we don't care about any calls >> who are not registered to us. >> The sip_dialogs table are purely for in-call presence >> information of authenticated users. >> >> PRESENCE_PROBE is, in essence a query to see who is currently >> registered. >> >> Maybe if you describe your paradigm to me that does not >> involve any registrations, I can come up with a better answer. >> >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) >> wrote: >> > Most of my changes are a pretty straight-forward extension >> to add the call-id, local-tag and remote-tag into the >> element. ?But I am blocked by the sql query in >> actual_sofia_presence_event_handler which pulls out the rows >> to work on in the first place (in the >> SWITCH_EVENT_PRESENCE_PROBE case), because it uses the >> sip_registrations table as the "master" and does a left join >> on sip_dialogs and sip_presence to get more data. ?In my >> case, there is nothing in sip_registrations, so I get no >> matches to work on. ?I realize that changing this query (or >> any of this stuff) is a risky thing ?- at this point I am >> just feeling around to see what might be possible. >> > >> > So my main question right now is: >> > - is it correct to build dialog event content primarily >> based on the sip_registrations table? ?Could the query be >> rejigged so that sip_dialogs is the master and >> sip_registrations is joined where there is a match? To me, >> this would seem to be correct, as dialog event contents >> should have little to do with registrations and should not be >> primarly driven by them. >> > >> > Carolyn >> > >> >> -----Original Message----- >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of >> >> Anthony Minessale >> >> Sent: Friday, October 08, 2010 5:32 PM >> >> To: freeswitch-dev at lists.freeswitch.org >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> anything can be accepted that keeps things working the way they >> >> already do work and more. >> >> we can probably add those other things to the dialog table >> as long as >> >> nothing breaks in the process. >> >> >> >> I am just trying to warn you that this is heavily >> depended-upon code >> >> by many and it's a critical change to manipulate it and changes >> >> should be discussed in detail. >> >> >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Tue Oct 12 10:10:35 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 12 Oct 2010 13:10:35 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: I am still only getting the partial dialog-info element, not the full dialog contents that I expect when I subscribe for dialog events. I get this: But not the per-dialog element containing details about active dialogs, e.g.: confirmed sip:44 at 10.10.10.158 sip:201 at 10.10.10.158 This is what I am looking for, but the details are blocked because the query looks in sip_registrations first and there are none. As you say below, "the only way to really know what state a phone is in, is to check if it's involved in a call or is registered" - but the query is doing effectively "AND is registered" Setting presence_id did not make a difference that I could see. Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Tuesday, October 12, 2010 11:28 AM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events > > Try this: > > > > > > > > > > > change $${domain} to some other value if you have a manually > configured domain. > > if you don't set presence_id, you will never see any presence > messages for that call. > > Setting presence id is critical to get your call to broadcast > presence events. > The reason we care about registered phones is when you > subscribe to an extension, it's assumed to represent a phone > and the only way to really know what state a phone is in, is > to check if it's involved in a call or is registered, > anything else means you have no idea and could not report > proper presence. > > The sip_dialogs table is not part of the dialog-info stuff so > RFC quotes would not be appropriate in this case. This table > is just a toll FS uses in many instances to track extra info > about a sip call for various features including sometimes the > dialog-info events. > > > On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) > wrote: > > OK. ?I have configured the freeswitch dialplan to answer > extension 44 and invoke the playback application: > > > > ? > > ? ? > > ? ? ? > > ? ? ? > > ? ? ? > > ? ? > > ? > > > > Now I want to be able to subscribe to 44@ to > see what calls are being handled there (this is just a first > step towards monitoring the calls that FS is handling for us). > > > > PRESENCE_PROBE does not sound like quite the right thing, > then. ?But that is what is being triggered by a > SUBSCRIBE(dialog) to that extension. ?>From RFC4235: > > > > "The dialog package allows users to subscribe to another > > ? user and to receive notification of the changes in state > of INVITE- > > ? initiated dialog usages in which the subscribed-to user > is involved." > > > > Nothing in there about being registered or not. > > > > Carolyn > > > >> -----Original Message----- > >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of > >> Anthony Minessale > >> Sent: Tuesday, October 12, 2010 10:30 AM > >> To: freeswitch-dev at lists.freeswitch.org > >> Subject: Re: [Freeswitch-dev] Dialog events > >> > >> The reason for this is because we don't care about any > calls who are > >> not registered to us. > >> The sip_dialogs table are purely for in-call presence > information of > >> authenticated users. > >> > >> PRESENCE_PROBE is, in essence a query to see who is currently > >> registered. > >> > >> Maybe if you describe your paradigm to me that does not > involve any > >> registrations, I can come up with a better answer. > >> > >> > >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) > >> wrote: > >> > Most of my changes are a pretty straight-forward extension > >> to add the call-id, local-tag and remote-tag into the > >> element. ?But I am blocked by the sql query in > >> actual_sofia_presence_event_handler which pulls out the > rows to work > >> on in the first place (in the SWITCH_EVENT_PRESENCE_PROBE case), > >> because it uses the sip_registrations table as the > "master" and does > >> a left join on sip_dialogs and sip_presence to get more > data. ?In my > >> case, there is nothing in sip_registrations, so I get no > matches to > >> work on. ?I realize that changing this query (or any of > this stuff) > >> is a risky thing ?- at this point I am just feeling around to see > >> what might be possible. > >> > > >> > So my main question right now is: > >> > - is it correct to build dialog event content primarily > >> based on the sip_registrations table? ?Could the query be > rejigged so > >> that sip_dialogs is the master and sip_registrations is > joined where > >> there is a match? To me, this would seem to be correct, as dialog > >> event contents should have little to do with registrations > and should > >> not be primarly driven by them. > >> > > >> > Carolyn > >> > > >> >> -----Original Message----- > >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of > >> >> Anthony Minessale > >> >> Sent: Friday, October 08, 2010 5:32 PM > >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> > >> >> anything can be accepted that keeps things working the way they > >> >> already do work and more. > >> >> we can probably add those other things to the dialog table > >> as long as > >> >> nothing breaks in the process. > >> >> > >> >> I am just trying to warn you that this is heavily > >> depended-upon code > >> >> by many and it's a critical change to manipulate it and changes > >> >> should be discussed in detail. > >> >> > >> > > >> > _______________________________________________ > >> > FreeSWITCH-dev mailing list > >> > FreeSWITCH-dev at lists.freeswitch.org > >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> > http://www.freeswitch.org > >> > > >> > >> > >> > >> -- > >> Anthony Minessale II > >> > >> FreeSWITCH http://www.freeswitch.org/ ClueCon > http://www.cluecon.com/ > >> Twitter: http://twitter.com/FreeSWITCH_wire > >> > >> AIM: anthm > >> MSN:anthony_minessale at hotmail.com > >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> IRC: irc.freenode.net #freeswitch > >> > >> FreeSWITCH Developer Conference > >> sip:888 at conference.freeswitch.org > >> googletalk:conf+888 at conference.freeswitch.org > >> pstn:+19193869900 > >> > >> _______________________________________________ > >> FreeSWITCH-dev mailing list > >> FreeSWITCH-dev at lists.freeswitch.org > >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> http://www.freeswitch.org > >> > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Tue Oct 12 10:46:43 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 12 Oct 2010 12:46:43 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: The presence probe statement you are following is executed when a subscription happens to get the first event. its a way to make all entities fire a presence event. The real presence sql stmt is the one at 698 which does not involve registration and is triggered by presence_in events which will be fired when you set the presence_id. If you don't have the domains the same and the presence_hosts field set to cover the variants you may get nothing. The only real problem I can imagine you are having is getting that first required notify after a subscribe, instead you would not get it until you placed a call. It would require just blindly accepting subscriptions to everything to do what you want. have you enabled debug-presence set to 10 in conf/autoload_configs/sofia.conf.xml ? This will show the SQL STMTS ad they are being run and could help you to see what you are missing. On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn) wrote: > I am still only getting the partial dialog-info element, not the full dialog contents that I expect when I subscribe for dialog events. ?I get this: > > > > > But not the per-dialog element containing details about active dialogs, e.g.: > > > > confirmed > > sip:44 at 10.10.10.158 > > > > > > sip:201 at 10.10.10.158 > > > > > > This is what I am looking for, but the details are blocked because the query looks in sip_registrations first and there are none. ?As you say below, "the only way to really know what state a phone is in, is to check if it's involved in a call or is registered" - but the query is doing effectively "AND is registered" > > Setting presence_id did not make a difference that I could see. > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Tuesday, October 12, 2010 11:28 AM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events >> >> Try this: >> >> ? >> ? ? >> ? ? ? >> ? ? ? >> ? ? ? >> ? ? ? >> ? ? >> ? >> >> change $${domain} to some other value if you have a manually >> configured domain. >> >> if you don't set presence_id, you will never see any presence >> messages for that call. >> >> Setting presence id is critical to get your call to broadcast >> presence events. >> The reason we care about registered phones is when you >> subscribe to an extension, it's assumed to represent a phone >> and the only way to really know what state a phone is in, is >> to check if it's involved in a call or is registered, >> anything else means you have no idea and could not report >> proper presence. >> >> The sip_dialogs table is not part of the dialog-info stuff so >> RFC quotes would not be appropriate in this case. ?This table >> is just a toll FS uses in many instances to track extra info >> about a sip call for various features including sometimes the >> dialog-info events. >> >> >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) >> wrote: >> > OK. ?I have configured the freeswitch dialplan to answer >> extension 44 and invoke the playback application: >> > >> > ? >> > ? ? >> > ? ? ? >> > ? ? ? >> > ? ? ? >> > ? ? >> > ? >> > >> > Now I want to be able to subscribe to 44@ to >> see what calls are being handled there (this is just a first >> step towards monitoring the calls that FS is handling for us). >> > >> > PRESENCE_PROBE does not sound like quite the right thing, >> then. ?But that is what is being triggered by a >> SUBSCRIBE(dialog) to that extension. ?>From RFC4235: >> > >> > "The dialog package allows users to subscribe to another >> > ? user and to receive notification of the changes in state >> of INVITE- >> > ? initiated dialog usages in which the subscribed-to user >> is involved." >> > >> > Nothing in there about being registered or not. >> > >> > Carolyn >> > >> >> -----Original Message----- >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of >> >> Anthony Minessale >> >> Sent: Tuesday, October 12, 2010 10:30 AM >> >> To: freeswitch-dev at lists.freeswitch.org >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> The reason for this is because we don't care about any >> calls who are >> >> not registered to us. >> >> The sip_dialogs table are purely for in-call presence >> information of >> >> authenticated users. >> >> >> >> PRESENCE_PROBE is, in essence a query to see who is currently >> >> registered. >> >> >> >> Maybe if you describe your paradigm to me that does not >> involve any >> >> registrations, I can come up with a better answer. >> >> >> >> >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) >> >> wrote: >> >> > Most of my changes are a pretty straight-forward extension >> >> to add the call-id, local-tag and remote-tag into the >> >> element. ?But I am blocked by the sql query in >> >> actual_sofia_presence_event_handler which pulls out the >> rows to work >> >> on in the first place (in the SWITCH_EVENT_PRESENCE_PROBE case), >> >> because it uses the sip_registrations table as the >> "master" and does >> >> a left join on sip_dialogs and sip_presence to get more >> data. ?In my >> >> case, there is nothing in sip_registrations, so I get no >> matches to >> >> work on. ?I realize that changing this query (or any of >> this stuff) >> >> is a risky thing ?- at this point I am just feeling around to see >> >> what might be possible. >> >> > >> >> > So my main question right now is: >> >> > - is it correct to build dialog event content primarily >> >> based on the sip_registrations table? ?Could the query be >> rejigged so >> >> that sip_dialogs is the master and sip_registrations is >> joined where >> >> there is a match? To me, this would seem to be correct, as dialog >> >> event contents should have little to do with registrations >> and should >> >> not be primarly driven by them. >> >> > >> >> > Carolyn >> >> > >> >> >> -----Original Message----- >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of >> >> >> Anthony Minessale >> >> >> Sent: Friday, October 08, 2010 5:32 PM >> >> >> To: freeswitch-dev at lists.freeswitch.org >> >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> >> >> anything can be accepted that keeps things working the way they >> >> >> already do work and more. >> >> >> we can probably add those other things to the dialog table >> >> as long as >> >> >> nothing breaks in the process. >> >> >> >> >> >> I am just trying to warn you that this is heavily >> >> depended-upon code >> >> >> by many and it's a critical change to manipulate it and changes >> >> >> should be discussed in detail. >> >> >> >> >> > >> >> > _______________________________________________ >> >> > FreeSWITCH-dev mailing list >> >> > FreeSWITCH-dev at lists.freeswitch.org >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> > >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> v >> >> > http://www.freeswitch.org >> >> > >> >> >> >> >> >> >> >> -- >> >> Anthony Minessale II >> >> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon >> http://www.cluecon.com/ >> >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> >> >> AIM: anthm >> >> MSN:anthony_minessale at hotmail.com >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> >> IRC: irc.freenode.net #freeswitch >> >> >> >> FreeSWITCH Developer Conference >> >> sip:888 at conference.freeswitch.org >> >> googletalk:conf+888 at conference.freeswitch.org >> >> pstn:+19193869900 >> >> >> >> _______________________________________________ >> >> FreeSWITCH-dev mailing list >> >> FreeSWITCH-dev at lists.freeswitch.org >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> v >> >> http://www.freeswitch.org >> >> >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Tue Oct 12 11:05:54 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 12 Oct 2010 14:05:54 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: I have enabled at least some of the debug. I will check to see if it is at level 10. Our application SUBECRIBEs for dialog events only when it is interested in them, with a very short timeout (ideally 0, but this does not work for some endpoints). We expect a NOTIFY back giving the current status. We don't want status events continually, just a single update when we ask for it. It seems like the code is very close to supporting this. Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Tuesday, October 12, 2010 1:47 PM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events > > The presence probe statement you are following is executed > when a subscription happens to get the first event. its a > way to make all entities fire a presence event. > > The real presence sql stmt is the one at 698 which does not > involve registration and is triggered by presence_in events > which will be fired when you set the presence_id. If you > don't have the domains the same and the presence_hosts field > set to cover the variants you may get nothing. > > The only real problem I can imagine you are having is getting > that first required notify after a subscribe, instead you > would not get it until you placed a call. It would require > just blindly accepting subscriptions to everything to do what > you want. > > have you enabled debug-presence set to 10 in > conf/autoload_configs/sofia.conf.xml ? > > This will show the SQL STMTS ad they are being run and could > help you to see what you are missing. > > > > > On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn) > wrote: > > I am still only getting the partial dialog-info element, > not the full dialog contents that I expect when I subscribe > for dialog events. ?I get this: > > > > > version=\"1\" state=\"partial\" entity=\"sip:44 at cbeeton.com\"> > > > > > > But not the per-dialog element containing details about > active dialogs, e.g.: > > > > > version=\"1\" state=\"full\" entity=\"sip:44 at cbeeton.com\"> > id=\"d3d433ce-2324c33e at 10.10.10.116\" > > call-id=\"d3d433ce-2324c33e at 10.10.10.116\" > local-tag=\"KQcQB9v3rmgpp\" > > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> > > confirmed > display=\"44\">sip:44 at 10.10.10.158 > > > > > > display=\"201-116\">sip:201 at 10.10.10.158 > > > > > > > > > > > > This is what I am looking for, but the details are blocked > because the query looks in sip_registrations first and there > are none. ?As you say below, "the only way to really know > what state a phone is in, is to check if it's involved in a > call or is registered" - but the query is doing effectively > "AND is registered" > > > > Setting presence_id did not make a difference that I could see. > > > > Carolyn > > > >> -----Original Message----- > >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of > >> Anthony Minessale > >> Sent: Tuesday, October 12, 2010 11:28 AM > >> To: freeswitch-dev at lists.freeswitch.org > >> Subject: Re: [Freeswitch-dev] Dialog events > >> > >> Try this: > >> > >> ? > >> ? ? > >> ? ? ? > >> ? ? ? > >> ? ? ? > >> ? ? ? > >> ? ? > >> ? > >> > >> change $${domain} to some other value if you have a manually > >> configured domain. > >> > >> if you don't set presence_id, you will never see any presence > >> messages for that call. > >> > >> Setting presence id is critical to get your call to broadcast > >> presence events. > >> The reason we care about registered phones is when you > subscribe to > >> an extension, it's assumed to represent a phone and the > only way to > >> really know what state a phone is in, is to check if it's > involved in > >> a call or is registered, anything else means you have no idea and > >> could not report proper presence. > >> > >> The sip_dialogs table is not part of the dialog-info stuff so RFC > >> quotes would not be appropriate in this case. ?This table > is just a > >> toll FS uses in many instances to track extra info about a > sip call > >> for various features including sometimes the dialog-info events. > >> > >> > >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) > >> wrote: > >> > OK. ?I have configured the freeswitch dialplan to answer > >> extension 44 and invoke the playback application: > >> > > >> > ? > >> > ? ? > >> > ? ? ? > >> > ? ? ? > >> > ? ? ? > >> > ? ? > >> > ? > >> > > >> > Now I want to be able to subscribe to 44@ to > >> see what calls are being handled there (this is just a first step > >> towards monitoring the calls that FS is handling for us). > >> > > >> > PRESENCE_PROBE does not sound like quite the right thing, > >> then. ?But that is what is being triggered by a > >> SUBSCRIBE(dialog) to that extension. ?>From RFC4235: > >> > > >> > "The dialog package allows users to subscribe to another > >> > ? user and to receive notification of the changes in state > >> of INVITE- > >> > ? initiated dialog usages in which the subscribed-to user > >> is involved." > >> > > >> > Nothing in there about being registered or not. > >> > > >> > Carolyn > >> > > >> >> -----Original Message----- > >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of > >> >> Anthony Minessale > >> >> Sent: Tuesday, October 12, 2010 10:30 AM > >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> > >> >> The reason for this is because we don't care about any > >> calls who are > >> >> not registered to us. > >> >> The sip_dialogs table are purely for in-call presence > >> information of > >> >> authenticated users. > >> >> > >> >> PRESENCE_PROBE is, in essence a query to see who is currently > >> >> registered. > >> >> > >> >> Maybe if you describe your paradigm to me that does not > >> involve any > >> >> registrations, I can come up with a better answer. > >> >> > >> >> > >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) > >> >> wrote: > >> >> > Most of my changes are a pretty straight-forward extension > >> >> to add the call-id, local-tag and remote-tag into the > >> >> element. ?But I am blocked by the sql query in > >> >> actual_sofia_presence_event_handler which pulls out the > >> rows to work > >> >> on in the first place (in the > SWITCH_EVENT_PRESENCE_PROBE case), > >> >> because it uses the sip_registrations table as the > >> "master" and does > >> >> a left join on sip_dialogs and sip_presence to get more > >> data. ?In my > >> >> case, there is nothing in sip_registrations, so I get no > >> matches to > >> >> work on. ?I realize that changing this query (or any of > >> this stuff) > >> >> is a risky thing ?- at this point I am just feeling > around to see > >> >> what might be possible. > >> >> > > >> >> > So my main question right now is: > >> >> > - is it correct to build dialog event content primarily > >> >> based on the sip_registrations table? ?Could the query be > >> rejigged so > >> >> that sip_dialogs is the master and sip_registrations is > >> joined where > >> >> there is a match? To me, this would seem to be correct, > as dialog > >> >> event contents should have little to do with registrations > >> and should > >> >> not be primarly driven by them. > >> >> > > >> >> > Carolyn > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > >> Behalf Of > >> >> >> Anthony Minessale > >> >> >> Sent: Friday, October 08, 2010 5:32 PM > >> >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> >> > >> >> >> anything can be accepted that keeps things working > the way they > >> >> >> already do work and more. > >> >> >> we can probably add those other things to the dialog table > >> >> as long as > >> >> >> nothing breaks in the process. > >> >> >> > >> >> >> I am just trying to warn you that this is heavily > >> >> depended-upon code > >> >> >> by many and it's a critical change to manipulate it > and changes > >> >> >> should be discussed in detail. > >> >> >> > >> >> > > >> >> > _______________________________________________ > >> >> > FreeSWITCH-dev mailing list > >> >> > FreeSWITCH-dev at lists.freeswitch.org > >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> > > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> v > >> >> > http://www.freeswitch.org > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Anthony Minessale II > >> >> > >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon > >> http://www.cluecon.com/ > >> >> Twitter: http://twitter.com/FreeSWITCH_wire > >> >> > >> >> AIM: anthm > >> >> MSN:anthony_minessale at hotmail.com > >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> >> IRC: irc.freenode.net #freeswitch > >> >> > >> >> FreeSWITCH Developer Conference > >> >> sip:888 at conference.freeswitch.org > >> >> googletalk:conf+888 at conference.freeswitch.org > >> >> pstn:+19193869900 > >> >> > >> >> _______________________________________________ > >> >> FreeSWITCH-dev mailing list > >> >> FreeSWITCH-dev at lists.freeswitch.org > >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> v > >> >> http://www.freeswitch.org > >> >> > >> > _______________________________________________ > >> > FreeSWITCH-dev mailing list > >> > FreeSWITCH-dev at lists.freeswitch.org > >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> > http://www.freeswitch.org > >> > > >> > >> > >> > >> -- > >> Anthony Minessale II > >> > >> FreeSWITCH http://www.freeswitch.org/ ClueCon > http://www.cluecon.com/ > >> Twitter: http://twitter.com/FreeSWITCH_wire > >> > >> AIM: anthm > >> MSN:anthony_minessale at hotmail.com > >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> IRC: irc.freenode.net #freeswitch > >> > >> FreeSWITCH Developer Conference > >> sip:888 at conference.freeswitch.org > >> googletalk:conf+888 at conference.freeswitch.org > >> pstn:+19193869900 > >> > >> _______________________________________________ > >> FreeSWITCH-dev mailing list > >> FreeSWITCH-dev at lists.freeswitch.org > >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> http://www.freeswitch.org > >> > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Tue Oct 12 11:28:06 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 12 Oct 2010 13:28:06 -0500 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: in this case you could possibly branch off with a 2nd sql stmt when so configured in the presence_probe handler to do exactly what you want and select all the same columns On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn) wrote: > I have enabled at least some of the debug. ?I will check to see if it is at level 10. > > Our application SUBECRIBEs for dialog events only when it is interested in them, with a very short timeout (ideally 0, but this does not work for some endpoints). ?We expect a NOTIFY back giving the current status. ?We don't want status events continually, just a single update when we ask for it. ?It seems like the code is very close to supporting this. > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Tuesday, October 12, 2010 1:47 PM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events >> >> The presence probe statement you are following is executed >> when a subscription happens to get the first event. ?its a >> way to make all entities fire a presence event. >> >> The real presence sql stmt is the one at 698 which does not >> involve registration and is triggered by presence_in events >> which will be fired when you set the presence_id. ?If you >> don't have the domains the same and the presence_hosts field >> set to cover the variants you may get nothing. >> >> The only real problem I can imagine you are having is getting >> that first required notify after a subscribe, instead you >> would not get it until you placed a call. ?It would require >> just blindly accepting subscriptions to everything to do what >> you want. >> >> have you enabled debug-presence set to 10 in >> conf/autoload_configs/sofia.conf.xml ? >> >> This will show the SQL STMTS ad they are being run and could >> help you to see what you are missing. >> >> >> >> >> On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn) >> wrote: >> > I am still only getting the partial dialog-info element, >> not the full dialog contents that I expect when I subscribe >> for dialog events. ?I get this: >> > >> > > > version=\"1\" state=\"partial\" entity=\"sip:44 at cbeeton.com\"> >> > >> > >> > But not the per-dialog element containing details about >> active dialogs, e.g.: >> > >> > > > version=\"1\" state=\"full\" entity=\"sip:44 at cbeeton.com\"> > > id=\"d3d433ce-2324c33e at 10.10.10.116\" >> > call-id=\"d3d433ce-2324c33e at 10.10.10.116\" >> local-tag=\"KQcQB9v3rmgpp\" >> > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> >> > confirmed > > display=\"44\">sip:44 at 10.10.10.158 >> > >> > >> > > display=\"201-116\">sip:201 at 10.10.10.158 >> > >> > >> > >> > >> > >> > This is what I am looking for, but the details are blocked >> because the query looks in sip_registrations first and there >> are none. ?As you say below, "the only way to really know >> what state a phone is in, is to check if it's involved in a >> call or is registered" - but the query is doing effectively >> "AND is registered" >> > >> > Setting presence_id did not make a difference that I could see. >> > >> > Carolyn >> > >> >> -----Original Message----- >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of >> >> Anthony Minessale >> >> Sent: Tuesday, October 12, 2010 11:28 AM >> >> To: freeswitch-dev at lists.freeswitch.org >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> Try this: >> >> >> >> ? >> >> ? ? >> >> ? ? ? >> >> ? ? ? >> >> ? ? ? >> >> ? ? ? >> >> ? ? >> >> ? >> >> >> >> change $${domain} to some other value if you have a manually >> >> configured domain. >> >> >> >> if you don't set presence_id, you will never see any presence >> >> messages for that call. >> >> >> >> Setting presence id is critical to get your call to broadcast >> >> presence events. >> >> The reason we care about registered phones is when you >> subscribe to >> >> an extension, it's assumed to represent a phone and the >> only way to >> >> really know what state a phone is in, is to check if it's >> involved in >> >> a call or is registered, anything else means you have no idea and >> >> could not report proper presence. >> >> >> >> The sip_dialogs table is not part of the dialog-info stuff so RFC >> >> quotes would not be appropriate in this case. ?This table >> is just a >> >> toll FS uses in many instances to track extra info about a >> sip call >> >> for various features including sometimes the dialog-info events. >> >> >> >> >> >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) >> >> wrote: >> >> > OK. ?I have configured the freeswitch dialplan to answer >> >> extension 44 and invoke the playback application: >> >> > >> >> > ? >> >> > ? ? >> >> > ? ? ? >> >> > ? ? ? >> >> > ? ? ? >> >> > ? ? >> >> > ? >> >> > >> >> > Now I want to be able to subscribe to 44@ to >> >> see what calls are being handled there (this is just a first step >> >> towards monitoring the calls that FS is handling for us). >> >> > >> >> > PRESENCE_PROBE does not sound like quite the right thing, >> >> then. ?But that is what is being triggered by a >> >> SUBSCRIBE(dialog) to that extension. ?>From RFC4235: >> >> > >> >> > "The dialog package allows users to subscribe to another >> >> > ? user and to receive notification of the changes in state >> >> of INVITE- >> >> > ? initiated dialog usages in which the subscribed-to user >> >> is involved." >> >> > >> >> > Nothing in there about being registered or not. >> >> > >> >> > Carolyn >> >> > >> >> >> -----Original Message----- >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of >> >> >> Anthony Minessale >> >> >> Sent: Tuesday, October 12, 2010 10:30 AM >> >> >> To: freeswitch-dev at lists.freeswitch.org >> >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> >> >> The reason for this is because we don't care about any >> >> calls who are >> >> >> not registered to us. >> >> >> The sip_dialogs table are purely for in-call presence >> >> information of >> >> >> authenticated users. >> >> >> >> >> >> PRESENCE_PROBE is, in essence a query to see who is currently >> >> >> registered. >> >> >> >> >> >> Maybe if you describe your paradigm to me that does not >> >> involve any >> >> >> registrations, I can come up with a better answer. >> >> >> >> >> >> >> >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) >> >> >> wrote: >> >> >> > Most of my changes are a pretty straight-forward extension >> >> >> to add the call-id, local-tag and remote-tag into the >> >> >> element. ?But I am blocked by the sql query in >> >> >> actual_sofia_presence_event_handler which pulls out the >> >> rows to work >> >> >> on in the first place (in the >> SWITCH_EVENT_PRESENCE_PROBE case), >> >> >> because it uses the sip_registrations table as the >> >> "master" and does >> >> >> a left join on sip_dialogs and sip_presence to get more >> >> data. ?In my >> >> >> case, there is nothing in sip_registrations, so I get no >> >> matches to >> >> >> work on. ?I realize that changing this query (or any of >> >> this stuff) >> >> >> is a risky thing ?- at this point I am just feeling >> around to see >> >> >> what might be possible. >> >> >> > >> >> >> > So my main question right now is: >> >> >> > - is it correct to build dialog event content primarily >> >> >> based on the sip_registrations table? ?Could the query be >> >> rejigged so >> >> >> that sip_dialogs is the master and sip_registrations is >> >> joined where >> >> >> there is a match? To me, this would seem to be correct, >> as dialog >> >> >> event contents should have little to do with registrations >> >> and should >> >> >> not be primarly driven by them. >> >> >> > >> >> >> > Carolyn >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org >> >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> >> Behalf Of >> >> >> >> Anthony Minessale >> >> >> >> Sent: Friday, October 08, 2010 5:32 PM >> >> >> >> To: freeswitch-dev at lists.freeswitch.org >> >> >> >> Subject: Re: [Freeswitch-dev] Dialog events >> >> >> >> >> >> >> >> anything can be accepted that keeps things working >> the way they >> >> >> >> already do work and more. >> >> >> >> we can probably add those other things to the dialog table >> >> >> as long as >> >> >> >> nothing breaks in the process. >> >> >> >> >> >> >> >> I am just trying to warn you that this is heavily >> >> >> depended-upon code >> >> >> >> by many and it's a critical change to manipulate it >> and changes >> >> >> >> should be discussed in detail. >> >> >> >> >> >> >> > >> >> >> > _______________________________________________ >> >> >> > FreeSWITCH-dev mailing list >> >> >> > FreeSWITCH-dev at lists.freeswitch.org >> >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> >> > >> >> >> >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> >> v >> >> >> > http://www.freeswitch.org >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Anthony Minessale II >> >> >> >> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon >> >> http://www.cluecon.com/ >> >> >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> >> >> >> >> AIM: anthm >> >> >> MSN:anthony_minessale at hotmail.com >> >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> >> >> IRC: irc.freenode.net #freeswitch >> >> >> >> >> >> FreeSWITCH Developer Conference >> >> >> sip:888 at conference.freeswitch.org >> >> >> googletalk:conf+888 at conference.freeswitch.org >> >> >> pstn:+19193869900 >> >> >> >> >> >> _______________________________________________ >> >> >> FreeSWITCH-dev mailing list >> >> >> FreeSWITCH-dev at lists.freeswitch.org >> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> >> >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> >> v >> >> >> http://www.freeswitch.org >> >> >> >> >> > _______________________________________________ >> >> > FreeSWITCH-dev mailing list >> >> > FreeSWITCH-dev at lists.freeswitch.org >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> > >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> v >> >> > http://www.freeswitch.org >> >> > >> >> >> >> >> >> >> >> -- >> >> Anthony Minessale II >> >> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon >> http://www.cluecon.com/ >> >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> >> >> AIM: anthm >> >> MSN:anthony_minessale at hotmail.com >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> >> IRC: irc.freenode.net #freeswitch >> >> >> >> FreeSWITCH Developer Conference >> >> sip:888 at conference.freeswitch.org >> >> googletalk:conf+888 at conference.freeswitch.org >> >> pstn:+19193869900 >> >> >> >> _______________________________________________ >> >> FreeSWITCH-dev mailing list >> >> FreeSWITCH-dev at lists.freeswitch.org >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> >> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de >> >> v >> >> http://www.freeswitch.org >> >> >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From math.parent at gmail.com Tue Oct 12 11:40:15 2010 From: math.parent at gmail.com (Mathieu Parent) Date: Tue, 12 Oct 2010 20:40:15 +0200 Subject: [Freeswitch-dev] Searching for a valid extension In-Reply-To: References: Message-ID: Hello, 2010/10/1 Geovani Ricardo Wiedenhoft : > Hello, > > We are completing development of the mod_khomp endpoint for Khomp boards: ... > > 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. I have already encountered this during the mod_skinny development. I asked the question to anthm on IRC and implemented what he suggested. This is mainly done in function skinny_session_dest_match_pattern() in src/mod/endpoints/mod_skinny/skinny_server.c. As processing all the dialplan can take too much CPU, a simpler dialplan is created which is named skinny-patterns. The conditions are processed like in a normal routing (Code was stolen from switch_core_standard_on_routing) with less and simpler expressions. Also specific commands are parsed instead of the common ones. Currently, those are skinny-route, skinny-drop and skinny-wait (only wait forever implemented). > > 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. You don't need to parse XML, the "dialplan_interface" does it for you. > So, I would like to know what is the possibility of similar functions to be > implemented in the core? There is no such function now in the core but we can work together to implement one. There was some though on this in http://jira.freeswitch.org/browse/FS-477. We need a way to be able to call 123 as well as 1234/ > Thanks > :) > > > Geovani Ricardo Wiedenhoft -- Mathieu Parent From anthony.minessale at gmail.com Tue Oct 12 12:05:49 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 12 Oct 2010 14:05:49 -0500 Subject: [Freeswitch-dev] Searching for a valid extension In-Reply-To: References: Message-ID: check the new switch_ivr_dmachine object On Tue, Oct 12, 2010 at 1:40 PM, Mathieu Parent wrote: > Hello, > > 2010/10/1 Geovani Ricardo Wiedenhoft : >> Hello, >> >> We are completing development of the mod_khomp endpoint for Khomp boards: > ... >> >> 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. > > I have already encountered this during the mod_skinny development. I > asked the question to anthm on IRC and implemented what he suggested. > This is mainly done in function skinny_session_dest_match_pattern() in > src/mod/endpoints/mod_skinny/skinny_server.c. > > As processing all the dialplan can take too much CPU, a simpler > dialplan is created which is named skinny-patterns. The conditions are > processed like in a normal routing (Code was stolen from > switch_core_standard_on_routing) with less and simpler expressions. > Also specific commands are parsed instead of the common ones. > Currently, those are skinny-route, skinny-drop and skinny-wait (only > wait forever implemented). > >> >> 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. > > You don't need to parse XML, the "dialplan_interface" does it for you. > >> So, I would like to know what is the possibility of similar functions to be >> implemented in the core? > > There is no such function now in the core but we can work together to > implement one. There was some though on this in > http://jira.freeswitch.org/browse/FS-477. We need a way to be able to > call 123 as well as 1234/ > >> Thanks >> :) >> >> >> Geovani Ricardo Wiedenhoft > -- > Mathieu Parent > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From msc at freeswitch.org Wed Oct 13 07:58:35 2010 From: msc at freeswitch.org (Michael Collins) Date: Wed, 13 Oct 2010 07:58:35 -0700 Subject: [Freeswitch-dev] FreeSWITCH Conference Call Today - Moises Silva From Sangoma Speaking Message-ID: Hey all! We have a good agenda for today: http://wiki.freeswitch.org/wiki/FS_weekly_2010_10_13 Moises will be in to talk about FreeTDM and where we stand. If you have FreeTDM questions please join and Moises will answer them. We also have a few new FreeSWITCH features to discuss. Talk to you in a few hours! -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101013/21881f5e/attachment.html From cbeeton at avaya.com Wed Oct 13 12:46:56 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 13 Oct 2010 15:46:56 -0400 Subject: [Freeswitch-dev] Dialog events In-Reply-To: References: Message-ID: I've attached a patch which shows what I am thinking of. It adds two columns into the sip_dialogs table, to track to_tag and from_tag. Since one of the tags is sometimes not known when the dialog is created, it is updated on the 200 response (there is probably a better place to do this). Then when a NOTIFY(dialog) is being crafted, the call_id and tags and the remote contact uri are used. These fields and the remote target uri are important because they allow an INVITE with REPLACES to be crafted. I am still not sure I understand the role of the sip_registrations table when crafting dialog events. I have reworked the query in a way which seems to me to match what the rfc describes. Please let me know what you think of this patch. Is there a set of presence tests that can be run to ensure that existing behaviour is not adversely affected? I know the contents of the element are still not 100% correct (for example, in the case where the call has come in from another domain, the remote identity uses the wrong domain. This doesn't cause me a problem but really it should be correct). Thanks, Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Tuesday, October 12, 2010 2:28 PM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events > > in this case you could possibly branch off with a 2nd sql > stmt when so configured in the presence_probe handler to do > exactly what you want and select all the same columns > > On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn) > wrote: > > I have enabled at least some of the debug. I will check to > see if it is at level 10. > > > > Our application SUBECRIBEs for dialog events only when it > is interested in them, with a very short timeout (ideally 0, > but this does not work for some endpoints). We expect a > NOTIFY back giving the current status. We don't want status > events continually, just a single update when we ask for it. > It seems like the code is very close to supporting this. > > > > Carolyn > > > >> -----Original Message----- > >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of > >> Anthony Minessale > >> Sent: Tuesday, October 12, 2010 1:47 PM > >> To: freeswitch-dev at lists.freeswitch.org > >> Subject: Re: [Freeswitch-dev] Dialog events > >> > >> The presence probe statement you are following is executed when a > >> subscription happens to get the first event. its a way to > make all > >> entities fire a presence event. > >> > >> The real presence sql stmt is the one at 698 which does > not involve > >> registration and is triggered by presence_in events which will be > >> fired when you set the presence_id. If you don't have the domains > >> the same and the presence_hosts field set to cover the > variants you > >> may get nothing. > >> > >> The only real problem I can imagine you are having is getting that > >> first required notify after a subscribe, instead you would > not get it > >> until you placed a call. It would require just blindly accepting > >> subscriptions to everything to do what you want. > >> > >> have you enabled debug-presence set to 10 in > >> conf/autoload_configs/sofia.conf.xml ? > >> > >> This will show the SQL STMTS ad they are being run and > could help you > >> to see what you are missing. > >> > >> > >> > >> > >> On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn) > >> wrote: > >> > I am still only getting the partial dialog-info element, > >> not the full dialog contents that I expect when I subscribe for > >> dialog events. I get this: > >> > > >> > >> > version=\"1\" state=\"partial\" entity=\"sip:44 at cbeeton.com\"> > >> > > >> > > >> > But not the per-dialog element containing details about > >> active dialogs, e.g.: > >> > > >> > >> > version=\"1\" state=\"full\" > entity=\"sip:44 at cbeeton.com\"> >> > id=\"d3d433ce-2324c33e at 10.10.10.116\" > >> > call-id=\"d3d433ce-2324c33e at 10.10.10.116\" > >> local-tag=\"KQcQB9v3rmgpp\" > >> > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\"> > >> > confirmed >> > display=\"44\">sip:44 at 10.10.10.158 > >> > >> > pname=\"+sip.rendering\" pvalue=\"yes\"/> > >> > >> display=\"201-116\">sip:201 at 10.10.10.158 > >> > > >> > > >> > > >> > > >> > > >> > This is what I am looking for, but the details are blocked > >> because the query looks in sip_registrations first and there are > >> none. As you say below, "the only way to really know what state a > >> phone is in, is to check if it's involved in a call or is > registered" > >> - but the query is doing effectively "AND is registered" > >> > > >> > Setting presence_id did not make a difference that I could see. > >> > > >> > Carolyn > >> > > >> >> -----Original Message----- > >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of > >> >> Anthony Minessale > >> >> Sent: Tuesday, October 12, 2010 11:28 AM > >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> > >> >> Try this: > >> >> > >> >> > >> >> > >> >> data="presence_id=44@$${domain}"/> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> change $${domain} to some other value if you have a manually > >> >> configured domain. > >> >> > >> >> if you don't set presence_id, you will never see any presence > >> >> messages for that call. > >> >> > >> >> Setting presence id is critical to get your call to broadcast > >> >> presence events. > >> >> The reason we care about registered phones is when you > >> subscribe to > >> >> an extension, it's assumed to represent a phone and the > >> only way to > >> >> really know what state a phone is in, is to check if it's > >> involved in > >> >> a call or is registered, anything else means you have > no idea and > >> >> could not report proper presence. > >> >> > >> >> The sip_dialogs table is not part of the dialog-info > stuff so RFC > >> >> quotes would not be appropriate in this case. This table > >> is just a > >> >> toll FS uses in many instances to track extra info about a > >> sip call > >> >> for various features including sometimes the dialog-info events. > >> >> > >> >> > >> >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn) > >> >> wrote: > >> >> > OK. I have configured the freeswitch dialplan to answer > >> >> extension 44 and invoke the playback application: > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > data="/music/default.wav"/> > >> >> > > >> >> > > >> >> > > >> >> > Now I want to be able to subscribe to 44@ to > >> >> see what calls are being handled there (this is just a > first step > >> >> towards monitoring the calls that FS is handling for us). > >> >> > > >> >> > PRESENCE_PROBE does not sound like quite the right thing, > >> >> then. But that is what is being triggered by a > >> >> SUBSCRIBE(dialog) to that extension. >From RFC4235: > >> >> > > >> >> > "The dialog package allows users to subscribe to another > >> >> > user and to receive notification of the changes in state > >> >> of INVITE- > >> >> > initiated dialog usages in which the subscribed-to user > >> >> is involved." > >> >> > > >> >> > Nothing in there about being registered or not. > >> >> > > >> >> > Carolyn > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > >> Behalf Of > >> >> >> Anthony Minessale > >> >> >> Sent: Tuesday, October 12, 2010 10:30 AM > >> >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> >> > >> >> >> The reason for this is because we don't care about any > >> >> calls who are > >> >> >> not registered to us. > >> >> >> The sip_dialogs table are purely for in-call presence > >> >> information of > >> >> >> authenticated users. > >> >> >> > >> >> >> PRESENCE_PROBE is, in essence a query to see who is > currently > >> >> >> registered. > >> >> >> > >> >> >> Maybe if you describe your paradigm to me that does not > >> >> involve any > >> >> >> registrations, I can come up with a better answer. > >> >> >> > >> >> >> > >> >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn) > >> >> >> wrote: > >> >> >> > Most of my changes are a pretty straight-forward extension > >> >> >> to add the call-id, local-tag and remote-tag into > the > >> >> >> element. But I am blocked by the sql query in > >> >> >> actual_sofia_presence_event_handler which pulls out the > >> >> rows to work > >> >> >> on in the first place (in the > >> SWITCH_EVENT_PRESENCE_PROBE case), > >> >> >> because it uses the sip_registrations table as the > >> >> "master" and does > >> >> >> a left join on sip_dialogs and sip_presence to get more > >> >> data. In my > >> >> >> case, there is nothing in sip_registrations, so I get no > >> >> matches to > >> >> >> work on. I realize that changing this query (or any of > >> >> this stuff) > >> >> >> is a risky thing - at this point I am just feeling > >> around to see > >> >> >> what might be possible. > >> >> >> > > >> >> >> > So my main question right now is: > >> >> >> > - is it correct to build dialog event content primarily > >> >> >> based on the sip_registrations table? Could the query be > >> >> rejigged so > >> >> >> that sip_dialogs is the master and sip_registrations is > >> >> joined where > >> >> >> there is a match? To me, this would seem to be correct, > >> as dialog > >> >> >> event contents should have little to do with registrations > >> >> and should > >> >> >> not be primarly driven by them. > >> >> >> > > >> >> >> > Carolyn > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org > >> >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > >> >> Behalf Of > >> >> >> >> Anthony Minessale > >> >> >> >> Sent: Friday, October 08, 2010 5:32 PM > >> >> >> >> To: freeswitch-dev at lists.freeswitch.org > >> >> >> >> Subject: Re: [Freeswitch-dev] Dialog events > >> >> >> >> > >> >> >> >> anything can be accepted that keeps things working > >> the way they > >> >> >> >> already do work and more. > >> >> >> >> we can probably add those other things to the dialog table > >> >> >> as long as > >> >> >> >> nothing breaks in the process. > >> >> >> >> > >> >> >> >> I am just trying to warn you that this is heavily > >> >> >> depended-upon code > >> >> >> >> by many and it's a critical change to manipulate it > >> and changes > >> >> >> >> should be discussed in detail. > >> >> >> >> > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > FreeSWITCH-dev mailing list > >> >> >> > FreeSWITCH-dev at lists.freeswitch.org > >> >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> >> > > >> >> >> > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> >> v > >> >> >> > http://www.freeswitch.org > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> Anthony Minessale II > >> >> >> > >> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon > >> >> http://www.cluecon.com/ > >> >> >> Twitter: http://twitter.com/FreeSWITCH_wire > >> >> >> > >> >> >> AIM: anthm > >> >> >> MSN:anthony_minessale at hotmail.com > >> >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> >> >> IRC: irc.freenode.net #freeswitch > >> >> >> > >> >> >> FreeSWITCH Developer Conference > >> >> >> sip:888 at conference.freeswitch.org > >> >> >> googletalk:conf+888 at conference.freeswitch.org > >> >> >> pstn:+19193869900 > >> >> >> > >> >> >> _______________________________________________ > >> >> >> FreeSWITCH-dev mailing list > >> >> >> FreeSWITCH-dev at lists.freeswitch.org > >> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> >> > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> >> v > >> >> >> http://www.freeswitch.org > >> >> >> > >> >> > _______________________________________________ > >> >> > FreeSWITCH-dev mailing list > >> >> > FreeSWITCH-dev at lists.freeswitch.org > >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> > > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> v > >> >> > http://www.freeswitch.org > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Anthony Minessale II > >> >> > >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon > >> http://www.cluecon.com/ > >> >> Twitter: http://twitter.com/FreeSWITCH_wire > >> >> > >> >> AIM: anthm > >> >> MSN:anthony_minessale at hotmail.com > >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> >> IRC: irc.freenode.net #freeswitch > >> >> > >> >> FreeSWITCH Developer Conference > >> >> sip:888 at conference.freeswitch.org > >> >> googletalk:conf+888 at conference.freeswitch.org > >> >> pstn:+19193869900 > >> >> > >> >> _______________________________________________ > >> >> FreeSWITCH-dev mailing list > >> >> FreeSWITCH-dev at lists.freeswitch.org > >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> >> > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> >> v > >> >> http://www.freeswitch.org > >> >> > >> > _______________________________________________ > >> > FreeSWITCH-dev mailing list > >> > FreeSWITCH-dev at lists.freeswitch.org > >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> > http://www.freeswitch.org > >> > > >> > >> > >> > >> -- > >> Anthony Minessale II > >> > >> FreeSWITCH http://www.freeswitch.org/ ClueCon > http://www.cluecon.com/ > >> Twitter: http://twitter.com/FreeSWITCH_wire > >> > >> AIM: anthm > >> MSN:anthony_minessale at hotmail.com > >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > >> IRC: irc.freenode.net #freeswitch > >> > >> FreeSWITCH Developer Conference > >> sip:888 at conference.freeswitch.org > >> googletalk:conf+888 at conference.freeswitch.org > >> pstn:+19193869900 > >> > >> _______________________________________________ > >> FreeSWITCH-dev mailing list > >> FreeSWITCH-dev at lists.freeswitch.org > >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > >> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de > >> v > >> http://www.freeswitch.org > >> > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-support-of-Dialog-events.patch Type: application/octet-stream Size: 16434 bytes Desc: 0001-Improve-support-of-Dialog-events.patch Url : http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101013/f438096e/attachment-0001.obj From bernhard.suttner at winet.ch Wed Oct 13 13:58:27 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Wed, 13 Oct 2010 22:58:27 +0200 Subject: [Freeswitch-dev] Improve Freeswitch Debugging Message-ID: <20101013225827.a3ee05e0@mail.winet.ch> Hi, is there a idea how to improve the freeswitch debugging possiblities if freeswitch does run on a high used system - maybe also clustered? I think this is maybe still a problem if the system is under high load and how have to get debug informations because e.g. the call from user 7777 is always not successful. Like a api command (debug_all_from sip-user 7777) which will then write kind of debug stuff from and to this user (log messages, sip debug messages, ...) to a special syslog server, log file, ...) Any other idea how to improve that or is there already a nice way to get that? Best regards, Bernhard From msc at freeswitch.org Wed Oct 13 14:21:34 2010 From: msc at freeswitch.org (Michael Collins) Date: Wed, 13 Oct 2010 14:21:34 -0700 Subject: [Freeswitch-dev] Improve Freeswitch Debugging In-Reply-To: <20101013225827.a3ee05e0@mail.winet.ch> References: <20101013225827.a3ee05e0@mail.winet.ch> Message-ID: Right now the best item for this is to enable the uuid stamp on all debug lines in the freeswitch.log file. In conf/autoload_configs/logfile.conf.xml enable this: restart fs or reload mod_logfile and from that point on each log line will have the associated uuid if there is one. As for your other idea, right now there isn't anything like that and it would probably take a fair amount of time and energy to come up with something like that. It would be great to have that ability, however it is not a simple endeavor. -MC On Wed, Oct 13, 2010 at 1:58 PM, Bernhard Suttner wrote: > Hi, > > is there a idea how to improve the freeswitch debugging possiblities if > freeswitch does run on a high used system - maybe also clustered? I think > this is maybe still a problem if the system is under high load and how have > to get debug informations because e.g. the call from user 7777 is always not > successful. > > Like a api command (debug_all_from sip-user 7777) which will then write > kind of debug stuff from and to this user (log messages, sip debug messages, > ...) to a special syslog server, log file, ...) > > Any other idea how to improve that or is there already a nice way to get > that? > > Best regards, > Bernhard > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101013/28e04384/attachment.html From grw.freeswitch at gmail.com Thu Oct 14 10:16:54 2010 From: grw.freeswitch at gmail.com (Geovani Ricardo Wiedenhoft) Date: Thu, 14 Oct 2010 14:16:54 -0300 Subject: [Freeswitch-dev] Searching for a valid extension. In-Reply-To: References: Message-ID: Thanks for the sugestions. I checked carefully every step, however, I got some questions. We tested the originate with the loopback endpoint, because we need to pass through the dialplan. My context: Test: freeswitch at geovani> originate loopback/10/khomp-SIP/XML 1002 -ERR NO_ROUTE_DESTINATION In this test, we send the digits 10 (simulating the reception of these digits in the FXS) for khomp-SIP context in XML. I expected the INVALID_NUMBER_FORMAT return (accept more digits and try again), but the result was NO_ROUTE_DESTINATION. This happened with the switch_ivr_originate function too. switch_ivr_originate(NULL, &session, &cause, dialstring.c_str(), timeout, NULL, NULL, NULL, NULL, NULL, SOF_NONE, NULL); cause = 3 = NO_ROUTE_DESTINATION In previous email I did not say, we can make calls with timeout between digits, but my goal is to anticipate the call if possible checking of the extension/context(exact match). Also, we need verify what context configured by the user is used. Thanks again Anthony Minessale and Mathieu Parent, but the others options use timeout for connections, if we understand completely. On Mon, Oct 11, 2010 at 5:44 PM, Anthony Minessale < anthony.minessale at gmail.com> wrote: > We don't have a static monolithic dialplan like asterisk, there can be > many dialplans or dynamic dialplans that reach out to external > services. > > The proper way to implement overlap dialing on a per-protocol basis would > be: > > 1) Separate your native channel from the FreeSWITCH channel so you can > create a FreeSWITCH session and attach the native channel. > > 2) send the call to the configured dialplan and allow that dialplan > module to work out it's own ambiguities and respond: > > SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28 > > 3) when you see this cause accept more digits and try again until you > get some other cause code. > > > This is how it's done in sip by doing an entire new call each time you > need to dial more digits. > > > > The other way which we do in FreeTDM is to define 2 regex, one for > anything that is valid and one for anything that is invalid and > consult this regex on each digit until you know one way or another. > > > > > > > On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft > wrote: > > 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 > > > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101014/31ba3031/attachment.html From anthony.minessale at gmail.com Thu Oct 14 10:45:13 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Thu, 14 Oct 2010 12:45:13 -0500 Subject: [Freeswitch-dev] Searching for a valid extension. In-Reply-To: References: Message-ID: You have to run the call into your own logic, either some XML REGEX or a script etc and you manually return INVALID_NUMBER_FORMAT when you want to signal to your phone to collect more digits. again, the dialplan is dynamic, fluid and stackable you cannot statically map every extension but you don't need to. Once you build the functionality that hanging up with INVALID_NUMBER_FORMAT means collect more digits and any other cause means you have dialed an invalid number, you can go develop a million ways to send this message back to your module and not make the module care about it. So you are hijacking that one cause to not actually hangup the channel. On Thu, Oct 14, 2010 at 12:16 PM, Geovani Ricardo Wiedenhoft wrote: > Thanks for the sugestions. > > I checked carefully every step, however, I got some questions. > > We tested the originate with the loopback endpoint, because we need to pass > through the dialplan. > > My context: > > > ? > ??? > ????? > ??? > ? > > > > Test: > freeswitch at geovani> originate loopback/10/khomp-SIP/XML 1002 > > > -ERR NO_ROUTE_DESTINATION > > > > In this test, we send the digits 10 (simulating the reception of these > digits in the FXS) for khomp-SIP context in XML. I expected the > INVALID_NUMBER_FORMAT return (accept more digits and try again), but the > result was NO_ROUTE_DESTINATION. This happened with the switch_ivr_originate > function too. > > switch_ivr_originate(NULL, &session, &cause, dialstring.c_str(), timeout, > NULL, NULL, NULL, NULL, NULL, SOF_NONE, NULL); > > cause = 3 = NO_ROUTE_DESTINATION > > > In previous email I did not say, we can make calls with timeout between > digits, but my goal is to anticipate the call if possible checking of the > extension/context(exact match). Also, we need verify what context configured > by the user is used. > > > Thanks again Anthony Minessale and Mathieu Parent, but the others options > use timeout for connections, if we understand completely. > > > > On Mon, Oct 11, 2010 at 5:44 PM, Anthony Minessale > wrote: >> >> We don't have a static monolithic dialplan like asterisk, there can be >> many dialplans or dynamic dialplans that reach out to external >> services. >> >> The proper way to implement overlap dialing on a per-protocol basis would >> be: >> >> 1) Separate your native channel from the FreeSWITCH channel so you can >> create a FreeSWITCH session and attach the native channel. >> >> 2) send the call to the configured dialplan and allow that dialplan >> module to work out it's own ambiguities and respond: >> >> SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28 >> >> 3) when you see this cause accept more digits and try again until you >> get some other cause code. >> >> >> This is how it's done in sip by doing an entire new call each time you >> need to dial more digits. >> >> >> >> The other way which we do in FreeTDM is to define 2 regex, one for >> anything that is valid and one for anything that is invalid and >> consult this regex on each digit until you know one way or another. >> >> >> >> >> >> >> On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft >> wrote: >> > 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 >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From msc at freeswitch.org Thu Oct 14 10:48:31 2010 From: msc at freeswitch.org (Michael Collins) Date: Thu, 14 Oct 2010 10:48:31 -0700 Subject: [Freeswitch-dev] Searching for a valid extension. In-Reply-To: References: Message-ID: Your regex does not match what you dialed: ^10(\d)$ needs three digits but you only dialed two digits in your originate: loopback/10/khomp-SIP/XML try something like: loopback/101/khomp-SIP/XML -MC On Thu, Oct 14, 2010 at 10:16 AM, Geovani Ricardo Wiedenhoft < grw.freeswitch at gmail.com> wrote: > Thanks for the sugestions. > > I checked carefully every step, however, I got some questions. > > We tested the originate with the loopback endpoint, because we need to pass > through the dialplan. > > My context: > > > > > > > > > > > Test: > freeswitch at geovani> originate loopback/10/khomp-SIP/XML 1002 > > > -ERR NO_ROUTE_DESTINATION > > > > In this test, we send the digits 10 (simulating the reception of these > digits in the FXS) for khomp-SIP context in XML. I expected the > INVALID_NUMBER_FORMAT return (accept more digits and try again), but the > result was NO_ROUTE_DESTINATION. This happened with the switch_ivr_originate > function too. > > switch_ivr_originate(NULL, &session, &cause, dialstring.c_str(), timeout, > NULL, NULL, NULL, NULL, NULL, SOF_NONE, NULL); > > cause = 3 = NO_ROUTE_DESTINATION > > > In previous email I did not say, we can make calls with timeout between > digits, but my goal is to anticipate the call if possible checking of the > extension/context(exact match). Also, we need verify what context configured > by the user is used. > > > Thanks again Anthony Minessale and Mathieu Parent, but the others options > use timeout for connections, if we understand completely. > > > > On Mon, Oct 11, 2010 at 5:44 PM, Anthony Minessale < > anthony.minessale at gmail.com> wrote: > >> We don't have a static monolithic dialplan like asterisk, there can be >> many dialplans or dynamic dialplans that reach out to external >> services. >> >> The proper way to implement overlap dialing on a per-protocol basis would >> be: >> >> 1) Separate your native channel from the FreeSWITCH channel so you can >> create a FreeSWITCH session and attach the native channel. >> >> 2) send the call to the configured dialplan and allow that dialplan >> module to work out it's own ambiguities and respond: >> >> SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28 >> >> 3) when you see this cause accept more digits and try again until you >> get some other cause code. >> >> >> This is how it's done in sip by doing an entire new call each time you >> need to dial more digits. >> >> >> >> The other way which we do in FreeTDM is to define 2 regex, one for >> anything that is valid and one for anything that is invalid and >> consult this regex on each digit until you know one way or another. >> >> >> >> >> >> >> On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft >> wrote: >> > 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 >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101014/6d6125e6/attachment.html From eduardonunesp at gmail.com Thu Oct 14 14:33:54 2010 From: eduardonunesp at gmail.com (Eduardo Nunes Pereira) Date: Thu, 14 Oct 2010 18:33:54 -0300 Subject: [Freeswitch-dev] Building "as xml" to console Message-ID: Hi, friends there functions to do my xml output to console: example "tasks show the xml" and shows in xml, or have to build my output xml all manually ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101014/1068b931/attachment.html From msc at freeswitch.org Thu Oct 14 17:18:06 2010 From: msc at freeswitch.org (Michael Collins) Date: Thu, 14 Oct 2010 17:18:06 -0700 Subject: [Freeswitch-dev] Building "as xml" to console In-Reply-To: References: Message-ID: Check out switch_xml.c. I think a good example of this might be "fifo list_verbose". In mod_fifo.c approx line # 3644 it creates a new object of type switch_xml_t using switch_xml_new(). I think you'll find some handy things like adding xml child nodes, etc. Look in mod_fifo.c at the function list_node() for an example of how you can use the included tools to build up an XML structure. Then you can convert to text with switch_xml_toxml() function. Search for this line in mod_fifo.c: xml_text = switch_xml_toxml(x_report, SWITCH_FALSE); The context around that line is a good example of using these objects, printing them out and then safely freeing them from memory. -MC On Thu, Oct 14, 2010 at 2:33 PM, Eduardo Nunes Pereira < eduardonunesp at gmail.com> wrote: > Hi, friends > > there functions to do my xml output to console: example "tasks show the > xml" and shows in xml, or have to build my output xml all manually ? > > Thanks > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101014/67174294/attachment.html From tayeb.meftah at gmail.com Sat Oct 16 02:37:18 2010 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Sat, 16 Oct 2010 11:37:18 +0200 Subject: [Freeswitch-dev] Building "as xml" to console In-Reply-To: References: Message-ID: <4CB9724E.10804@gmail.com> show tasks as xml thank you Le 14/10/2010 23:33, Eduardo Nunes Pereira a ?crit : > Hi, friends > > there functions to do my xml output to console: example "tasks > show the xml" and shows in xml, or have to build my output xml all > manually ? > > Thanks > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -- Meftah Tayeb inum: +883510001288000 mobile: +213660347746 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101016/6345742b/attachment.html From cbeeton at avaya.com Fri Oct 15 08:16:58 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Fri, 15 Oct 2010 11:16:58 -0400 Subject: [Freeswitch-dev] Dialog events: full vs partial Message-ID: I have started again on a fresh branch to investigate presence monitoring of conference extensions, and I think I have discovered another problem with the way that NOTIFYs containing dialog events are formulated. RFC4235 says: "state: This attribute indicates whether the document contains the full dialog information, or whether it contains only information on those dialogs that have changed since the previous document (partial)." and "Notifications do not normally contain full state; rather, they only indicate the state of the dialog(s) whose state has changed. The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a NOTIFY that contains no dialog elements. These NOTIFYs contain the complete view of dialog state." But what I see the code doing is *never* sending a complete (full) list of dialogs, even if there are more than one, and marking all the presence event related NOTIFY events as "full" even though by the definition above, they are all "partial". One observable effect is if you are monitoring a conference extension. The light will begin to flash when one person joins the conference, and goes solid when another joins, but then goes out when one person leaves, even though others are still in. This is because the NOTIFY is sent with status "full" but only contains the one "terminated" dialog, and none of the others which are still "confirmed". I'm not sure yet what is the best way to solve this. I think that sofia_presence_sub_callback is always generating "partial" updates, because it is always considering only the most recent event. I think that the sofia_presence_resub callback will have to generate one event, containing all the rows retrieved from the query, rather than what it does now (which is send a SWITCH_EVENT_PRESENCE_IN for each row, which is handled by the sofia_presence_sub_callback and thus results in a bunch of what are really "partial" NOTIFYs, instead of one "full" NOTIFY). Does this make sense? Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101015/2a649e08/attachment-0001.html From anthony.minessale at gmail.com Fri Oct 15 08:29:18 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 15 Oct 2010 10:29:18 -0500 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: The conference has it's own presence feature for the conference as a whole. see conf/autoload_configs/conference.conf.xml Then you can subscribe to conf+3001@ And the presence is announced for the conference as a whole. On Fri, Oct 15, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) wrote: > I have started again on a fresh branch to investigate presence monitoring of > conference extensions, and I think I have discovered another problem with > the way that NOTIFYs containing dialog events are formulated. > > RFC4235 says: > "state: This attribute indicates whether the document contains the > full dialog information, or whether it contains only information > on those dialogs that have changed since the previous document > (partial)." > > and > > "Notifications do not normally contain full state; rather, they > only indicate the state of the dialog(s) whose state has changed. > The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a > NOTIFY that contains no dialog elements.? These NOTIFYs contain > the complete view of dialog state." > > But what I see the code doing is *never* sending a complete (full) list of > dialogs, even if there are more than one, and marking all the presence event > related NOTIFY events as "full" even though by the definition above, they > are all "partial". > > One observable effect is if you are monitoring a conference extension.? The > light will begin to flash when one person joins the conference, and goes > solid when another joins, but then goes out when one person leaves, even > though others are still in.? This is because the NOTIFY is sent with status > "full" but only contains the one "terminated" dialog, and none of the others > which are still "confirmed". > > I'm not sure yet what is the best way to solve this.? I think that > sofia_presence_sub_callback?is always generating "partial" updates, because > it is always considering only the most recent event.?I think that the > sofia_presence_resub callback will have to generate one event, containing > all the rows retrieved from the query, rather than what it does now (which > is send a SWITCH_EVENT_PRESENCE_IN for each row, which is handled by the > sofia_presence_sub_callback and thus results in a bunch of what are really > "partial" NOTIFYs, instead of one "full" NOTIFY). > > Does this make sense? > > Carolyn > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Fri Oct 15 09:59:19 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Fri, 15 Oct 2010 12:59:19 -0400 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: That's interesting, but I'm not sure that it addresses the entire issue. I first observed this problem when working on another feature, where I want to monitor calls being handled by a Freeswitch app at a certain extension. I was not getting the full list there, either. If Freeswitch was returning a proper "full" list and proper "partial" updates, conferences wouldn't need to be handled as a special case. Doesn't the mismatch between the RFC and the behaviour warrant some investigation? Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Friday, October 15, 2010 11:29 AM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events: full vs partial > > The conference has it's own presence feature for the > conference as a whole. > > see conf/autoload_configs/conference.conf.xml > > > > > > > > Then you can subscribe to conf+3001@ And the > presence is announced for the conference as a whole. > > > > > On Fri, Oct 15, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) > wrote: > > I have started again on a fresh branch to investigate presence > > monitoring of conference extensions, and I think I have discovered > > another problem with the way that NOTIFYs containing dialog > events are formulated. > > > > RFC4235 says: > > "state: This attribute indicates whether the document contains the > > full dialog information, or whether it contains only information on > > those dialogs that have changed since the previous document > > (partial)." > > > > and > > > > "Notifications do not normally contain full state; rather, > they only > > indicate the state of the dialog(s) whose state has changed. > > The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a > > NOTIFY that contains no dialog elements.? These NOTIFYs contain the > > complete view of dialog state." > > > > But what I see the code doing is *never* sending a complete (full) > > list of dialogs, even if there are more than one, and > marking all the > > presence event related NOTIFY events as "full" even though by the > > definition above, they are all "partial". > > > > One observable effect is if you are monitoring a conference > extension.? > > The light will begin to flash when one person joins the conference, > > and goes solid when another joins, but then goes out when > one person > > leaves, even though others are still in.? This is because > the NOTIFY > > is sent with status "full" but only contains the one "terminated" > > dialog, and none of the others which are still "confirmed". > > > > I'm not sure yet what is the best way to solve this.? I think that > > sofia_presence_sub_callback?is always generating "partial" updates, > > because it is always considering only the most recent > event.?I think > > that the sofia_presence_resub callback will have to generate one > > event, containing all the rows retrieved from the query, > rather than > > what it does now (which is send a SWITCH_EVENT_PRESENCE_IN for each > > row, which is handled by the sofia_presence_sub_callback and thus > > results in a bunch of what are really "partial" NOTIFYs, > instead of one "full" NOTIFY). > > > > Does this make sense? > > > > Carolyn > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Fri Oct 15 10:19:04 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 15 Oct 2010 12:19:04 -0500 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: Same answer as before. We are open to improvements but you cannot break any existing functionality and it cannot make FreeSWITCH slow an inflexible just because some RFC wants it. I think most of the presence implementations in SIP are fool hearty to begin with but we are trying to also normalize presence into an abstraction and we currently do not support one entity sending back multiple presence informations so that concept would need to go into the core abstraction before it could be realized into the sip endpoint. On Fri, Oct 15, 2010 at 11:59 AM, Beeton, Carolyn (Carolyn) wrote: > That's interesting, but I'm not sure that it addresses the entire issue. > > I first observed this problem when working on another feature, where I want to monitor calls being handled by a Freeswitch app at a certain extension. ?I was not getting the full list there, either. > > If Freeswitch was returning a proper "full" list and proper "partial" updates, conferences wouldn't need to be handled as a special case. ?Doesn't the mismatch between the RFC and the behaviour warrant some investigation? > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Friday, October 15, 2010 11:29 AM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events: full vs partial >> >> The conference has it's own presence feature for the >> conference as a whole. >> >> see conf/autoload_configs/conference.conf.xml >> >> >> ? >> ? >> ? ? >> ? >> >> Then you can subscribe to conf+3001@ And the >> presence is announced for the conference as a whole. >> >> >> >> >> On Fri, Oct 15, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) >> wrote: >> > I have started again on a fresh branch to investigate presence >> > monitoring of conference extensions, and I think I have discovered >> > another problem with the way that NOTIFYs containing dialog >> events are formulated. >> > >> > RFC4235 says: >> > "state: This attribute indicates whether the document contains the >> > full dialog information, or whether it contains only information on >> > those dialogs that have changed since the previous document >> > (partial)." >> > >> > and >> > >> > "Notifications do not normally contain full state; rather, >> they only >> > indicate the state of the dialog(s) whose state has changed. >> > The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a >> > NOTIFY that contains no dialog elements.? These NOTIFYs contain the >> > complete view of dialog state." >> > >> > But what I see the code doing is *never* sending a complete (full) >> > list of dialogs, even if there are more than one, and >> marking all the >> > presence event related NOTIFY events as "full" even though by the >> > definition above, they are all "partial". >> > >> > One observable effect is if you are monitoring a conference >> extension. >> > The light will begin to flash when one person joins the conference, >> > and goes solid when another joins, but then goes out when >> one person >> > leaves, even though others are still in.? This is because >> the NOTIFY >> > is sent with status "full" but only contains the one "terminated" >> > dialog, and none of the others which are still "confirmed". >> > >> > I'm not sure yet what is the best way to solve this.? I think that >> > sofia_presence_sub_callback?is always generating "partial" updates, >> > because it is always considering only the most recent >> event.?I think >> > that the sofia_presence_resub callback will have to generate one >> > event, containing all the rows retrieved from the query, >> rather than >> > what it does now (which is send a SWITCH_EVENT_PRESENCE_IN for each >> > row, which is handled by the sofia_presence_sub_callback and thus >> > results in a bunch of what are really "partial" NOTIFYs, >> instead of one "full" NOTIFY). >> > >> > Does this make sense? >> > >> > Carolyn >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From anthony.minessale at gmail.com Fri Oct 15 14:14:30 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 15 Oct 2010 16:14:30 -0500 Subject: [Freeswitch-dev] UI Developer Job for CudaTel Message-ID: We're expanding our horizons again over at CudaTel and hiring some more developers. Anyone interested, who lives in WI, OK, CA or MI or willing to move to one of those should apply. Looking for people with good HTML Design instincts and JavaScript / Jquery skills. Full-time job with challenging/rewarding work. Send inquires to jobs at freeswitch.org with a resume and any example work. -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From msc at freeswitch.org Mon Oct 18 12:29:03 2010 From: msc at freeswitch.org (Michael Collins) Date: Mon, 18 Oct 2010 12:29:03 -0700 Subject: [Freeswitch-dev] FreeSWITCH Conference Call This Wednesday Oct 20 Message-ID: Hello all! Here is the agenda page for this Wednesday's call: http://wiki.freeswitch.org/wiki/FS_weekly_2010_10_20 We didn't have a speaker scheduled for Wednesday so I will spend a few minutes talking about the wiki. Please bring your wiki questions. In fact, if you can please send me your wiki questions in advance so that I can research them. If you have any agenda items for the call this week please put them on the list. Thanks! -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101018/a035b48c/attachment.html From anthony.minessale at gmail.com Mon Oct 18 13:39:25 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Mon, 18 Oct 2010 15:39:25 -0500 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: I recommend getting latest where you should be closer to what you want apart from the extra columns in the db then trying to get the new cols in separately then work it into the select and into the dialog info xml in incremental steps/patches. On Fri, Oct 15, 2010 at 12:19 PM, Anthony Minessale wrote: > Same answer as before. > > We are open to improvements but you cannot break any existing > functionality and it cannot make FreeSWITCH slow an inflexible just > because some RFC wants it. > > I think most of the presence implementations in SIP are fool hearty to > begin with but we are trying to also normalize presence into an > abstraction and we currently do not support one entity sending back > multiple presence informations so that concept would need to go into > the core abstraction before it could be realized into the sip > endpoint. > > > > > > On Fri, Oct 15, 2010 at 11:59 AM, Beeton, Carolyn (Carolyn) > wrote: >> That's interesting, but I'm not sure that it addresses the entire issue. >> >> I first observed this problem when working on another feature, where I want to monitor calls being handled by a Freeswitch app at a certain extension. ?I was not getting the full list there, either. >> >> If Freeswitch was returning a proper "full" list and proper "partial" updates, conferences wouldn't need to be handled as a special case. ?Doesn't the mismatch between the RFC and the behaviour warrant some investigation? >> >> Carolyn >> >>> -----Original Message----- >>> From: freeswitch-dev-bounces at lists.freeswitch.org >>> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >>> Behalf Of Anthony Minessale >>> Sent: Friday, October 15, 2010 11:29 AM >>> To: freeswitch-dev at lists.freeswitch.org >>> Subject: Re: [Freeswitch-dev] Dialog events: full vs partial >>> >>> The conference has it's own presence feature for the >>> conference as a whole. >>> >>> see conf/autoload_configs/conference.conf.xml >>> >>> >>> ? >>> ? >>> ? ? >>> ? >>> >>> Then you can subscribe to conf+3001@ And the >>> presence is announced for the conference as a whole. >>> >>> >>> >>> >>> On Fri, Oct 15, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) >>> wrote: >>> > I have started again on a fresh branch to investigate presence >>> > monitoring of conference extensions, and I think I have discovered >>> > another problem with the way that NOTIFYs containing dialog >>> events are formulated. >>> > >>> > RFC4235 says: >>> > "state: This attribute indicates whether the document contains the >>> > full dialog information, or whether it contains only information on >>> > those dialogs that have changed since the previous document >>> > (partial)." >>> > >>> > and >>> > >>> > "Notifications do not normally contain full state; rather, >>> they only >>> > indicate the state of the dialog(s) whose state has changed. >>> > The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a >>> > NOTIFY that contains no dialog elements.? These NOTIFYs contain the >>> > complete view of dialog state." >>> > >>> > But what I see the code doing is *never* sending a complete (full) >>> > list of dialogs, even if there are more than one, and >>> marking all the >>> > presence event related NOTIFY events as "full" even though by the >>> > definition above, they are all "partial". >>> > >>> > One observable effect is if you are monitoring a conference >>> extension. >>> > The light will begin to flash when one person joins the conference, >>> > and goes solid when another joins, but then goes out when >>> one person >>> > leaves, even though others are still in.? This is because >>> the NOTIFY >>> > is sent with status "full" but only contains the one "terminated" >>> > dialog, and none of the others which are still "confirmed". >>> > >>> > I'm not sure yet what is the best way to solve this.? I think that >>> > sofia_presence_sub_callback?is always generating "partial" updates, >>> > because it is always considering only the most recent >>> event.?I think >>> > that the sofia_presence_resub callback will have to generate one >>> > event, containing all the rows retrieved from the query, >>> rather than >>> > what it does now (which is send a SWITCH_EVENT_PRESENCE_IN for each >>> > row, which is handled by the sofia_presence_sub_callback and thus >>> > results in a bunch of what are really "partial" NOTIFYs, >>> instead of one "full" NOTIFY). >>> > >>> > Does this make sense? >>> > >>> > Carolyn >>> > _______________________________________________ >>> > FreeSWITCH-dev mailing list >>> > FreeSWITCH-dev at 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/ >>> Twitter: http://twitter.com/FreeSWITCH_wire >>> >>> AIM: anthm >>> MSN:anthony_minessale at hotmail.com >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>> IRC: irc.freenode.net #freeswitch >>> >>> FreeSWITCH Developer Conference >>> sip:888 at conference.freeswitch.org >>> googletalk:conf+888 at conference.freeswitch.org >>> pstn:+19193869900 >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Tue Oct 19 09:23:10 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 19 Oct 2010 12:23:10 -0400 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: Thank you! That is good advice. I will proceed in baby steps as you suggest, with the next step adding the to and from tags into the sip_dialogs database. One question about that: adding new columns to an existing database requires upgrade code. Is there an example I can follow on how to do this, or is this database created from scratch on a freeswitch update? Carolyn > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Anthony Minessale > Sent: Monday, October 18, 2010 4:39 PM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Dialog events: full vs partial > > I recommend getting latest where you should be closer to what > you want apart from the extra columns in the db then trying > to get the new cols in separately then work it into the > select and into the dialog info xml in incremental steps/patches. > From anthony.minessale at gmail.com Tue Oct 19 09:36:40 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 19 Oct 2010 11:36:40 -0500 Subject: [Freeswitch-dev] Dialog events: full vs partial In-Reply-To: References: Message-ID: since most of the tables in sofia are per runtime we just erase it and recreate it. so if you change the def in sofia_glue look for the code later in the file that tries to do a validation sql stmt followed by a reaction which will re-create it. see 5502 for instance for sip_dialogs. also beware I am messing with this code again today so you should beware of merge conflicts. On Tue, Oct 19, 2010 at 11:23 AM, Beeton, Carolyn (Carolyn) wrote: > Thank you! ?That is good advice. ?I will proceed in baby steps as you suggest, with the next step adding the to and from tags into the sip_dialogs database. > > One question about that: adding new columns to an existing database requires upgrade code. ?Is there an example I can follow on how to do this, or is this database created from scratch on a freeswitch update? > > Carolyn > >> -----Original Message----- >> From: freeswitch-dev-bounces at lists.freeswitch.org >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On >> Behalf Of Anthony Minessale >> Sent: Monday, October 18, 2010 4:39 PM >> To: freeswitch-dev at lists.freeswitch.org >> Subject: Re: [Freeswitch-dev] Dialog events: full vs partial >> >> I recommend getting latest where you should be closer to what >> you want apart from the extra columns in the db then trying >> to get the new cols in separately then work it into the >> select and into the dialog info xml in incremental steps/patches. >> > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Tue Oct 19 10:14:18 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 19 Oct 2010 13:14:18 -0400 Subject: [Freeswitch-dev] patch to add to and from tag into sip_dialogs Message-ID: Attached is a patch which adds the to and from tag into sip_dialogs. Since the to tag is not known until an incoming call is accepted, update it then. Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101019/2ce226b4/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Track-to-and-from-tags-in-sip_dialogs-database.patch Type: application/octet-stream Size: 6952 bytes Desc: 0001-Track-to-and-from-tags-in-sip_dialogs-database.patch Url : http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101019/2ce226b4/attachment.obj From joegen at opensipstack.org Tue Oct 19 21:06:41 2010 From: joegen at opensipstack.org (Joegen E. Baclor) Date: Wed, 20 Oct 2010 12:06:41 +0800 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem Message-ID: <4CBE6AD1.3020403@opensipstack.org> Hi, Following Anthonys advise to configure a bridged dial plan infront of sipX socket based apps proves to be a reasonable approach to let attended transfer work for our apps. However, bridged dial plans for the auto-attendant has a side effect. sipX uses blind transfer to forward a caller to its intended destination. sipX proxy would then authenticate the user if it has proper permission to reach the resource as it receives to new INVITE as a result of the blind transfer. Since the call is bridged, b-leg will consume the REFER and send its own INVITE which doesn't have the notion how to authenticate against sipX. My question is is there a way to propagate the REFER to the caller instead of being consumed by the bridge? Thanks for any advise in advance. Joegen From cbeeton at avaya.com Wed Oct 20 06:16:31 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 20 Oct 2010 09:16:31 -0400 Subject: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log Message-ID: I am not seeing SWITCH_LOG_ERROR or SWITCH_LOG_WARNING msgs from sofia_presence.c in the log, though loglevel is set to "debug" and "debug-presence" is set to 10. I do see INFO, NOTICE, and DEBUG messages. Is there something else to set? or do messages at these levels go somewhere different? Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/3c0c0ace/attachment.html From cbeeton at avaya.com Wed Oct 20 07:04:03 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 20 Oct 2010 10:04:03 -0400 Subject: [Freeswitch-dev] observations on latest SUBSCRIBE(dialog) behaviour Message-ID: A couple of comments on the "latest" behaviour when I SUBSCRIBE for dialog events on an internal freeswitch application extension: - No NOTIFY is sent on SUBSCRIBE(dialog) for non-registered endpoints. The extra three empty fields at the end of line 622 of sofia_presence.c should be removed (presence_id should be the 12th arg, but because of these it is 15th) - presence is not reported correctly for calls from remote destinations. The "user" parameter in the resub_callback was recently modified to use the presence_id, but "host" is the from_host (the remote one), which is not correct and results in the START_PRESENCE_SQL not getting any hits. And a very minor thing, but which causes more queries and messages than is really necessary: - two PRESENCE_PROBE events are sent when a SUBSCRIBE(dialog) is received. One is from around line 2335 of sofia_presence.c, the other at the end of the same function (sofia_presence_handle_sip_i_subscribe). One of them should be removed. Carolyn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/76dd17ce/attachment-0001.html From anthony.minessale at gmail.com Wed Oct 20 08:07:53 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Wed, 20 Oct 2010 10:07:53 -0500 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: <4CBE6AD1.3020403@opensipstack.org> References: <4CBE6AD1.3020403@opensipstack.org> Message-ID: I don't quite get what you are saying but.. Can't you define credentials in FS as noreg gateway and match it up to the challenge realm? On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor wrote: > Hi, > > Following Anthonys advise to configure a bridged dial plan infront of > sipX socket based apps proves to be a reasonable approach to let > attended transfer work for our apps. ?However, bridged dial plans for > the auto-attendant has a side effect. ?sipX uses blind transfer to > forward a caller to its intended destination. ?sipX proxy would then > authenticate the user ?if it has proper permission to reach the resource > as it receives to new INVITE as a result of the blind transfer. ?Since > the call is bridged, b-leg will consume the REFER and send its own > INVITE which doesn't have the notion how to authenticate against sipX. > My question is is there a way to propagate the REFER to the caller > instead of being consumed by the bridge? > > Thanks for any advise in advance. > > Joegen > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From jmesquita at freeswitch.org Wed Oct 20 08:36:14 2010 From: jmesquita at freeswitch.org (=?ISO-8859-1?Q?Jo=E3o_Mesquita?=) Date: Wed, 20 Oct 2010 12:36:14 -0300 Subject: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log In-Reply-To: References: Message-ID: Have you set the console log level accordingly? You have to set it to debug like this: console loglevel debug You might also have the loglevel capped so you must issue this command: fsctl loglevel debug I hope that helps. Jo?o Mesquita On Wed, Oct 20, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) < cbeeton at avaya.com> wrote: > I am not seeing SWITCH_LOG_ERROR or SWITCH_LOG_WARNING msgs from > sofia_presence.c in the log, though loglevel is set to "debug" and > "debug-presence" is set to 10. I do see INFO, NOTICE, and DEBUG messages. > Is there something else to set? or do messages at these levels go somewhere > different? > > Carolyn > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/fc27863d/attachment.html From cbeeton at avaya.com Wed Oct 20 11:23:35 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 20 Oct 2010 14:23:35 -0400 Subject: [Freeswitch-dev] presence direction incorrect? Message-ID: One more thing: the "direction" contained in the dialog NOTIFYs is backwards, I think: if (!strcasecmp(direction, "outbound")) { direction = "recipient"; dft_state = "early"; } else { direction = "initiator"; dft_state = "confirmed"; } should be either comparing on "inbound" or switched around. I am seeing inbound dialogs being marked "initiator". The observed user (the internal FS extension) was the recipient of the call. "This attribute is either initiator or recipient, and indicates whether the observed user was the initiator of the dialog, or the recipient of the INVITE that created it." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/f66ec9e5/attachment.html From cbeeton at avaya.com Wed Oct 20 12:51:28 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Wed, 20 Oct 2010 15:51:28 -0400 Subject: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log In-Reply-To: References: Message-ID: My switch.conf.xml file has . The funny thing is that I see the low level debugs (NOTICE and INFO and DEBUG) but not the higher level ones (WARNING and ERROR). I would think if anything it should be the other way around. I have to keep poking in the code to change SWITCH_LOG_WARNING to SWITCH_LOG_NOTICE so that I can see what's going on! Carolyn ________________________________ From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Jo?o Mesquita Sent: Wednesday, October 20, 2010 11:36 AM To: freeswitch-dev at lists.freeswitch.org Subject: Re: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log Have you set the console log level accordingly? You have to set it to debug like this: console loglevel debug You might also have the loglevel capped so you must issue this command: fsctl loglevel debug I hope that helps. Jo?o Mesquita On Wed, Oct 20, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) > wrote: I am not seeing SWITCH_LOG_ERROR or SWITCH_LOG_WARNING msgs from sofia_presence.c in the log, though loglevel is set to "debug" and "debug-presence" is set to 10. I do see INFO, NOTICE, and DEBUG messages. Is there something else to set? or do messages at these levels go somewhere different? Carolyn _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/ec950cbd/attachment.html From steveayre at gmail.com Wed Oct 20 13:26:30 2010 From: steveayre at gmail.com (Steven Ayre) Date: Wed, 20 Oct 2010 21:26:30 +0100 Subject: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log In-Reply-To: References: Message-ID: Perhaps there's no error to display? Steve on iPhone On 20 Oct 2010, at 20:51, "Beeton, Carolyn (Carolyn)" wrote: > My switch.conf.xml file has . > > The funny thing is that I see the low level debugs (NOTICE and INFO and DEBUG) but not the higher level ones (WARNING and ERROR). I would think if anything it should be the other way around. I have to keep poking in the code to change SWITCH_LOG_WARNING to SWITCH_LOG_NOTICE so that I can see what's going on! > > Carolyn > > From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Jo?o Mesquita > Sent: Wednesday, October 20, 2010 11:36 AM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Not seeing WARNING and ERROR messages in log > > Have you set the console log level accordingly? > > You have to set it to debug like this: console loglevel debug > > You might also have the loglevel capped so you must issue this command: fsctl loglevel debug > > I hope that helps. > Jo?o Mesquita > > > On Wed, Oct 20, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn) wrote: > I am not seeing SWITCH_LOG_ERROR or SWITCH_LOG_WARNING msgs from sofia_presence.c in the log, though loglevel is set to "debug" and "debug-presence" is set to 10. I do see INFO, NOTICE, and DEBUG messages. Is there something else to set? or do messages at these levels go somewhere different? > > Carolyn > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101020/b335d8db/attachment-0001.html From anthony.minessale at gmail.com Wed Oct 20 13:35:22 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Wed, 20 Oct 2010 15:35:22 -0500 Subject: [Freeswitch-dev] presence direction incorrect? In-Reply-To: References: Message-ID: It may be wrong so I can't be sure enough to argue but this is how it works properly for BLF you need to make sure that change works for that too. Did you find some dialog-info driven phones and use the blf features to make sure they continue to work per our initial conversation? On Wed, Oct 20, 2010 at 1:23 PM, Beeton, Carolyn (Carolyn) wrote: > One more thing: the "direction" contained in the dialog NOTIFYs is > backwards, I think: > > if (!strcasecmp(direction, "outbound")) { > ??? direction = "recipient"; > ??? dft_state = "early"; > } else { > ??? direction = "initiator"; > ??? dft_state = "confirmed"; > } > > should be either comparing on "inbound" or switched around.? I am seeing > inbound dialogs being marked "initiator".? The observed user (the internal > FS extension) was the recipient of the call. > > "This attribute is either initiator or recipient, and > indicates whether the observed user was the initiator of the > dialog, or the recipient of the INVITE that created it." > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From joegen at opensipstack.org Wed Oct 20 19:54:27 2010 From: joegen at opensipstack.org (Joegen E. Baclor) Date: Thu, 21 Oct 2010 10:54:27 +0800 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: References: <4CBE6AD1.3020403@opensipstack.org> Message-ID: <4CBFAB63.6090408@opensipstack.org> Hi Anthony sorry for being vague. The call flow i am experimenting on looks like this 1. UA1 -> sipXproxy -> [FS (bridged-dial-plan)] -> [FS (auto-attendant-socket dial-plan)] 2. [FS (auto-attendant-socket dial-plan]) sends REFER to [FS (bridged-dial-plan)] 3. B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE to Refer-to URI via sipXproxy The way sipX does this right now is REFER is actually processed by UA1. Having [FS (bridged-dial-plan)] breaks this. I have reason to believe that the ultimate answer to my previous question would be a no. Replicating authentication credentials would be costly as well as create a security hole since any UA which has a valid extension in the from URI can now make calls through the AA without being challenged since FS assumes authentication. I am thinking that we could still make the old behavior a possibility if there is a way to intsruct A Leg of the bridge call perform the REFER instead of the auto-attendant leg sending it. Is this possible? Thanks for you patience. Joegen On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote: > I don't quite get what you are saying but.. > Can't you define credentials in FS as noreg gateway and match it up to > the challenge realm? > > > On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor > wrote: > >> Hi, >> >> Following Anthonys advise to configure a bridged dial plan infront of >> sipX socket based apps proves to be a reasonable approach to let >> attended transfer work for our apps. However, bridged dial plans for >> the auto-attendant has a side effect. sipX uses blind transfer to >> forward a caller to its intended destination. sipX proxy would then >> authenticate the user if it has proper permission to reach the resource >> as it receives to new INVITE as a result of the blind transfer. Since >> the call is bridged, b-leg will consume the REFER and send its own >> INVITE which doesn't have the notion how to authenticate against sipX. >> My question is is there a way to propagate the REFER to the caller >> instead of being consumed by the bridge? >> >> Thanks for any advise in advance. >> >> Joegen >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > From joegen at opensipstack.org Thu Oct 21 05:12:13 2010 From: joegen at opensipstack.org (Joegen E. Baclor) Date: Thu, 21 Oct 2010 20:12:13 +0800 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: <4CBFAB63.6090408@opensipstack.org> References: <4CBE6AD1.3020403@opensipstack.org> <4CBFAB63.6090408@opensipstack.org> Message-ID: <4CC02E1D.6050105@opensipstack.org> I just saw uuid_deflect in the API reference so i guess this is doable. Is there a means to send the UUID of the bridged call as a uri parameter by simply using the XML dialplan? If not I guess I have to create a new socket app just the do the bridging. On Thursday, 21 October, 2010 10:54 AM, Joegen E. Baclor wrote: > Hi Anthony sorry for being vague. The call flow i am experimenting on > looks like this > > 1. UA1 -> sipXproxy -> [FS (bridged-dial-plan)] -> [FS > (auto-attendant-socket dial-plan)] > 2. [FS (auto-attendant-socket dial-plan]) sends REFER to [FS > (bridged-dial-plan)] > 3. B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE > to Refer-to URI via sipXproxy > > The way sipX does this right now is REFER is actually processed by UA1. > Having [FS (bridged-dial-plan)] breaks this. > > I have reason to believe that the ultimate answer to my previous > question would be a no. Replicating authentication credentials would be > costly as well as create a security hole since any UA which has a valid > extension in the from URI can now make calls through the AA without > being challenged since FS assumes authentication. > > I am thinking that we could still make the old behavior a possibility if > there is a way to intsruct A Leg of the bridge call perform the REFER > instead of the auto-attendant leg sending it. Is this possible? > > Thanks for you patience. > > Joegen > > > On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote: > >> I don't quite get what you are saying but.. >> Can't you define credentials in FS as noreg gateway and match it up to >> the challenge realm? >> >> >> On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor >> wrote: >> >> >>> Hi, >>> >>> Following Anthonys advise to configure a bridged dial plan infront of >>> sipX socket based apps proves to be a reasonable approach to let >>> attended transfer work for our apps. However, bridged dial plans for >>> the auto-attendant has a side effect. sipX uses blind transfer to >>> forward a caller to its intended destination. sipX proxy would then >>> authenticate the user if it has proper permission to reach the resource >>> as it receives to new INVITE as a result of the blind transfer. Since >>> the call is bridged, b-leg will consume the REFER and send its own >>> INVITE which doesn't have the notion how to authenticate against sipX. >>> My question is is there a way to propagate the REFER to the caller >>> instead of being consumed by the bridge? >>> >>> Thanks for any advise in advance. >>> >>> Joegen >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > From peter.olsson at visionutveckling.se Thu Oct 21 05:21:22 2010 From: peter.olsson at visionutveckling.se (Peter Olsson) Date: Thu, 21 Oct 2010 14:21:22 +0200 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: <4CC02E1D.6050105@opensipstack.org> References: <4CBE6AD1.3020403@opensipstack.org> <4CBFAB63.6090408@opensipstack.org> <4CC02E1D.6050105@opensipstack.org> Message-ID: <549CFEF87AEDE841A38E9D15EAB4C04C57E623C4DB@cooper> Just call "deflect" in dialplan, with new destination as parameter (sip:xxx at domain.com) /Peter -----Ursprungligt meddelande----- Fr?n: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] F?r Joegen E. Baclor Skickat: den 21 oktober 2010 14:12 Till: freeswitch-dev at lists.freeswitch.org ?mne: Re: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem I just saw uuid_deflect in the API reference so i guess this is doable. Is there a means to send the UUID of the bridged call as a uri parameter by simply using the XML dialplan? If not I guess I have to create a new socket app just the do the bridging. On Thursday, 21 October, 2010 10:54 AM, Joegen E. Baclor wrote: > Hi Anthony sorry for being vague. The call flow i am experimenting on > looks like this > > 1. UA1 -> sipXproxy -> [FS (bridged-dial-plan)] -> [FS > (auto-attendant-socket dial-plan)] > 2. [FS (auto-attendant-socket dial-plan]) sends REFER to [FS > (bridged-dial-plan)] > 3. B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE > to Refer-to URI via sipXproxy > > The way sipX does this right now is REFER is actually processed by UA1. > Having [FS (bridged-dial-plan)] breaks this. > > I have reason to believe that the ultimate answer to my previous > question would be a no. Replicating authentication credentials would be > costly as well as create a security hole since any UA which has a valid > extension in the from URI can now make calls through the AA without > being challenged since FS assumes authentication. > > I am thinking that we could still make the old behavior a possibility if > there is a way to intsruct A Leg of the bridge call perform the REFER > instead of the auto-attendant leg sending it. Is this possible? > > Thanks for you patience. > > Joegen > > > On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote: > >> I don't quite get what you are saying but.. >> Can't you define credentials in FS as noreg gateway and match it up to >> the challenge realm? >> >> >> On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor >> wrote: >> >> >>> Hi, >>> >>> Following Anthonys advise to configure a bridged dial plan infront of >>> sipX socket based apps proves to be a reasonable approach to let >>> attended transfer work for our apps. However, bridged dial plans for >>> the auto-attendant has a side effect. sipX uses blind transfer to >>> forward a caller to its intended destination. sipX proxy would then >>> authenticate the user if it has proper permission to reach the resource >>> as it receives to new INVITE as a result of the blind transfer. Since >>> the call is bridged, b-leg will consume the REFER and send its own >>> INVITE which doesn't have the notion how to authenticate against sipX. >>> My question is is there a way to propagate the REFER to the caller >>> instead of being consumed by the bridge? >>> >>> Thanks for any advise in advance. >>> >>> Joegen >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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 at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org !DSPAM:4cc02ff332932087729767! From joegen at opensipstack.org Thu Oct 21 05:30:55 2010 From: joegen at opensipstack.org (Joegen E. Baclor) Date: Thu, 21 Oct 2010 20:30:55 +0800 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: <549CFEF87AEDE841A38E9D15EAB4C04C57E623C4DB@cooper> References: <4CBE6AD1.3020403@opensipstack.org> <4CBFAB63.6090408@opensipstack.org> <4CC02E1D.6050105@opensipstack.org> <549CFEF87AEDE841A38E9D15EAB4C04C57E623C4DB@cooper> Message-ID: <4CC0327F.9040506@opensipstack.org> That is actually what's being done now and the problem i am trying to solve. calling deflect in the IVR app will let the bridged call handle the REFER. I need the bridge call to send the REFER in behalf of the IVR. Thus, the IVR needs to know the UUID of the bridge so that it could instruct it to send a REFER via uuid_deflect. On Thursday, 21 October, 2010 08:21 PM, Peter Olsson wrote: > Just call "deflect" in dialplan, with new destination as parameter (sip:xxx at domain.com) > > /Peter > > > -----Ursprungligt meddelande----- > Fr?n: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] F?r Joegen E. Baclor > Skickat: den 21 oktober 2010 14:12 > Till: freeswitch-dev at lists.freeswitch.org > ?mne: Re: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem > > I just saw uuid_deflect in the API reference so i guess this is > doable. Is there a means to send the UUID of the bridged call as a uri > parameter by simply using the XML dialplan? If not I guess I have to > create a new socket app just the do the bridging. > > > On Thursday, 21 October, 2010 10:54 AM, Joegen E. Baclor wrote: > >> Hi Anthony sorry for being vague. The call flow i am experimenting on >> looks like this >> >> 1. UA1 -> sipXproxy -> [FS (bridged-dial-plan)] -> [FS >> (auto-attendant-socket dial-plan)] >> 2. [FS (auto-attendant-socket dial-plan]) sends REFER to [FS >> (bridged-dial-plan)] >> 3. B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE >> to Refer-to URI via sipXproxy >> >> The way sipX does this right now is REFER is actually processed by UA1. >> Having [FS (bridged-dial-plan)] breaks this. >> >> I have reason to believe that the ultimate answer to my previous >> question would be a no. Replicating authentication credentials would be >> costly as well as create a security hole since any UA which has a valid >> extension in the from URI can now make calls through the AA without >> being challenged since FS assumes authentication. >> >> I am thinking that we could still make the old behavior a possibility if >> there is a way to intsruct A Leg of the bridge call perform the REFER >> instead of the auto-attendant leg sending it. Is this possible? >> >> Thanks for you patience. >> >> Joegen >> >> >> On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote: >> >> >>> I don't quite get what you are saying but.. >>> Can't you define credentials in FS as noreg gateway and match it up to >>> the challenge realm? >>> >>> >>> On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor >>> wrote: >>> >>> >>> >>>> Hi, >>>> >>>> Following Anthonys advise to configure a bridged dial plan infront of >>>> sipX socket based apps proves to be a reasonable approach to let >>>> attended transfer work for our apps. However, bridged dial plans for >>>> the auto-attendant has a side effect. sipX uses blind transfer to >>>> forward a caller to its intended destination. sipX proxy would then >>>> authenticate the user if it has proper permission to reach the resource >>>> as it receives to new INVITE as a result of the blind transfer. Since >>>> the call is bridged, b-leg will consume the REFER and send its own >>>> INVITE which doesn't have the notion how to authenticate against sipX. >>>> My question is is there a way to propagate the REFER to the caller >>>> instead of being consumed by the bridge? >>>> >>>> Thanks for any advise in advance. >>>> >>>> Joegen >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at 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 at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > !DSPAM:4cc02ff332932087729767! > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > From anthony.minessale at gmail.com Thu Oct 21 10:17:08 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Thu, 21 Oct 2010 12:17:08 -0500 Subject: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem In-Reply-To: <4CC0327F.9040506@opensipstack.org> References: <4CBE6AD1.3020403@opensipstack.org> <4CBFAB63.6090408@opensipstack.org> <4CC02E1D.6050105@opensipstack.org> <549CFEF87AEDE841A38E9D15EAB4C04C57E623C4DB@cooper> <4CC0327F.9040506@opensipstack.org> Message-ID: try on latest, I added a patch to pass indications in that mode over to the host channel. On Thu, Oct 21, 2010 at 7:30 AM, Joegen E. Baclor wrote: > That is actually what's being done now and the problem i am trying to > solve. ?calling deflect in the IVR app will let the bridged call handle > the REFER. ?I need the bridge call to send the REFER in behalf of the > IVR. ?Thus, the IVR needs to know the UUID of the bridge so that it > could instruct it to send a REFER via uuid_deflect. > > > On Thursday, 21 October, 2010 08:21 PM, Peter Olsson wrote: >> Just call "deflect" in dialplan, with new destination as parameter (sip:xxx at domain.com) >> >> /Peter >> >> >> -----Ursprungligt meddelande----- >> Fr?n: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] F?r Joegen E. Baclor >> Skickat: den 21 oktober 2010 14:12 >> Till: freeswitch-dev at lists.freeswitch.org >> ?mne: Re: [Freeswitch-dev] Bridge dialplan to sipx IVR services problem >> >> I just saw uuid_deflect in the API reference so i guess this is >> doable. ? Is there a means to send the UUID of the bridged call as a uri >> parameter by simply using the XML dialplan? ?If not I guess I have to >> create a new socket app just the do the bridging. >> >> >> On Thursday, 21 October, 2010 10:54 AM, Joegen E. Baclor wrote: >> >>> Hi Anthony sorry for being vague. ?The call flow i am experimenting on >>> looks like this >>> >>> 1. ?UA1 -> ? ?sipXproxy -> ? [FS (bridged-dial-plan)] -> ? [FS >>> (auto-attendant-socket dial-plan)] >>> 2. ?[FS (auto-attendant-socket dial-plan]) sends REFER to [FS >>> (bridged-dial-plan)] >>> 3. ?B-Leg of [FS (bridged-dial-plan)] consumes REFER and sends INVITE >>> to ?Refer-to URI via sipXproxy >>> >>> The way sipX does this right now is REFER is actually processed by UA1. >>> Having [FS (bridged-dial-plan)] breaks this. >>> >>> I have reason to believe that the ultimate answer to my previous >>> question would be a no. ?Replicating authentication credentials would be >>> costly as well as create a security hole since any UA which has a valid >>> extension in the from URI can now make calls through the AA without >>> being challenged since FS assumes authentication. >>> >>> I am thinking that we could still make the old behavior a possibility if >>> there is a way to intsruct A Leg of the bridge call perform the REFER >>> instead of the auto-attendant leg sending it. ?Is this possible? >>> >>> Thanks for you patience. >>> >>> Joegen >>> >>> >>> On Wednesday, 20 October, 2010 11:07 PM, Anthony Minessale wrote: >>> >>> >>>> I don't quite get what you are saying but.. >>>> Can't you define credentials in FS as noreg gateway and match it up to >>>> the challenge realm? >>>> >>>> >>>> On Tue, Oct 19, 2010 at 11:06 PM, Joegen E. Baclor >>>> ? ?wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> Following Anthonys advise to configure a bridged dial plan infront of >>>>> sipX socket based apps proves to be a reasonable approach to let >>>>> attended transfer work for our apps. ?However, bridged dial plans for >>>>> the auto-attendant has a side effect. ?sipX uses blind transfer to >>>>> forward a caller to its intended destination. ?sipX proxy would then >>>>> authenticate the user ?if it has proper permission to reach the resource >>>>> as it receives to new INVITE as a result of the blind transfer. ?Since >>>>> the call is bridged, b-leg will consume the REFER and send its own >>>>> INVITE which doesn't have the notion how to authenticate against sipX. >>>>> My question is is there a way to propagate the REFER to the caller >>>>> instead of being consumed by the bridge? >>>>> >>>>> Thanks for any advise in advance. >>>>> >>>>> Joegen >>>>> >>>>> _______________________________________________ >>>>> FreeSWITCH-dev mailing list >>>>> FreeSWITCH-dev at 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 at 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 at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> !DSPAM:4cc02ff332932087729767! >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Fri Oct 22 12:25:47 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Fri, 22 Oct 2010 15:25:47 -0400 Subject: [Freeswitch-dev] presence direction incorrect? In-Reply-To: References: Message-ID: I'm sure it is wrong. I have SUBSCRIBEd for dialog events from both the FS extension and a Polycom set. The Polycom correctly marks dialogs for calls it made as "initiator", and for calls it received as "recipient". The FS extension reports the same dialogs with the same direction, which clearly does not make sense (both ends cannot be the initiator). I'm not surprised that BLF applications don't care about the direction. There are a lot of fields in a dialog event that won't matter to many applications, but they should be correct for the applications that do care, such as one that wants to be able to pick up the call. Carolyn -----Original Message----- From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Wednesday, October 20, 2010 4:35 PM To: freeswitch-dev at lists.freeswitch.org Subject: Re: [Freeswitch-dev] presence direction incorrect? It may be wrong so I can't be sure enough to argue but this is how it works properly for BLF you need to make sure that change works for that too. Did you find some dialog-info driven phones and use the blf features to make sure they continue to work per our initial conversation? On Wed, Oct 20, 2010 at 1:23 PM, Beeton, Carolyn (Carolyn) wrote: > One more thing: the "direction" contained in the dialog NOTIFYs is > backwards, I think: > > if (!strcasecmp(direction, "outbound")) { > ??? direction = "recipient"; > ??? dft_state = "early"; > } else { > ??? direction = "initiator"; > ??? dft_state = "confirmed"; > } > > should be either comparing on "inbound" or switched around.? I am > seeing inbound dialogs being marked "initiator".? The observed user > (the internal FS extension) was the recipient of the call. > > "This attribute is either initiator or recipient, and > indicates whether the observed user was the initiator of the > dialog, or the recipient of the INVITE that created it." > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From paulo at voicetechnology.com.br Fri Oct 22 13:09:29 2010 From: paulo at voicetechnology.com.br (=?ISO-8859-1?Q?Paulo_Rog=E9rio_Panhoto?=) Date: Fri, 22 Oct 2010 18:09:29 -0200 Subject: [Freeswitch-dev] Getting DTMF from channel. Message-ID: <4CC1EF79.7040409@voicetechnology.com.br> Hi, I'm writing a module that allows playback of MP4 video files (with libmp4v2). The playback itself is made by two functions ready to run on separate threads (though, audio runs on current thread and video runs on a separate one). At this point, I'm trying to implement dtmf cut-through. After some research (I checked out mod_dptools.c and switch_ivr_play_say.c) and this code was my best guess -- it runs on the audio stream: if(switch_channel_test_flag(pt->channel, CF_BREAK)) { switch_channel_clear_flag(pt->channel, CF_BREAK); break; } switch_ivr_parse_all_events(pt->session); if(switch_channel_has_dtmf(pt->channel)) { switch_channel_dequeue_dtmf(pt->channel, &dtmf); const char * terminators = switch_channel_get_variable(pt->channel, SWITCH_PLAYBACK_TERMINATORS_VARIABLE); if(terminators && !strcasecmp(terminators, "none")) terminators = NULL; switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(pt->session), SWITCH_LOG_DEBUG, "Digit %c\n", dtmf.digit); if(terminators && strchr(terminators, dtmf.digit)) { std::string digit(&dtmf.digit, 0, 1); switch_channel_set_variable(pt->channel, SWITCH_PLAYBACK_TERMINATOR_USED, digit.c_str()); break; } } Which didn't work. I'm asking if anyone has any idea. Any help is appreciated Regards, Paulo R. Panhoto From anthony.minessale at gmail.com Fri Oct 22 13:18:28 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 22 Oct 2010 15:18:28 -0500 Subject: [Freeswitch-dev] presence direction incorrect? In-Reply-To: References: Message-ID: You are thinking in your paradigm instead of ours. We consider the thing you are monitoring from FS perspective, the invite to/from FS and the phone. This is because there are 2 legs when you monitor the ext on FS you are monitoring the users relationship to FS. When there is an inbound call to x1000 it's really an outbound call to the phone which we are showing as an outbound call ringing. try the patch I added to latest where when it's your new brand of non-registered entities, it forces the perspective to be reversed On Fri, Oct 22, 2010 at 2:25 PM, Beeton, Carolyn (Carolyn) wrote: > I'm sure it is wrong. ?I have SUBSCRIBEd for dialog events from both the FS extension and a Polycom set. ?The Polycom correctly marks dialogs for calls it made as "initiator", and for calls it received as "recipient". ?The FS extension reports the same dialogs with the same direction, which clearly does not make sense (both ends cannot be the initiator). ?I'm not surprised that BLF applications don't care about the direction. ?There are a lot of fields in a dialog event that won't matter to many applications, but they should be correct for the applications that do care, such as one that wants to be able to pick up the call. > > Carolyn > > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony Minessale > Sent: Wednesday, October 20, 2010 4:35 PM > To: freeswitch-dev at lists.freeswitch.org > Subject: Re: [Freeswitch-dev] presence direction incorrect? > > It may be wrong so I can't be sure enough to argue but this is how it works properly for BLF you need to make sure that change works for that too. > Did you find some dialog-info driven phones and use the blf features to make sure they continue to work per our initial conversation? > > > > On Wed, Oct 20, 2010 at 1:23 PM, Beeton, Carolyn (Carolyn) wrote: >> One more thing: the "direction" contained in the dialog NOTIFYs is >> backwards, I think: >> >> if (!strcasecmp(direction, "outbound")) { >> ??? direction = "recipient"; >> ??? dft_state = "early"; >> } else { >> ??? direction = "initiator"; >> ??? dft_state = "confirmed"; >> } >> >> should be either comparing on "inbound" or switched around.? I am >> seeing inbound dialogs being marked "initiator".? The observed user >> (the internal FS extension) was the recipient of the call. >> >> "This attribute is either initiator or recipient, and >> ? ? ? ? ?indicates whether the observed user was the initiator of the >> ? ? ? ? ?dialog, or the recipient of the INVITE that created it." >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From anthony.minessale at gmail.com Fri Oct 22 13:38:32 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 22 Oct 2010 15:38:32 -0500 Subject: [Freeswitch-dev] Getting DTMF from channel. In-Reply-To: <4CC1EF79.7040409@voicetechnology.com.br> References: <4CC1EF79.7040409@voicetechnology.com.br> Message-ID: maybe if you post the module for contribution we can add it to FS and figure it out by looking in the code to make it do what you want. 2010/10/22 Paulo Rog?rio Panhoto : > ? ?Hi, > > ? ?I'm writing a module that allows playback of MP4 video files (with > libmp4v2). The playback itself is made by two functions ready to run on > separate threads (though, audio runs on current thread and video runs on > a separate one). At this point, I'm trying to implement dtmf cut-through. > > ? ?After some research (I checked out mod_dptools.c and > switch_ivr_play_say.c) and this code was my best guess -- it runs on the > audio stream: > > ? ? ? ?if(switch_channel_test_flag(pt->channel, CF_BREAK)) > ? ? ? ?{ > ? ? ? ? ? ?switch_channel_clear_flag(pt->channel, CF_BREAK); > ? ? ? ? ? ?break; > ? ? ? ?} > > ? ? ? ?switch_ivr_parse_all_events(pt->session); > > ? ? ? ?if(switch_channel_has_dtmf(pt->channel)) > ? ? ? ?{ > ? ? ? ? ? ?switch_channel_dequeue_dtmf(pt->channel, &dtmf); > ? ? ? ? ? ?const char * terminators = > switch_channel_get_variable(pt->channel, > SWITCH_PLAYBACK_TERMINATORS_VARIABLE); > ? ? ? ? ? ?if(terminators && !strcasecmp(terminators, "none")) > terminators = NULL; > ? ? ? ? ? ?switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(pt->session), > SWITCH_LOG_DEBUG, "Digit %c\n", dtmf.digit); > ? ? ? ? ? ?if(terminators && strchr(terminators, dtmf.digit)) > ? ? ? ? ? ?{ > ? ? ? ? ? ? ? ?std::string digit(&dtmf.digit, 0, 1); > ? ? ? ? ? ? ? ?switch_channel_set_variable(pt->channel, > SWITCH_PLAYBACK_TERMINATOR_USED, digit.c_str()); > ? ? ? ? ? ? ? ?break; > ? ? ? ? ? ?} > ? ? ? ?} > > ? ?Which didn't work. I'm asking if anyone has any idea. > > ? ?Any help is appreciated > > ? ?Regards, > > ? ?Paulo R. Panhoto > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From paulo at voicetechnology.com.br Fri Oct 22 14:09:37 2010 From: paulo at voicetechnology.com.br (=?ISO-8859-1?Q?Paulo_Rog=E9rio_Panhoto?=) Date: Fri, 22 Oct 2010 19:09:37 -0200 Subject: [Freeswitch-dev] Getting DTMF from channel. In-Reply-To: References: <4CC1EF79.7040409@voicetechnology.com.br> Message-ID: <4CC1FD91.8020000@voicetechnology.com.br> I really want to post it as contribution but I don't know how the process works. So, in the meantine, it is already published on github git://github.com/ppanhoto/Freeswitch-mod_mp4.git Regards, Paulo. On 22/10/10 18:38, Anthony Minessale wrote: > maybe if you post the module for contribution we can add it to FS and > figure it out by looking in the code to make it do what you want. > > > 2010/10/22 Paulo Rog?rio Panhoto : > >> Hi, >> >> I'm writing a module that allows playback of MP4 video files (with >> libmp4v2). The playback itself is made by two functions ready to run on >> separate threads (though, audio runs on current thread and video runs on >> a separate one). At this point, I'm trying to implement dtmf cut-through. >> >> After some research (I checked out mod_dptools.c and >> switch_ivr_play_say.c) and this code was my best guess -- it runs on the >> audio stream: >> >> if(switch_channel_test_flag(pt->channel, CF_BREAK)) >> { >> switch_channel_clear_flag(pt->channel, CF_BREAK); >> break; >> } >> >> switch_ivr_parse_all_events(pt->session); >> >> if(switch_channel_has_dtmf(pt->channel)) >> { >> switch_channel_dequeue_dtmf(pt->channel, &dtmf); >> const char * terminators = >> switch_channel_get_variable(pt->channel, >> SWITCH_PLAYBACK_TERMINATORS_VARIABLE); >> if(terminators && !strcasecmp(terminators, "none")) >> terminators = NULL; >> switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(pt->session), >> SWITCH_LOG_DEBUG, "Digit %c\n", dtmf.digit); >> if(terminators && strchr(terminators, dtmf.digit)) >> { >> std::string digit(&dtmf.digit, 0, 1); >> switch_channel_set_variable(pt->channel, >> SWITCH_PLAYBACK_TERMINATOR_USED, digit.c_str()); >> break; >> } >> } >> >> Which didn't work. I'm asking if anyone has any idea. >> >> Any help is appreciated >> >> Regards, >> >> Paulo R. Panhoto >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > From anthony.minessale at gmail.com Fri Oct 22 14:47:59 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 22 Oct 2010 16:47:59 -0500 Subject: [Freeswitch-dev] Getting DTMF from channel. In-Reply-To: <4CC1FD91.8020000@voicetechnology.com.br> References: <4CC1EF79.7040409@voicetechnology.com.br> <4CC1FD91.8020000@voicetechnology.com.br> Message-ID: Ok let's work on that. email consulting at freeswitch.org and ask for GIT commit to a dir for that module and we can get you a dir. Once its building on latest GIT, we can dig into it and get DTMF working. 2010/10/22 Paulo Rog?rio Panhoto : > ? ?I really want to post it as contribution but I don't know how the > process works. So, in the meantine, it is already published on github > > git://github.com/ppanhoto/Freeswitch-mod_mp4.git > > ? ?Regards, > > ? ?Paulo. > > On 22/10/10 18:38, Anthony Minessale wrote: >> maybe if you post the module for contribution we can add it to FS and >> figure it out by looking in the code to make it do what you want. >> >> >> 2010/10/22 Paulo Rog?rio Panhoto : >> >>> ? ?Hi, >>> >>> ? ?I'm writing a module that allows playback of MP4 video files (with >>> libmp4v2). The playback itself is made by two functions ready to run on >>> separate threads (though, audio runs on current thread and video runs on >>> a separate one). At this point, I'm trying to implement dtmf cut-through. >>> >>> ? ?After some research (I checked out mod_dptools.c and >>> switch_ivr_play_say.c) and this code was my best guess -- it runs on the >>> audio stream: >>> >>> ? ? ? ?if(switch_channel_test_flag(pt->channel, CF_BREAK)) >>> ? ? ? ?{ >>> ? ? ? ? ? ?switch_channel_clear_flag(pt->channel, CF_BREAK); >>> ? ? ? ? ? ?break; >>> ? ? ? ?} >>> >>> ? ? ? ?switch_ivr_parse_all_events(pt->session); >>> >>> ? ? ? ?if(switch_channel_has_dtmf(pt->channel)) >>> ? ? ? ?{ >>> ? ? ? ? ? ?switch_channel_dequeue_dtmf(pt->channel, &dtmf); >>> ? ? ? ? ? ?const char * terminators = >>> switch_channel_get_variable(pt->channel, >>> SWITCH_PLAYBACK_TERMINATORS_VARIABLE); >>> ? ? ? ? ? ?if(terminators && !strcasecmp(terminators, "none")) >>> terminators = NULL; >>> ? ? ? ? ? ?switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(pt->session), >>> SWITCH_LOG_DEBUG, "Digit %c\n", dtmf.digit); >>> ? ? ? ? ? ?if(terminators && strchr(terminators, dtmf.digit)) >>> ? ? ? ? ? ?{ >>> ? ? ? ? ? ? ? ?std::string digit(&dtmf.digit, 0, 1); >>> ? ? ? ? ? ? ? ?switch_channel_set_variable(pt->channel, >>> SWITCH_PLAYBACK_TERMINATOR_USED, digit.c_str()); >>> ? ? ? ? ? ? ? ?break; >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> >>> ? ?Which didn't work. I'm asking if anyone has any idea. >>> >>> ? ?Any help is appreciated >>> >>> ? ?Regards, >>> >>> ? ?Paulo R. Panhoto >>> >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From jan.berger at video24.no Sun Oct 24 06:07:43 2010 From: jan.berger at video24.no (Jan Berger) Date: Sun, 24 Oct 2010 15:07:43 +0200 Subject: [Freeswitch-dev] FS Integrator needed Message-ID: <2DE88A91A9A34BA8B046226C470486C5@dell9400> Hi folks, I am looking for a developer willing to take on a task to integrate FS with the CCXML/VXML engine on www.video24.no Your first task will be to map the 2 API's - this is more documentation than actual work - I will suggest you just write a small module and start testing one even at the time. CCXML/VXML requires a list of telecom-events that must be supported in FS. A majority of the events exist, but some do not. So - this is in "theory" a small task of mapping events between 2 API's - with some extras Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101024/a679c8a8/attachment-0001.html From mnhassan at usa.net Sun Oct 24 06:31:00 2010 From: mnhassan at usa.net (Nyamul Hassan) Date: Sun, 24 Oct 2010 19:31:00 +0600 Subject: [Freeswitch-dev] FS Integrator needed In-Reply-To: <2DE88A91A9A34BA8B046226C470486C5@dell9400> References: <2DE88A91A9A34BA8B046226C470486C5@dell9400> Message-ID: Best help would probably be to contact consulting at freeswitch.org Regards HASSAN On 2010-10-24, Jan Berger wrote: > Hi folks, > > > > I am looking for a developer willing to take on a task to integrate FS with > the CCXML/VXML engine on www.video24.no > > > > Your first task will be to map the 2 API's - this is more documentation than > actual work - I will suggest you just write a small module and start testing > one even at the time. CCXML/VXML requires a list of telecom-events that must > be supported in FS. A majority of the events exist, but some do not. > > > > So - this is in "theory" a small task of mapping events between 2 API's - > with some extras > > > > Jan > > -- Sent from my mobile device From bernhard.suttner at winet.ch Mon Oct 25 09:11:31 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Mon, 25 Oct 2010 18:11:31 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone Message-ID: <20101025181131.45b6a767@mail.winet.ch> Hi, I have the following scenario A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B FS is of course the same Freeswitch Sever. If B sends RINGING to FS the RINGING will not be passed through to A because of the loopback module. (That is was the trace does say). What has to happen on mod_loopback if it does receive the RINGING? Does it have to do something like switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? I think it has maybe something to do with the missing INDICATE_RINGING section in mod_loopback. Best regards, Bernhard Suttner From anthony.minessale at gmail.com Mon Oct 25 10:00:57 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Mon, 25 Oct 2010 12:00:57 -0500 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: <20101025181131.45b6a767@mail.winet.ch> References: <20101025181131.45b6a767@mail.winet.ch> Message-ID: try again on latest HEAD that may have been broken over the weekend. On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner wrote: > Hi, > > I have the following scenario > > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B > > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the RINGING will not be passed through to A because of the loopback module. (That is was the trace does say). What has to happen on mod_loopback if it does receive the RINGING? Does it have to do something like switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? I think it has maybe something to do with the missing INDICATE_RINGING section in mod_loopback. > > Best regards, > Bernhard Suttner > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From bernhard.suttner at winet.ch Mon Oct 25 11:41:18 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Mon, 25 Oct 2010 20:41:18 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone Message-ID: <20101025204118.4e281b00@mail.winet.ch> Hi, thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) Best regards, Bernhard ----- Original Message ----- From: Anthony Minessale [mailto:anthony.minessale at gmail.com] To: freeswitch-dev at lists.freeswitch.org Sent: Mon, 25 Oct 2010 19:00:57 +0200 Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone > try again on latest HEAD that may have been broken over the weekend. > > > On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner > wrote: > > Hi, > > > > I have the following scenario > > > > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B > > > > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the > RINGING will not be passed through to A because of the loopback module. > (That is was the trace does say). What has to happen on mod_loopback if it > does receive the RINGING? Does it have to do something like > switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? > I think it has maybe something to do with the missing INDICATE_RINGING > section in mod_loopback. > > > > Best regards, > > Bernhard Suttner > > > > _______________________________________________ > > FreeSWITCH-dev mailing list > > FreeSWITCH-dev at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Mon Oct 25 12:21:52 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Mon, 25 Oct 2010 14:21:52 -0500 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: <20101025204118.4e281b00@mail.winet.ch> References: <20101025204118.4e281b00@mail.winet.ch> Message-ID: We try. We're not always on top of things as much as we'd like but we sure try =p On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner wrote: > Hi, > > thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. > > Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) > > Best regards, > Bernhard > > > ----- Original Message ----- > From: Anthony Minessale [mailto:anthony.minessale at gmail.com] > To: freeswitch-dev at lists.freeswitch.org > Sent: Mon, 25 Oct 2010 19:00:57 +0200 > Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone > > >> try again on latest HEAD that may have been broken over the weekend. >> >> >> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >> wrote: >> > Hi, >> > >> > I have the following scenario >> > >> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >> > >> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >> RINGING will not be passed through to A because of the loopback module. >> (That is was the trace does say). What has to happen on mod_loopback if it >> does receive the RINGING? Does it have to do something like >> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >> I think it has maybe something to do with the missing INDICATE_RINGING >> section in mod_loopback. >> > >> > Best regards, >> > Bernhard Suttner >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From cbeeton at avaya.com Mon Oct 25 13:03:04 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Mon, 25 Oct 2010 16:03:04 -0400 Subject: [Freeswitch-dev] Presence questions Message-ID: 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: confirmed sip:45 at 47.135.152.158 sip:45 at 47.135.152.158 - ** 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: confirmed sip:45 at 47.135.152.158 sip:46 at 47.135.152.158 - 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 From bernhard.suttner at winet.ch Tue Oct 26 01:09:54 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Tue, 26 Oct 2010 10:09:54 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: References: <20101025204118.4e281b00@mail.winet.ch> Message-ID: <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> Hi, it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. Best regards, Bernhard -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale Gesendet: Montag, 25. Oktober 2010 21:22 An: freeswitch-dev at lists.freeswitch.org Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone We try. We're not always on top of things as much as we'd like but we sure try =p On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner wrote: > Hi, > > thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. > > Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) > > Best regards, > Bernhard > > > ----- Original Message ----- > From: Anthony Minessale [mailto:anthony.minessale at gmail.com] > To: freeswitch-dev at lists.freeswitch.org > Sent: Mon, 25 Oct 2010 19:00:57 +0200 > Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone > > >> try again on latest HEAD that may have been broken over the weekend. >> >> >> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >> wrote: >> > Hi, >> > >> > I have the following scenario >> > >> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >> > >> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >> RINGING will not be passed through to A because of the loopback module. >> (That is was the trace does say). What has to happen on mod_loopback if it >> does receive the RINGING? Does it have to do something like >> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >> I think it has maybe something to do with the missing INDICATE_RINGING >> section in mod_loopback. >> > >> > Best regards, >> > Bernhard Suttner >> > >> > _______________________________________________ >> > FreeSWITCH-dev mailing list >> > FreeSWITCH-dev at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From stamm at lyth.de Tue Oct 26 02:20:08 2010 From: stamm at lyth.de (Achim Stamm) Date: Tue, 26 Oct 2010 11:20:08 +0200 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite Message-ID: <4CC69D48.9060707@lyth.de> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup sofia/internal/50 at 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 at 192.168.1.114 [KILL] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 (sofia/internal/50 at 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 at 192.168.1.114) Ended 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 sofia/internal/50 at 192.168.1.114 SOFIA DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 sofia/internal/50 at 192.168.1.114 Standard DESTROY 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/50 at 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 at 192.168.1.114:52111 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 From stamm at lyth.de Tue Oct 26 02:21:20 2010 From: stamm at lyth.de (Achim Stamm) Date: Tue, 26 Oct 2010 11:21:20 +0200 Subject: [Freeswitch-dev] How to hangup bridged sessions In-Reply-To: References: <4CA605EE.10604@lyth.de> <4CA60DF4.7000801@lyth.de> Message-ID: <4CC69D90.1040907@lyth.de> Anthony Minessale schrieb: > switch_call_cause_t *cancel_cause is the last arg to originate > > switch_call_cause_t cancel_cause = SWITCH_CAUSE_NONE; > > pass &cancel_cause as the final arg to originate. > > if originate is in some other thread you will need to create the > cancel_cause in the other thread and pass it up. > > Then when you change cancel cause to some cause, all sessions in the > originate thread will terminate with that cause. > > > On Fri, Oct 1, 2010 at 11:36 AM, Achim Stamm wrote: > >> Bernhard Suttner schrieb: >> >>> Hi, >>> >>> Did you try to hangup the session (not the peer session). This should freeswitch force to hangup all related channels (the session + the connected sessions). >>> >>> BR, >>> Bernhard >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Achim Stamm >>> Gesendet: Freitag, 1. Oktober 2010 18:02 >>> An: freeswitch-dev at lists.freeswitch.org >>> Betreff: [Freeswitch-dev] How to hangup bridged sessions >>> >>> 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 at 192.168.1.50,user/61 at 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 >>> >>> >>> >> For my special case: >> I need my session alive for doing read and write frame in a while loop. >> After hanging up the peer Sessions. I do an answer (for my session) and >> enter the while loop. >> The "Connection" to another Session (also in a read and write frame >> while loop) is done >> by exchanging manually audio frames. >> >> Thanks for your question. >> >> -- >> 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 >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > > Thanks for Helping. Your solution works fine. 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 From juanito1982 at gmail.com Tue Oct 26 05:30:33 2010 From: juanito1982 at gmail.com (=?ISO-8859-1?Q?Juan_Antonio_Iba=F1ez_Santorum?=) Date: Tue, 26 Oct 2010 14:30:33 +0200 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: <4CC69D48.9060707@lyth.de> References: <4CC69D48.9060707@lyth.de> Message-ID: Usually regarding a codec configuration. Try to test both with g711 Regards 2010/10/26 Achim Stamm > 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel > [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered > 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup > sofia/internal/50 at 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 at 192.168.1.114 [KILL] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 > (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP > 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP > 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 > sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 > (sofia/internal/50 at 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 at 192.168.1.114) Ended > 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close > Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 > (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 > sofia/internal/50 at 192.168.1.114 SOFIA DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 > sofia/internal/50 at 192.168.1.114 Standard DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 > (sofia/internal/50 at 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 at 192.168.1.114:52111 > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 > sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101026/d02386a5/attachment.html From cbeeton at avaya.com Tue Oct 26 05:47:11 2010 From: cbeeton at avaya.com (Beeton, Carolyn (Carolyn)) Date: Tue, 26 Oct 2010 08:47:11 -0400 Subject: [Freeswitch-dev] Presence questions In-Reply-To: References: Message-ID: This seems to be a Snom issue. On shutdown, FS terminates the subscriptions. Snom doesn't seem to take that as a hint to start a fresh subscription until several minutes later. > -----Original Message----- > From: freeswitch-dev-bounces at lists.freeswitch.org > [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On > Behalf Of Beeton, Carolyn (Carolyn) > > 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. > From anthony.minessale at gmail.com Tue Oct 26 07:09:30 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 09:09:30 -0500 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: <4CC69D48.9060707@lyth.de> References: <4CC69D48.9060707@lyth.de> Message-ID: what is mod_evb? if it's a proprietary endpoint i'd look into that code. On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: > 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel > [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered > 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup > sofia/internal/50 at 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 at 192.168.1.114 [KILL] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 > (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] > 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP > 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP > 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 > sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 > (sofia/internal/50 at 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 at 192.168.1.114) Ended > 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close > Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 > (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 > sofia/internal/50 at 192.168.1.114 SOFIA DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 > sofia/internal/50 at 192.168.1.114 Standard DESTROY > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 > (sofia/internal/50 at 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 at 192.168.1.114:52111 > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 > sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] > 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From anthony.minessale at gmail.com Tue Oct 26 07:21:54 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 09:21:54 -0500 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> Message-ID: do you have inbound-bypass-media on? or are you not setting {ignore_early_media=true} when you call loopback The default config ext 9181 demonstrates this functionality and is confirmed to work. On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner wrote: > Hi, > > it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Montag, 25. Oktober 2010 21:22 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > We try. We're not always on top of things as much as we'd like but we > sure try =p > > > On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner > wrote: >> Hi, >> >> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >> >> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >> >> Best regards, >> Bernhard >> >> >> ----- Original Message ----- >> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >> To: freeswitch-dev at lists.freeswitch.org >> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> >>> try again on latest HEAD that may have been broken over the weekend. >>> >>> >>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>> wrote: >>> > Hi, >>> > >>> > I have the following scenario >>> > >>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>> > >>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>> RINGING will not be passed through to A because of the loopback module. >>> (That is was the trace does say). What has to happen on mod_loopback if it >>> does receive the RINGING? Does it have to do something like >>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>> I think it has maybe something to do with the missing INDICATE_RINGING >>> section in mod_loopback. >>> > >>> > Best regards, >>> > Bernhard Suttner >>> > >>> > _______________________________________________ >>> > FreeSWITCH-dev mailing list >>> > FreeSWITCH-dev at 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/ >>> Twitter: http://twitter.com/FreeSWITCH_wire >>> >>> AIM: anthm >>> MSN:anthony_minessale at hotmail.com >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>> IRC: irc.freenode.net #freeswitch >>> >>> FreeSWITCH Developer Conference >>> sip:888 at conference.freeswitch.org >>> googletalk:conf+888 at conference.freeswitch.org >>> pstn:+19193869900 >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From stamm at lyth.de Tue Oct 26 07:34:44 2010 From: stamm at lyth.de (Achim Stamm) Date: Tue, 26 Oct 2010 16:34:44 +0200 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: References: <4CC69D48.9060707@lyth.de> Message-ID: <4CC6E704.2020707@lyth.de> Anthony Minessale schrieb: > what is mod_evb? if it's a proprietary endpoint i'd look into that code. > > > On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: > >> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >> 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel >> [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered >> 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup >> sofia/internal/50 at 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 at 192.168.1.114 [KILL] >> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 >> (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] >> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP >> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >> sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP >> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >> sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 >> sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 >> (sofia/internal/50 at 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 at 192.168.1.114) Ended >> 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close >> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 >> (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY >> 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 >> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 >> sofia/internal/50 at 192.168.1.114 Standard DESTROY >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 >> (sofia/internal/50 at 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 at 192.168.1.114:52111 >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 >> sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > > Hello Anthony, mod_ebv is an own module implementation. Here 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 at 192.168.1.114,user/61 at 192.168.1.114", timelimit, NULL, NULL, NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) Both Phones with number 60 and 61 rings. The problem with INCOMPATIBLE_DESTINATION occurs also with two X-Lites. 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 From anthony.minessale at gmail.com Tue Oct 26 07:53:34 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 09:53:34 -0500 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: <4CC6E704.2020707@lyth.de> References: <4CC69D48.9060707@lyth.de> <4CC6E704.2020707@lyth.de> Message-ID: Well then you should show a log of it happening with 2 x-lites then. On Tue, Oct 26, 2010 at 9:34 AM, Achim Stamm wrote: > Anthony Minessale schrieb: >> what is mod_evb? if it's a proprietary endpoint i'd look into that code. >> >> >> On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: >> >>> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>> 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel >>> [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered >>> 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup >>> sofia/internal/50 at 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 at 192.168.1.114 [KILL] >>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 >>> (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] >>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>> (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>> (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP >>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>> sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP >>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>> sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>> (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 >>> sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 >>> (sofia/internal/50 at 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 at 192.168.1.114) Ended >>> 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close >>> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 >>> (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY >>> 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 >>> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 >>> sofia/internal/50 at 192.168.1.114 Standard DESTROY >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 >>> (sofia/internal/50 at 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 at 192.168.1.114:52111 >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 >>> sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>> (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 >>> >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>> http://www.freeswitch.org >>> >>> >> >> >> >> > Hello Anthony, > > mod_ebv is an own module implementation. > Here 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 at 192.168.1.114,user/61 at 192.168.1.114", timelimit, NULL, NULL, > NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) > > Both Phones with number 60 and 61 rings. > The problem with INCOMPATIBLE_DESTINATION occurs also with two X-Lites. > > 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From frode.isaksen at bewan.com Wed Oct 13 23:30:43 2010 From: frode.isaksen at bewan.com (Frode Isaksen) Date: Thu, 14 Oct 2010 08:30:43 +0200 Subject: [Freeswitch-dev] Searching for a valid extension In-Reply-To: References: Message-ID: <96A47145-D9B6-4F12-9F70-2FB82DEB4859@bewan.com> Le 13 oct. 2010 ? 21:48, freeswitch-dev-request at lists.freeswitch.org a ?crit : > There is no such function now in the core but we can work together to > implement one. There was some though on this in > http://jira.freeswitch.org/browse/FS-477. We need a way to be able to > call 123 as well as 1234/ Hello all, I have solved this by starting a timer for each digit pressed and matching with something like ^(\d+)T$ or ^(\d{4,10})T$ and appending a 'T' to the destination_number when the timer expires. Frode From amkusmirek at gmail.com Sat Oct 23 11:47:51 2010 From: amkusmirek at gmail.com (=?ISO-8859-2?Q?Adam_Ku=B6mirek?=) Date: Sat, 23 Oct 2010 20:47:51 +0200 Subject: [Freeswitch-dev] VLAN support in sofia module Message-ID: Hi All I would like to run FreeSwitch as SBC in my network. I have architecture with all clients connected via separate vlans. It gives me possibility to use one ip address for all clients, but I need FS sofia profile to bind to specific interface (eg eth0:20 vlan 20) and global ip address. As I see, for now sofia module allows to bind to ip address only. I looked quickly to sourcees and it seems that this is limited by sofia library. Of course i may be wrong because I'm new to FS and didn't have time to analyze sources. Please, write some words on this topic. Do you have plans to implement vlan support in FS. I know that AcmePacket Net-Net gives such feature. Don't know any open voip solution with this iplemented. Regards Adam From mark.duling at biola.edu Mon Oct 25 18:21:15 2010 From: mark.duling at biola.edu (Mark Duling) Date: Mon, 25 Oct 2010 18:21:15 -0700 Subject: [Freeswitch-dev] Installing Freeswitch with non-default paths Message-ID: Hello, I can install freeswitch to the default path and it works using the tarball snapshot, but I really want to install it using configure switches (--bindir, --libdir, --with-modinstdir, etc). But when I install using non-default paths I get the following errors when starting freeswitch, and even starting it with CLI switches ('sudo freeswitch -conf ... -mod ...) does not seem to help. Is there a path bug such that some parts of the installed software don't get the memo that a non-default path was set? 2010-10-25 18:00:42.223012 [CONSOLE] switch_core.c:1596 Loading Modules. 2010-10-25 18:00:42.223261 [CRIT] switch_loadable_module.c:926 Error Loading module /CORE_SOFTTIMER_MODULE.so **dlopen(/CORE_SOFTTIMER_MODULE.so, 6): image not found** 2010-10-25 18:00:42.223338 [CRIT] switch_loadable_module.c:926 Error Loading module /CORE_PCM_MODULE.so **dlopen(/CORE_PCM_MODULE.so, 6): image not found** Thank you. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101025/121df4d7/attachment.html From bernhard.suttner at winet.ch Tue Oct 26 08:48:33 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Tue, 26 Oct 2010 17:48:33 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> Message-ID: <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> Hi, I have not activated inbound-bypass-media and I tried with ignore-eary-media set to true and to false. Both times, I have no ringback. I added some debug stuff within mod_loopback.c and saw, that the code after switch_core_session_get_partner will not be called for msg->message_id = 7. Best regards, Bernhard -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale Gesendet: Dienstag, 26. Oktober 2010 16:22 An: freeswitch-dev at lists.freeswitch.org Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone do you have inbound-bypass-media on? or are you not setting {ignore_early_media=true} when you call loopback The default config ext 9181 demonstrates this functionality and is confirmed to work. On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner wrote: > Hi, > > it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Montag, 25. Oktober 2010 21:22 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > We try. We're not always on top of things as much as we'd like but we > sure try =p > > > On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner > wrote: >> Hi, >> >> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >> >> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >> >> Best regards, >> Bernhard >> >> >> ----- Original Message ----- >> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >> To: freeswitch-dev at lists.freeswitch.org >> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> >>> try again on latest HEAD that may have been broken over the weekend. >>> >>> >>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>> wrote: >>> > Hi, >>> > >>> > I have the following scenario >>> > >>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>> > >>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>> RINGING will not be passed through to A because of the loopback module. >>> (That is was the trace does say). What has to happen on mod_loopback if it >>> does receive the RINGING? Does it have to do something like >>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>> I think it has maybe something to do with the missing INDICATE_RINGING >>> section in mod_loopback. >>> > >>> > Best regards, >>> > Bernhard Suttner >>> > >>> > _______________________________________________ >>> > FreeSWITCH-dev mailing list >>> > FreeSWITCH-dev at 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/ >>> Twitter: http://twitter.com/FreeSWITCH_wire >>> >>> AIM: anthm >>> MSN:anthony_minessale at hotmail.com >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>> IRC: irc.freenode.net #freeswitch >>> >>> FreeSWITCH Developer Conference >>> sip:888 at conference.freeswitch.org >>> googletalk:conf+888 at conference.freeswitch.org >>> pstn:+19193869900 >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From stamm at lyth.de Tue Oct 26 08:51:04 2010 From: stamm at lyth.de (Achim Stamm) Date: Tue, 26 Oct 2010 17:51:04 +0200 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: References: <4CC69D48.9060707@lyth.de> <4CC6E704.2020707@lyth.de> Message-ID: <4CC6F8E8.4060308@lyth.de> Anthony Minessale schrieb: > Well then you should show a log of it happening with 2 x-lites then. > > > > On Tue, Oct 26, 2010 at 9:34 AM, Achim Stamm wrote: > >> Anthony Minessale schrieb: >> >>> what is mod_evb? if it's a proprietary endpoint i'd look into that code. >>> >>> >>> On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: >>> >>> >>>> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>> 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel >>>> [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered >>>> 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup >>>> sofia/internal/50 at 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 at 192.168.1.114 [KILL] >>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 >>>> (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] >>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>> (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>> (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP >>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>> sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP >>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>> sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>> (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 >>>> sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 >>>> (sofia/internal/50 at 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 at 192.168.1.114) Ended >>>> 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close >>>> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 >>>> (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY >>>> 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 >>>> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 >>>> sofia/internal/50 at 192.168.1.114 Standard DESTROY >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 >>>> (sofia/internal/50 at 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 at 192.168.1.114:52111 >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 >>>> sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>> (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 >>>> >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at lists.freeswitch.org >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>> http://www.freeswitch.org >>>> >>>> >>>> >>> >>> >>> >> Hello Anthony, >> >> mod_ebv is an own module implementation. >> Here 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 at 192.168.1.114,user/61 at 192.168.1.114", timelimit, NULL, NULL, >> NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) >> >> Both Phones with number 60 and 61 rings. >> The problem with INCOMPATIBLE_DESTINATION occurs also with two X-Lites. >> >> 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 >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > > Here is a full Log with two X-Lites: EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_audiosync=10) 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [ebv_audiosync]=[10] EXECUTE sofia/internal/50 at 192.168.1.114 set(call_timeout=120) 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [call_timeout]=[120] EXECUTE sofia/internal/50 at 192.168.1.114 set(hangup_after_bridge=false) 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [hangup_after_bridge]=[false] EXECUTE sofia/internal/50 at 192.168.1.114 set(ignore_early_media=true) 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [ignore_early_media]=[true] 2010-10-26 16:12:35.687500 [DEBUG] switch_core_session.c:1751 Application easybyvoice Requires media! pre_answering channel sofia/internal/50 at 192.168.1.114 2010-10-26 16:12:35.703125 [INFO] switch_core_session.c:1753 Sending early media 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/internal/50 at 192.168.1.114] 192.168.1.114 port 27666 -> 192.168.1.114 port 51244 codec: 8 ms: 20 2010-10-26 16:12:35.703125 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2010-10-26 16:12:35.703125 [DEBUG] mod_sofia.c:1904 Ring SDP: v=0 o=FreeSWITCH 1288074689 1288074690 IN IP4 192.168.1.114 s=FreeSWITCH c=IN IP4 192.168.1.114 t=0 0 m=audio 27666 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv 2010-10-26 16:12:35.703125 [NOTICE] mod_sofia.c:1907 Pre-Answer sofia/internal/50 at 192.168.1.114! 2010-10-26 16:12:35.703125 [DEBUG] switch_core_session.c:641 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] EXECUTE sofia/internal/50 at 192.168.1.114 easybyvoice(EProcessCallExtern,50,70) 2010-10-26 16:12:35.703125 [DEBUG] sofia.c:4148 Channel sofia/internal/50 at 192.168.1.114 skipping state [early][183] 2010-10-26 16:12:35.718750 [WARNING] mod_ebv.cpp:1536 mod_ebv built 14.04.2010 20:15! 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:1120 Die Nebenstelle [user/60 at 192.168.1.114,user/61 at 192.168.1.114] wird angerufen. 2010-10-26 16:12:35.718750 [INFO] Extension.cpp:481 Mailbox-Timer mit [45] Sekunden wird gestartet. 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:152 Starte Bridge-Call Thread .... 2010-10-26 16:12:35.718750 [DEBUG] switch_ivr_originate.c:1885 variable string 0 = [presence_id=60 at 192.168.1.114] 2010-10-26 16:12:35.734375 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:60 at 192.168.1.101:10488 [11d0f556-8770-408c-be71-f2d5689435d2] 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:3384 (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_NEW -> CS_INIT 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_INIT 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:83 sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA INIT 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:117 (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_INIT -> CS_ROUTING 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT going to sleep 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_ROUTING 2010-10-26 16:12:35.734375 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:60 at 192.168.1.101:10488 entering state [calling][0] 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING 2010-10-26 16:12:35.734375 [DEBUG] switch_ivr_originate.c:1885 variable string 0 = [presence_id=61 at 192.168.1.114] 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:140 sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA ROUTING 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING going to sleep 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_CONSUME_MEDIA 2010-10-26 16:12:35.750000 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:61 at 192.168.1.148:15716 [f56c3295-51e9-4e65-a6b8-d72e8ecc9832] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:3384 (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_NEW -> CS_INIT 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA going to sleep 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_INIT 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:83 sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA INIT 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:117 (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_INIT -> CS_ROUTING 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT going to sleep 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_ROUTING 2010-10-26 16:12:35.750000 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:61 at 192.168.1.148:15716 entering state [calling][0] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:140 sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA ROUTING 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_ROUTING -> CS_CONSUME_MEDIA 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING going to sleep 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_CONSUME_MEDIA 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA going to sleep 2010-10-26 16:12:35.796875 [DEBUG] switch_rtp.c:2066 Correct ip/port confirmed. 2010-10-26 16:12:35.890625 [INFO] sofia.c:662 Update Callee ID to "61" <61> 2010-10-26 16:12:35.906250 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:61 at 192.168.1.148:15716 entering state [proceeding][180] 2010-10-26 16:12:35.906250 [NOTICE] sofia.c:4223 Ring-Ready sofia/internal/sip:61 at 192.168.1.148:15716! 2010-10-26 16:12:36.046875 [INFO] sofia.c:662 Update Callee ID to "60" <60> 2010-10-26 16:12:36.062500 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:60 at 192.168.1.101:10488 entering state [proceeding][180] 2010-10-26 16:12:36.062500 [NOTICE] sofia.c:4223 Ring-Ready sofia/internal/sip:60 at 192.168.1.101:10488! 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:61 at 192.168.1.148:15716 entering state [completing][200] 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4164 Remote SDP: v=0 o=- 5 2 IN IP4 192.168.1.148 s=CounterPath eyeBeam 1.5 c=IN IP4 192.168.1.148 t=0 0 m=audio 32706 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=x-rtp-session-id:7FD79621EBE842499E1736EE7C1A6E58 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel sofia/internal/sip:61 at 192.168.1.148:15716 entering state [ready][200] 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3585 Audio Codec Compare [PCMA:8:8000:20]/[PCMA:8:8000:20] 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2354 Set Codec sofia/internal/sip:61 at 192.168.1.148:15716 PCMA/8000 20 ms 160 samples 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3518 Set 2833 dtmf send payload to 101 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2594 AUDIO RTP [sofia/internal/sip:61 at 192.168.1.148:15716] 192.168.1.114 port 17306 -> 192.168.1.148 port 32706 codec: 8 ms: 20 2010-10-26 16:12:52.859375 [DEBUG] switch_rtp.c:1182 Starting timer [soft] 160 bytes per 20ms 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send payload to 101 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf receive payload to 101 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3079 Hangup sofia/internal/sip:60 at 192.168.1.101:10488 [CS_CONSUME_MEDIA] [LOSE_RACE] 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2324 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [KILL] 2010-10-26 16:12:52.875000 [NOTICE] sofia.c:4733 Channel [sofia/internal/sip:61 at 192.168.1.148:15716] has been answered 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:52.875000 [NOTICE] switch_channel.c:2424 Hangup sofia/internal/50 at 192.168.1.114 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_HANGUP 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/50 at 192.168.1.114 [KILL] 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3111 sofia/internal/50 at 192.168.1.114 Media Establishment Failed. 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_HANGUP 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:1264 leavin ebv_process_call_extern 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3113 Hangup sofia/internal/sip:61 at 192.168.1.148:15716 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION] 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/50 at 192.168.1.114) State EXECUTE going to sleep 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 192.168.1.114) Running State Change CS_HANGUP 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/sip:60 at 192.168.1.101:10488 hanging up, cause: LOSE_RACE 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [KILL] 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3228 Originate Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION] 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:2219 Originate Failed. Cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:154 .... Bridge-Call Thread beendet!! 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel sofia/internal/sip:61 at 192.168.1.148:15716 hanging up, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.890625 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/50 at 192.168.1.114) State HANGUP 2010-10-26 16:12:52.890625 [DEBUG] mod_sofia.c:414 Channel sofia/internal/50 at 192.168.1.114 hanging up, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:467 Sending CANCEL to sofia/internal/sip:60 at 192.168.1.101:10488 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 sofia/internal/sip:60 at 192.168.1.101:10488 Standard HANGUP, cause: LOSE_RACE 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP going to sleep 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_HANGUP -> CS_REPORTING 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_REPORTING 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:53 sofia/internal/sip:60 at 192.168.1.101:10488 Standard REPORTING, cause: LOSE_RACE 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING going to sleep 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_REPORTING -> CS_DESTROY 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1164 Session 62 (sofia/internal/sip:60 at 192.168.1.101:10488) Locked, Waiting on external entities 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:457 Sending BYE to sofia/internal/sip:61 at 192.168.1.148:15716 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 sofia/internal/sip:61 at 192.168.1.148:15716 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP going to sleep 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_HANGUP -> CS_REPORTING 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_REPORTING 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:53 sofia/internal/sip:61 at 192.168.1.148:15716 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING going to sleep 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_REPORTING -> CS_DESTROY 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1164 Session 63 (sofia/internal/sip:61 at 192.168.1.148:15716) Locked, Waiting on external entities 2010-10-26 16:12:52.921875 [DEBUG] mod_sofia.c:476 Responding to INVITE with: 488 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:46 sofia/internal/50 at 192.168.1.114 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/50 at 192.168.1.114) State HANGUP going to sleep 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/50 at 192.168.1.114) State Change CS_HANGUP -> CS_REPORTING 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 192.168.1.114) Running State Change CS_REPORTING 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/50 at 192.168.1.114) State REPORTING 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:53 sofia/internal/50 at 192.168.1.114 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/50 at 192.168.1.114) State REPORTING going to sleep 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/50 at 192.168.1.114) State Change CS_REPORTING -> CS_DESTROY 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1164 Session 61 (sofia/internal/50 at 192.168.1.114) Locked, Waiting on external entities 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1182 Session 61 (sofia/internal/50 at 192.168.1.114) Ended 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1184 Close Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:428 (sofia/internal/50 at 192.168.1.114) Running State Change CS_DESTROY 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/50 at 192.168.1.114) State DESTROY 2010-10-26 16:12:52.937500 [DEBUG] mod_sofia.c:341 sofia/internal/50 at 192.168.1.114 SOFIA DESTROY 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:60 sofia/internal/50 at 192.168.1.114 Standard DESTROY 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/50 at 192.168.1.114) State DESTROY going to sleep 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 Rejected by acl "domains". Falling back to Digest auth. 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 Rejected by acl "domains". Falling back to Digest auth. 2010-10-26 16:13:04.312500 [NOTICE] switch_channel.c:669 New Channel sofia/internal/50 at 192.168.1.114 [164c4fd7-a814-4dc1-af21-585c313914c4] 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 192.168.1.114) Running State Change CS_NEW 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/50 at 192.168.1.114) State NEW 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4153 Channel sofia/internal/50 at 192.168.1.114 entering state [received][100] 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4164 Remote SDP: v=0 o=- 6 2 IN IP4 192.168.1.114 s=CounterPath X-Lite 3.0 c=IN IP4 192.168.1.114 t=0 0 m=audio 35824 RTP/AVP 107 0 8 101 a=rtpmap:107 BV32/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=alt:1 3 : KqvAzzQb 8KWQrMqE 192.168.1.114 35824 a=alt:2 2 : 7/J0Lq0c 31UYb9xD 192.168.197.1 35824 a=alt:3 1 : KVftFEHN Agl/D+Em 192.168.254.1 35824 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare [BV32:107:16000:20]/[PCMA:8:8000:20] 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare [PCMU:0:8000:20]/[PCMA:8:8000:20] 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare [PCMA:8:8000:20]/[PCMA:8:8000:20] 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:2354 Set Codec sofia/internal/50 at 192.168.1.114 PCMA/8000 20 ms 160 samples 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3524 Set 2833 dtmf send/recv payload to 101 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4310 (sofia/internal/50 at 192.168.1.114) State Change CS_NEW -> CS_INIT 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 192.168.1.114) Running State Change CS_INIT 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/50 at 192.168.1.114) State INIT 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:83 sofia/internal/50 at 192.168.1.114 SOFIA INIT 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:117 (sofia/internal/50 at 192.168.1.114) State Change CS_INIT -> CS_ROUTING 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 (sofia/internal/50 at 192.168.1.114) State INIT going to sleep 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/50 at 192.168.1.114) Running State Change CS_ROUTING 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:341 (sofia/internal/50 at 192.168.1.114) State ROUTING 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:140 sofia/internal/50 at 192.168.1.114 SOFIA ROUTING 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:77 sofia/internal/50 at 192.168.1.114 Standard ROUTING 2010-10-26 16:13:04.328125 [INFO] mod_dialplan_xml.c:418 Processing 50->70 in context default Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Nebenstellen-extern] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Nebenstellen-extern] caller_id_number(50) =~ /^6[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern10_11] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern10_11] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern12_13] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern12_13] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern14_15] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern14_15] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern16_17] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern16_17] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern18_19] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern18_19] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Systemnummern] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Systemnummern] destination_number(70) =~ /^2[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Mailboxen] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Mailboxen] destination_number(70) =~ /^3[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Tuerruf] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) [EBV-Tuerruf] destination_number(70) =~ /^7[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Tuerruf] caller_id_number(50) =~ /^4[0-9]$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Amtsleitungen_50] continue=false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) [EBV-Amtsleitungen_50] caller_id_number(50) =~ /^.*/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) [EBV-Amtsleitungen_50] destination_number(70) =~ /^70$/ break=on-false Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE EBV-Amtsleitungen) Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE ------------------------) Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE caller_id_number : ${caller_id_number}) Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE destination_number : ${destination_number}) Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE user_name : ${user_name}) Dialplan: sofia/internal/50 at 192.168.1.114 Action info() Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ebv_nebenstellen=60,61) INLINE EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_nebenstellen=60,61) 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [ebv_nebenstellen]=[60,61] Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ebv_mailbox_record=30) INLINE EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_mailbox_record=30) 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 sofia/internal/50 at 192.168.1.114 SET [ebv_mailbox_record]=[30] Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ebv_audiosync=10) Dialplan: sofia/internal/50 at 192.168.1.114 Action set(call_timeout=120) Dialplan: sofia/internal/50 at 192.168.1.114 Action set(hangup_after_bridge=false) Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ignore_early_media=true) Dialplan: sofia/internal/50 at 192.168.1.114 Action easybyvoice(EProcessCallExtern,${user_name},${destination_number}) 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:119 (sofia/internal/50 at 192.168.1.114) State Change CS_ROUTING -> CS_EXECUTE 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/50 at 192.168.1.114 [BREAK] 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 From anthony.minessale at gmail.com Tue Oct 26 09:02:44 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 11:02:44 -0500 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> Message-ID: you still did not update to latest git then On Tue, Oct 26, 2010 at 10:48 AM, Bernhard Suttner wrote: > Hi, > > I have not activated inbound-bypass-media and I tried with ignore-eary-media set to true and to false. Both times, I have no ringback. I added some debug stuff within mod_loopback.c and saw, that the code after switch_core_session_get_partner will not be called for msg->message_id = 7. > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Dienstag, 26. Oktober 2010 16:22 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > do you have inbound-bypass-media on? > or are you not setting {ignore_early_media=true} when you call loopback > > The default config ext 9181 demonstrates this functionality and is > confirmed to work. > > > > On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner > wrote: >> Hi, >> >> it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. >> >> Best regards, >> Bernhard >> >> -----Urspr?ngliche Nachricht----- >> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale >> Gesendet: Montag, 25. Oktober 2010 21:22 >> An: freeswitch-dev at lists.freeswitch.org >> Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> We try. We're not always on top of things as much as we'd like but we >> sure try =p >> >> >> On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner >> wrote: >>> Hi, >>> >>> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >>> >>> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >>> >>> Best regards, >>> Bernhard >>> >>> >>> ----- Original Message ----- >>> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >>> To: freeswitch-dev at lists.freeswitch.org >>> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >>> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >>> >>> >>>> try again on latest HEAD that may have been broken over the weekend. >>>> >>>> >>>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>>> wrote: >>>> > Hi, >>>> > >>>> > I have the following scenario >>>> > >>>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>>> > >>>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>>> RINGING will not be passed through to A because of the loopback module. >>>> (That is was the trace does say). What has to happen on mod_loopback if it >>>> does receive the RINGING? Does it have to do something like >>>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>>> I think it has maybe something to do with the missing INDICATE_RINGING >>>> section in mod_loopback. >>>> > >>>> > Best regards, >>>> > Bernhard Suttner >>>> > >>>> > _______________________________________________ >>>> > FreeSWITCH-dev mailing list >>>> > FreeSWITCH-dev at 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/ >>>> Twitter: http://twitter.com/FreeSWITCH_wire >>>> >>>> AIM: anthm >>>> MSN:anthony_minessale at hotmail.com >>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>>> IRC: irc.freenode.net #freeswitch >>>> >>>> FreeSWITCH Developer Conference >>>> sip:888 at conference.freeswitch.org >>>> googletalk:conf+888 at conference.freeswitch.org >>>> pstn:+19193869900 >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at 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 at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From anthony.minessale at gmail.com Tue Oct 26 09:05:24 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 11:05:24 -0500 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: <4CC6F8E8.4060308@lyth.de> References: <4CC69D48.9060707@lyth.de> <4CC6E704.2020707@lyth.de> <4CC6F8E8.4060308@lyth.de> Message-ID: your code appears out of date. please reproduce on latest GIT HEAD On Tue, Oct 26, 2010 at 10:51 AM, Achim Stamm wrote: > Anthony Minessale schrieb: >> Well then you should show a log of it happening with 2 x-lites then. >> >> >> >> On Tue, Oct 26, 2010 at 9:34 AM, Achim Stamm wrote: >> >>> Anthony Minessale schrieb: >>> >>>> what is mod_evb? if it's a proprietary endpoint i'd look into that code. >>>> >>>> >>>> On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: >>>> >>>> >>>>> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>> 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel >>>>> [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered >>>>> 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup >>>>> sofia/internal/50 at 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 at 192.168.1.114 [KILL] >>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 >>>>> (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] >>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>>> (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>>> (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP >>>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>>> sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP >>>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>>> sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>>> (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 >>>>> sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 >>>>> (sofia/internal/50 at 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 at 192.168.1.114) Ended >>>>> 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close >>>>> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 >>>>> (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY >>>>> 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 >>>>> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 >>>>> sofia/internal/50 at 192.168.1.114 Standard DESTROY >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 >>>>> (sofia/internal/50 at 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 at 192.168.1.114:52111 >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 >>>>> sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>>> (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> FreeSWITCH-dev mailing list >>>>> FreeSWITCH-dev at lists.freeswitch.org >>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>>> http://www.freeswitch.org >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> Hello Anthony, >>> >>> mod_ebv is an own module implementation. >>> Here 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 at 192.168.1.114,user/61 at 192.168.1.114", timelimit, NULL, NULL, >>> NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) >>> >>> Both Phones with number 60 and 61 rings. >>> The problem with INCOMPATIBLE_DESTINATION occurs also with two X-Lites. >>> >>> 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 >>> >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at lists.freeswitch.org >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>> http://www.freeswitch.org >>> >>> >> >> >> >> > Here is a full Log with two X-Lites: > EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_audiosync=10) > 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [ebv_audiosync]=[10] > EXECUTE sofia/internal/50 at 192.168.1.114 set(call_timeout=120) > 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [call_timeout]=[120] > EXECUTE sofia/internal/50 at 192.168.1.114 set(hangup_after_bridge=false) > 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [hangup_after_bridge]=[false] > EXECUTE sofia/internal/50 at 192.168.1.114 set(ignore_early_media=true) > 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [ignore_early_media]=[true] > 2010-10-26 16:12:35.687500 [DEBUG] switch_core_session.c:1751 > Application easybyvoice Requires media! pre_answering channel > sofia/internal/50 at 192.168.1.114 > 2010-10-26 16:12:35.703125 [INFO] switch_core_session.c:1753 Sending > early media > 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2594 AUDIO RTP > [sofia/internal/50 at 192.168.1.114] 192.168.1.114 port 27666 -> > 192.168.1.114 port 51244 codec: 8 ms: 20 > 2010-10-26 16:12:35.703125 [DEBUG] switch_rtp.c:1182 Starting timer > [soft] 160 bytes per 20ms > 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send > payload to 101 > 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf > receive payload to 101 > 2010-10-26 16:12:35.703125 [DEBUG] mod_sofia.c:1904 Ring SDP: > v=0 > o=FreeSWITCH 1288074689 1288074690 IN IP4 192.168.1.114 > s=FreeSWITCH > c=IN IP4 192.168.1.114 > t=0 0 > m=audio 27666 RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:20 > a=sendrecv > > 2010-10-26 16:12:35.703125 [NOTICE] mod_sofia.c:1907 Pre-Answer > sofia/internal/50 at 192.168.1.114! > 2010-10-26 16:12:35.703125 [DEBUG] switch_core_session.c:641 Send signal > sofia/internal/50 at 192.168.1.114 [BREAK] > EXECUTE sofia/internal/50 at 192.168.1.114 > easybyvoice(EProcessCallExtern,50,70) > 2010-10-26 16:12:35.703125 [DEBUG] sofia.c:4148 Channel > sofia/internal/50 at 192.168.1.114 skipping state [early][183] > 2010-10-26 16:12:35.718750 [WARNING] mod_ebv.cpp:1536 mod_ebv built > 14.04.2010 20:15! > 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:1120 Die Nebenstelle > [user/60 at 192.168.1.114,user/61 at 192.168.1.114] wird angerufen. > 2010-10-26 16:12:35.718750 [INFO] Extension.cpp:481 Mailbox-Timer mit > [45] Sekunden wird gestartet. > 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:152 Starte Bridge-Call > Thread .... > 2010-10-26 16:12:35.718750 [DEBUG] switch_ivr_originate.c:1885 variable > string 0 = [presence_id=60 at 192.168.1.114] > 2010-10-26 16:12:35.734375 [NOTICE] switch_channel.c:669 New Channel > sofia/internal/sip:60 at 192.168.1.101:10488 > [11d0f556-8770-408c-be71-f2d5689435d2] > 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:3384 > (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_NEW -> CS_INIT > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_INIT > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT > 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:83 > sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA INIT > 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:117 > (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_INIT -> > CS_ROUTING > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT going to sleep > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_ROUTING > 2010-10-26 16:12:35.734375 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:60 at 192.168.1.101:10488 entering state [calling][0] > 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:341 > (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING > 2010-10-26 16:12:35.734375 [DEBUG] switch_ivr_originate.c:1885 variable > string 0 = [presence_id=61 at 192.168.1.114] > 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:140 > sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA ROUTING > 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 > (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_ROUTING -> > CS_CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 > (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING going to sleep > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change > CS_CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [NOTICE] switch_channel.c:669 New Channel > sofia/internal/sip:61 at 192.168.1.148:15716 > [f56c3295-51e9-4e65-a6b8-d72e8ecc9832] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 > (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:3384 > (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_NEW -> CS_INIT > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 > (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA going to > sleep > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_INIT > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT > 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:83 > sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA INIT > 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:117 > (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_INIT -> > CS_ROUTING > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT going to sleep > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_ROUTING > 2010-10-26 16:12:35.750000 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:61 at 192.168.1.148:15716 entering state [calling][0] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 > (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING > 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:140 > sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA ROUTING > 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 > (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_ROUTING -> > CS_CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 > (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING going to sleep > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change > CS_CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 > (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA > 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 > (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA going to > sleep > 2010-10-26 16:12:35.796875 [DEBUG] switch_rtp.c:2066 Correct ip/port > confirmed. > 2010-10-26 16:12:35.890625 [INFO] sofia.c:662 Update Callee ID to "61" <61> > 2010-10-26 16:12:35.906250 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:61 at 192.168.1.148:15716 entering state [proceeding][180] > 2010-10-26 16:12:35.906250 [NOTICE] sofia.c:4223 Ring-Ready > sofia/internal/sip:61 at 192.168.1.148:15716! > 2010-10-26 16:12:36.046875 [INFO] sofia.c:662 Update Callee ID to "60" <60> > 2010-10-26 16:12:36.062500 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:60 at 192.168.1.101:10488 entering state [proceeding][180] > 2010-10-26 16:12:36.062500 [NOTICE] sofia.c:4223 Ring-Ready > sofia/internal/sip:60 at 192.168.1.101:10488! > 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:61 at 192.168.1.148:15716 entering state [completing][200] > 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4164 Remote SDP: > v=0 > o=- 5 2 IN IP4 192.168.1.148 > s=CounterPath eyeBeam 1.5 > c=IN IP4 192.168.1.148 > t=0 0 > m=audio 32706 RTP/AVP 8 101 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=x-rtp-session-id:7FD79621EBE842499E1736EE7C1A6E58 > > 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel > sofia/internal/sip:61 at 192.168.1.148:15716 entering state [ready][200] > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3585 Audio Codec Compare > [PCMA:8:8000:20]/[PCMA:8:8000:20] > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2354 Set Codec > sofia/internal/sip:61 at 192.168.1.148:15716 PCMA/8000 20 ms 160 samples > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3518 Set 2833 dtmf send > payload to 101 > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2594 AUDIO RTP > [sofia/internal/sip:61 at 192.168.1.148:15716] 192.168.1.114 port 17306 -> > 192.168.1.148 port 32706 codec: 8 ms: 20 > 2010-10-26 16:12:52.859375 [DEBUG] switch_rtp.c:1182 Starting timer > [soft] 160 bytes per 20ms > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send > payload to 101 > 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf > receive payload to 101 > 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3079 Hangup > sofia/internal/sip:60 at 192.168.1.101:10488 [CS_CONSUME_MEDIA] [LOSE_RACE] > 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2324 Send signal > sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal > sofia/internal/sip:60 at 192.168.1.101:10488 [KILL] > 2010-10-26 16:12:52.875000 [NOTICE] sofia.c:4733 Channel > [sofia/internal/sip:61 at 192.168.1.148:15716] has been answered > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:52.875000 [NOTICE] switch_channel.c:2424 Hangup > sofia/internal/50 at 192.168.1.114 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_HANGUP > 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal > sofia/internal/50 at 192.168.1.114 [KILL] > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3111 > sofia/internal/50 at 192.168.1.114 Media Establishment Failed. > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_HANGUP > 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:1264 leavin > ebv_process_call_extern > 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3113 Hangup > sofia/internal/sip:61 at 192.168.1.148:15716 [CS_CONSUME_MEDIA] > [INCOMPATIBLE_DESTINATION] > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:348 > (sofia/internal/50 at 192.168.1.114) State EXECUTE going to sleep > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_HANGUP > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP > 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/sip:60 at 192.168.1.101:10488 hanging up, cause: LOSE_RACE > 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal > sofia/internal/sip:61 at 192.168.1.148:15716 [KILL] > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3228 Originate > Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION] > 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:2219 Originate Failed. > Cause: INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:154 .... Bridge-Call > Thread beendet!! > 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP > 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/sip:61 at 192.168.1.148:15716 hanging up, cause: > INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.890625 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/50 at 192.168.1.114) State HANGUP > 2010-10-26 16:12:52.890625 [DEBUG] mod_sofia.c:414 Channel > sofia/internal/50 at 192.168.1.114 hanging up, cause: INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:467 Sending CANCEL to > sofia/internal/sip:60 at 192.168.1.101:10488 > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 > sofia/internal/sip:60 at 192.168.1.101:10488 Standard HANGUP, cause: LOSE_RACE > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP going to sleep > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:333 > (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_HANGUP -> > CS_REPORTING > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change > CS_REPORTING > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:53 > sofia/internal/sip:60 at 192.168.1.101:10488 Standard REPORTING, cause: > LOSE_RACE > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING going to sleep > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:327 > (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_REPORTING -> > CS_DESTROY > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1164 Session 62 > (sofia/internal/sip:60 at 192.168.1.101:10488) Locked, Waiting on external > entities > 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:457 Sending BYE to > sofia/internal/sip:61 at 192.168.1.148:15716 > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 > sofia/internal/sip:61 at 192.168.1.148:15716 Standard HANGUP, cause: > INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP going to sleep > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:333 > (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_HANGUP -> > CS_REPORTING > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change > CS_REPORTING > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:53 > sofia/internal/sip:61 at 192.168.1.148:15716 Standard REPORTING, cause: > INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING going to sleep > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:327 > (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_REPORTING -> > CS_DESTROY > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1164 Session 63 > (sofia/internal/sip:61 at 192.168.1.148:15716) Locked, Waiting on external > entities > 2010-10-26 16:12:52.921875 [DEBUG] mod_sofia.c:476 Responding to INVITE > with: 488 > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:46 > sofia/internal/50 at 192.168.1.114 Standard HANGUP, cause: > INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:499 > (sofia/internal/50 at 192.168.1.114) State HANGUP going to sleep > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:333 > (sofia/internal/50 at 192.168.1.114) State Change CS_HANGUP -> CS_REPORTING > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_REPORTING > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/50 at 192.168.1.114) State REPORTING > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:53 > sofia/internal/50 at 192.168.1.114 Standard REPORTING, cause: > INCOMPATIBLE_DESTINATION > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 > (sofia/internal/50 at 192.168.1.114) State REPORTING going to sleep > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:327 > (sofia/internal/50 at 192.168.1.114) State Change CS_REPORTING -> CS_DESTROY > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1164 Session 61 > (sofia/internal/50 at 192.168.1.114) Locked, Waiting on external entities > 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1182 Session > 61 (sofia/internal/50 at 192.168.1.114) Ended > 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1184 Close > Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:428 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_DESTROY > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 > (sofia/internal/50 at 192.168.1.114) State DESTROY > 2010-10-26 16:12:52.937500 [DEBUG] mod_sofia.c:341 > sofia/internal/50 at 192.168.1.114 SOFIA DESTROY > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:60 > sofia/internal/50 at 192.168.1.114 Standard DESTROY > 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 > (sofia/internal/50 at 192.168.1.114) State DESTROY going to sleep > 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 > Rejected by acl "domains". Falling back to Digest auth. > 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 > Rejected by acl "domains". Falling back to Digest auth. > 2010-10-26 16:13:04.312500 [NOTICE] switch_channel.c:669 New Channel > sofia/internal/50 at 192.168.1.114 [164c4fd7-a814-4dc1-af21-585c313914c4] > 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_NEW > 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:320 > (sofia/internal/50 at 192.168.1.114) State NEW > 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4153 Channel > sofia/internal/50 at 192.168.1.114 entering state [received][100] > 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4164 Remote SDP: > v=0 > o=- 6 2 IN IP4 192.168.1.114 > s=CounterPath X-Lite 3.0 > c=IN IP4 192.168.1.114 > t=0 0 > m=audio 35824 RTP/AVP 107 0 8 101 > a=rtpmap:107 BV32/16000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=alt:1 3 : KqvAzzQb 8KWQrMqE 192.168.1.114 35824 > a=alt:2 2 : 7/J0Lq0c 31UYb9xD 192.168.197.1 35824 > a=alt:3 1 : KVftFEHN Agl/D+Em 192.168.254.1 35824 > > 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare > [BV32:107:16000:20]/[PCMA:8:8000:20] > 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare > [PCMU:0:8000:20]/[PCMA:8:8000:20] > 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare > [PCMA:8:8000:20]/[PCMA:8:8000:20] > 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:2354 Set Codec > sofia/internal/50 at 192.168.1.114 PCMA/8000 20 ms 160 samples > 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3524 Set 2833 dtmf > send/recv payload to 101 > 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4310 > (sofia/internal/50 at 192.168.1.114) State Change CS_NEW -> CS_INIT > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_INIT > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/50 at 192.168.1.114) State INIT > 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:83 > sofia/internal/50 at 192.168.1.114 SOFIA INIT > 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:117 > (sofia/internal/50 at 192.168.1.114) State Change CS_INIT -> CS_ROUTING > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 > (sofia/internal/50 at 192.168.1.114) State INIT going to sleep > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 > (sofia/internal/50 at 192.168.1.114) Running State Change CS_ROUTING > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:341 > (sofia/internal/50 at 192.168.1.114) State ROUTING > 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:140 > sofia/internal/50 at 192.168.1.114 SOFIA ROUTING > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:77 > sofia/internal/50 at 192.168.1.114 Standard ROUTING > 2010-10-26 16:13:04.328125 [INFO] mod_dialplan_xml.c:418 Processing > 50->70 in context default > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Nebenstellen-extern] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Nebenstellen-extern] caller_id_number(50) =~ /^6[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern10_11] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern10_11] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern12_13] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern12_13] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern14_15] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern14_15] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern16_17] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern16_17] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern18_19] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern18_19] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Systemnummern] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) > [EBV-Systemnummern] destination_number(70) =~ /^2[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Mailboxen] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Mailboxen] > destination_number(70) =~ /^3[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Tuerruf] > continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) [EBV-Tuerruf] > destination_number(70) =~ /^7[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Tuerruf] > caller_id_number(50) =~ /^4[0-9]$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 parsing > [default->EBV-Amtsleitungen_50] continue=false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) > [EBV-Amtsleitungen_50] caller_id_number(50) =~ /^.*/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) > [EBV-Amtsleitungen_50] destination_number(70) =~ /^70$/ break=on-false > Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE > EBV-Amtsleitungen) > Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE > ------------------------) > Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE > caller_id_number ? : ${caller_id_number}) > Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE > destination_number : ${destination_number}) > Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE user_name : > ${user_name}) > Dialplan: sofia/internal/50 at 192.168.1.114 Action info() > Dialplan: sofia/internal/50 at 192.168.1.114 Action > set(ebv_nebenstellen=60,61) INLINE > EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_nebenstellen=60,61) > 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [ebv_nebenstellen]=[60,61] > Dialplan: sofia/internal/50 at 192.168.1.114 Action > set(ebv_mailbox_record=30) INLINE > EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_mailbox_record=30) > 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 > sofia/internal/50 at 192.168.1.114 SET [ebv_mailbox_record]=[30] > Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ebv_audiosync=10) > Dialplan: sofia/internal/50 at 192.168.1.114 Action set(call_timeout=120) > Dialplan: sofia/internal/50 at 192.168.1.114 Action > set(hangup_after_bridge=false) > Dialplan: sofia/internal/50 at 192.168.1.114 Action > set(ignore_early_media=true) > Dialplan: sofia/internal/50 at 192.168.1.114 Action > easybyvoice(EProcessCallExtern,${user_name},${destination_number}) > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:119 > (sofia/internal/50 at 192.168.1.114) State Change CS_ROUTING -> CS_EXECUTE > 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send > signal sofia/internal/50 at 192.168.1.114 [BREAK] > > > > 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From mike at jerris.com Tue Oct 26 09:19:48 2010 From: mike at jerris.com (Michael Jerris) Date: Tue, 26 Oct 2010 12:19:48 -0400 Subject: [Freeswitch-dev] VLAN support in sofia module In-Reply-To: References: Message-ID: <47FBF168-1A01-43CD-B674-D12F7655ACD6@jerris.com> vlan is an os networking stack feature more than sip stack. The requirement to bind to a specific IP is a feature that allows you to specify the interface to use so we can use the correct identity in communication. Binding to 0.0.0.0 is not planned and I think not desirable. Mike On Oct 23, 2010, at 2:47 PM, Adam Ku?mirek wrote: > Hi All > > I would like to run FreeSwitch as SBC in my network. I have > architecture with all clients connected via separate vlans. > It gives me possibility to use one ip address for all clients, but I > need FS sofia profile to bind to specific interface (eg eth0:20 vlan > 20) and global ip address. > As I see, for now sofia module allows to bind to ip address only. I > looked quickly to sourcees and it seems that this is limited by sofia > library. > Of course i may be wrong because I'm new to FS and didn't have time to > analyze sources. > Please, write some words on this topic. > Do you have plans to implement vlan support in FS. > I know that AcmePacket Net-Net gives such feature. Don't know any open > voip solution with this iplemented. > > Regards Adam > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org From steveayre at gmail.com Tue Oct 26 09:47:35 2010 From: steveayre at gmail.com (Steven Ayre) Date: Tue, 26 Oct 2010 17:47:35 +0100 Subject: [Freeswitch-dev] VLAN support in sofia module In-Reply-To: References: Message-ID: Possibly your best bet would be to set sip-ip and rtp-ip to the specific interface and ext-sip-ip and ext-rtp-ip to the global IP. I don't know how well this'll work though. Sofia might get very confused about where to send stuff to, since the same IP is used on essentially separate networks. -Steve On 23 October 2010 19:47, Adam Ku?mirek wrote: > Hi All > > I would like to run FreeSwitch as SBC in my network. I have > architecture with all clients connected via separate vlans. > It gives me possibility to use one ip address for all clients, but I > need FS sofia profile to bind to specific interface (eg eth0:20 vlan > 20) and global ip address. > As I see, for now sofia module allows to bind to ip address only. I > looked quickly to sourcees and it seems that this is limited by sofia > library. > Of course i may be wrong because I'm new to FS and didn't have time to > analyze sources. > Please, write some words on this topic. > Do you have plans to implement vlan support in FS. > I know that AcmePacket Net-Net gives such feature. Don't know any open > voip solution with this iplemented. > > Regards Adam > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From steveayre at gmail.com Tue Oct 26 09:49:52 2010 From: steveayre at gmail.com (Steven Ayre) Date: Tue, 26 Oct 2010 17:49:52 +0100 Subject: [Freeswitch-dev] VLAN support in sofia module In-Reply-To: References: Message-ID: Thinking about it, it won't work. ext-sip-ip will be inside the packets but they'll be sent from sip-ip so the clients won't see it coming from the IP you want. On 26 October 2010 17:47, Steven Ayre wrote: > Possibly your best bet would be to set sip-ip and rtp-ip to the > specific interface and ext-sip-ip and ext-rtp-ip to the global IP. > > I don't know how well this'll work though. Sofia might get very > confused about where to send stuff to, since the same IP is used on > essentially separate networks. > > -Steve > > > On 23 October 2010 19:47, Adam Ku?mirek wrote: >> Hi All >> >> I would like to run FreeSwitch as SBC in my network. I have >> architecture with all clients connected via separate vlans. >> It gives me possibility to use one ip address for all clients, but I >> need FS sofia profile to bind to specific interface (eg eth0:20 vlan >> 20) and global ip address. >> As I see, for now sofia module allows to bind to ip address only. I >> looked quickly to sourcees and it seems that this is limited by sofia >> library. >> Of course i may be wrong because I'm new to FS and didn't have time to >> analyze sources. >> Please, write some words on this topic. >> Do you have plans to implement vlan support in FS. >> I know that AcmePacket Net-Net gives such feature. Don't know any open >> voip solution with this iplemented. >> >> Regards Adam >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> > From bernhard.suttner at winet.ch Tue Oct 26 10:06:57 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Tue, 26 Oct 2010 19:06:57 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> Message-ID: Fixed. Problem was within mod_loopback but anthm did fix it. Thanks a lot again! -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale Gesendet: Dienstag, 26. Oktober 2010 18:03 An: freeswitch-dev at lists.freeswitch.org Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone you still did not update to latest git then On Tue, Oct 26, 2010 at 10:48 AM, Bernhard Suttner wrote: > Hi, > > I have not activated inbound-bypass-media and I tried with ignore-eary-media set to true and to false. Both times, I have no ringback. I added some debug stuff within mod_loopback.c and saw, that the code after switch_core_session_get_partner will not be called for msg->message_id = 7. > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Dienstag, 26. Oktober 2010 16:22 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > do you have inbound-bypass-media on? > or are you not setting {ignore_early_media=true} when you call loopback > > The default config ext 9181 demonstrates this functionality and is > confirmed to work. > > > > On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner > wrote: >> Hi, >> >> it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. >> >> Best regards, >> Bernhard >> >> -----Urspr?ngliche Nachricht----- >> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale >> Gesendet: Montag, 25. Oktober 2010 21:22 >> An: freeswitch-dev at lists.freeswitch.org >> Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> We try. We're not always on top of things as much as we'd like but we >> sure try =p >> >> >> On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner >> wrote: >>> Hi, >>> >>> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >>> >>> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >>> >>> Best regards, >>> Bernhard >>> >>> >>> ----- Original Message ----- >>> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >>> To: freeswitch-dev at lists.freeswitch.org >>> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >>> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >>> >>> >>>> try again on latest HEAD that may have been broken over the weekend. >>>> >>>> >>>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>>> wrote: >>>> > Hi, >>>> > >>>> > I have the following scenario >>>> > >>>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>>> > >>>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>>> RINGING will not be passed through to A because of the loopback module. >>>> (That is was the trace does say). What has to happen on mod_loopback if it >>>> does receive the RINGING? Does it have to do something like >>>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>>> I think it has maybe something to do with the missing INDICATE_RINGING >>>> section in mod_loopback. >>>> > >>>> > Best regards, >>>> > Bernhard Suttner >>>> > >>>> > _______________________________________________ >>>> > FreeSWITCH-dev mailing list >>>> > FreeSWITCH-dev at 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/ >>>> Twitter: http://twitter.com/FreeSWITCH_wire >>>> >>>> AIM: anthm >>>> MSN:anthony_minessale at hotmail.com >>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>>> IRC: irc.freenode.net #freeswitch >>>> >>>> FreeSWITCH Developer Conference >>>> sip:888 at conference.freeswitch.org >>>> googletalk:conf+888 at conference.freeswitch.org >>>> pstn:+19193869900 >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at 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 at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From anthony.minessale at gmail.com Tue Oct 26 10:22:57 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Tue, 26 Oct 2010 12:22:57 -0500 Subject: [Freeswitch-dev] VLAN support in sofia module In-Reply-To: References: Message-ID: its not possible to listen on 0.0.0.0 you can only guess at best on which ip goes with what packets and you cannot choose which source addr to put in outbound packets in that case. This is a limitation caused by the design of the SIP spec. You must create a distinct profile for every interface with the desired IP from each vlan. On Tue, Oct 26, 2010 at 11:49 AM, Steven Ayre wrote: > Thinking about it, it won't work. ext-sip-ip will be inside the > packets but they'll be sent from sip-ip so the clients won't see it > coming from the IP you want. > > On 26 October 2010 17:47, Steven Ayre wrote: >> Possibly your best bet would be to set sip-ip and rtp-ip to the >> specific interface and ext-sip-ip and ext-rtp-ip to the global IP. >> >> I don't know how well this'll work though. Sofia might get very >> confused about where to send stuff to, since the same IP is used on >> essentially separate networks. >> >> -Steve >> >> >> On 23 October 2010 19:47, Adam Ku?mirek wrote: >>> Hi All >>> >>> I would like to run FreeSwitch as SBC in my network. I have >>> architecture with all clients connected via separate vlans. >>> It gives me possibility to use one ip address for all clients, but I >>> need FS sofia profile to bind to specific interface (eg eth0:20 vlan >>> 20) and global ip address. >>> As I see, for now sofia module allows to bind to ip address only. I >>> looked quickly to sourcees and it seems that this is limited by sofia >>> library. >>> Of course i may be wrong because I'm new to FS and didn't have time to >>> analyze sources. >>> Please, write some words on this topic. >>> Do you have plans to implement vlan support in FS. >>> I know that AcmePacket Net-Net gives such feature. Don't know any open >>> voip solution with this iplemented. >>> >>> Regards Adam >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From i.ivanova at mastervoice.it Wed Oct 27 04:15:03 2010 From: i.ivanova at mastervoice.it (Irina Ivanova) Date: Wed, 27 Oct 2010 13:15:03 +0200 Subject: [Freeswitch-dev] Handling of multiple 183 responses with different SDP Message-ID: <4CC809B7.1040005@mastervoice.it> 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.system.issuetabpanels%3Aall-tabpanel 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 at 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. From mike at jerris.com Wed Oct 27 07:26:04 2010 From: mike at jerris.com (Michael Jerris) Date: Wed, 27 Oct 2010 10:26:04 -0400 Subject: [Freeswitch-dev] Handling of multiple 183 responses with different SDP In-Reply-To: <4CC809B7.1040005@mastervoice.it> References: <4CC809B7.1040005@mastervoice.it> Message-ID: http://www.ietf.org/rfc/rfc3264.txt On Oct 27, 2010, at 7:15 AM, Irina Ivanova wrote: > 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.system.issuetabpanels%3Aall-tabpanel > > 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 at 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. > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101027/19692417/attachment.html From anthony.minessale at gmail.com Wed Oct 27 08:51:55 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Wed, 27 Oct 2010 10:51:55 -0500 Subject: [Freeswitch-dev] Handling of multiple 183 responses with different SDP In-Reply-To: <4CC809B7.1040005@mastervoice.it> References: <4CC809B7.1040005@mastervoice.it> Message-ID: Mentioning that it works with asterisk is essentially admitting that its wrong. Trying to use RFC as an excuse to make me change something annoys me so let me have my turn now: RFC 3261 section 13.2.1 bullet 2: "If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." ADOPTED RFC vs expired draft. So that's the end I guess unless you want to email consulting at freeswitch.org and file a bounty for a non-standard feature. On Wed, Oct 27, 2010 at 6:15 AM, Irina Ivanova wrote: > 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.system.issuetabpanels%3Aall-tabpanel > > 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 at 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. > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From msc at freeswitch.org Wed Oct 27 09:24:10 2010 From: msc at freeswitch.org (Michael Collins) Date: Wed, 27 Oct 2010 09:24:10 -0700 Subject: [Freeswitch-dev] FreeSWITCH Conference Call Today Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101027/43accadc/attachment.html From fowlerp at avaya.com Wed Oct 27 11:05:11 2010 From: fowlerp at avaya.com (Fowler, Peter (Peter)) Date: Wed, 27 Oct 2010 14:05:11 -0400 Subject: [Freeswitch-dev] Support for RFC 4575 - SIP Event Package for Conference State Message-ID: <47AB18AC0F23934383F2BBA7EE3D8D742200E85DA9@DC-US1MBEX4.global.avaya.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101027/64701f58/attachment.html From i.ivanova at mastervoice.it Thu Oct 28 07:02:51 2010 From: i.ivanova at mastervoice.it (Irina Ivanova) Date: Thu, 28 Oct 2010 16:02:51 +0200 Subject: [Freeswitch-dev] Handling of multiple 183 responses with different SDP In-Reply-To: References: <4CC809B7.1040005@mastervoice.it> Message-ID: <4CC9828B.50103@mastervoice.it> ?Thank you for the response and for the correct link to RFC. It is exactly what was missing and what we couldn't manage to find ourselves while trying to clear up the situation with our provider. If we won't be able to resolve this issue with them we'll consider filing the bounty for this feature. Anthony Minessale wrote: > Mentioning that it works with asterisk is essentially admitting that its wrong. > > Trying to use RFC as an excuse to make me change something annoys me > so let me have my turn now: > > RFC 3261 section 13.2.1 bullet 2: > > "If the initial offer is in an INVITE, the answer MUST be in a reliable > non-failure message from UAS back to UAC which is correlated to that > INVITE. For this specification, that is only the final 2xx response to > that INVITE. That same exact answer MAY also be placed in any > provisional responses sent prior to the answer. The UAC MUST treat the > first session description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial INVITE." > > ADOPTED RFC vs expired draft. > > So that's the end I guess unless you want to email > consulting at freeswitch.org and file a bounty for a non-standard > feature. > > > On Wed, Oct 27, 2010 at 6:15 AM, Irina Ivanova wrote: > >> 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.system.issuetabpanels%3Aall-tabpanel >> >> 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 at 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. >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > > From msc at freeswitch.org Thu Oct 28 12:11:18 2010 From: msc at freeswitch.org (Michael Collins) Date: Thu, 28 Oct 2010 12:11:18 -0700 Subject: [Freeswitch-dev] FS Conference Call Recordings Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101028/f5bea3da/attachment.html From msc at freeswitch.org Thu Oct 28 16:37:44 2010 From: msc at freeswitch.org (Michael Collins) Date: Thu, 28 Oct 2010 16:37:44 -0700 Subject: [Freeswitch-dev] Language files - French, German, Spanish, etc. Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101028/0b80075d/attachment.html From bernhard.suttner at winet.ch Fri Oct 29 02:59:15 2010 From: bernhard.suttner at winet.ch (Bernhard Suttner) Date: Fri, 29 Oct 2010 11:59:15 +0200 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> Message-ID: Hi, I get the ringback correctly, but from the signaling point of view, I get no register: A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B B does send the ringing to FS. Loopback will set the flag to send the ringback to A but A does not get a RINGING. Is there maybe something other to set to get that working? Best regards, Bernhard -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Bernhard Suttner Gesendet: Dienstag, 26. Oktober 2010 19:07 An: freeswitch-dev at lists.freeswitch.org Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone Fixed. Problem was within mod_loopback but anthm did fix it. Thanks a lot again! -----Urspr?ngliche Nachricht----- Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale Gesendet: Dienstag, 26. Oktober 2010 18:03 An: freeswitch-dev at lists.freeswitch.org Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone you still did not update to latest git then On Tue, Oct 26, 2010 at 10:48 AM, Bernhard Suttner wrote: > Hi, > > I have not activated inbound-bypass-media and I tried with ignore-eary-media set to true and to false. Both times, I have no ringback. I added some debug stuff within mod_loopback.c and saw, that the code after switch_core_session_get_partner will not be called for msg->message_id = 7. > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Dienstag, 26. Oktober 2010 16:22 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > do you have inbound-bypass-media on? > or are you not setting {ignore_early_media=true} when you call loopback > > The default config ext 9181 demonstrates this functionality and is > confirmed to work. > > > > On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner > wrote: >> Hi, >> >> it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. >> >> Best regards, >> Bernhard >> >> -----Urspr?ngliche Nachricht----- >> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale >> Gesendet: Montag, 25. Oktober 2010 21:22 >> An: freeswitch-dev at lists.freeswitch.org >> Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> We try. We're not always on top of things as much as we'd like but we >> sure try =p >> >> >> On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner >> wrote: >>> Hi, >>> >>> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >>> >>> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >>> >>> Best regards, >>> Bernhard >>> >>> >>> ----- Original Message ----- >>> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >>> To: freeswitch-dev at lists.freeswitch.org >>> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >>> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >>> >>> >>>> try again on latest HEAD that may have been broken over the weekend. >>>> >>>> >>>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>>> wrote: >>>> > Hi, >>>> > >>>> > I have the following scenario >>>> > >>>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>>> > >>>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>>> RINGING will not be passed through to A because of the loopback module. >>>> (That is was the trace does say). What has to happen on mod_loopback if it >>>> does receive the RINGING? Does it have to do something like >>>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>>> I think it has maybe something to do with the missing INDICATE_RINGING >>>> section in mod_loopback. >>>> > >>>> > Best regards, >>>> > Bernhard Suttner >>>> > >>>> > _______________________________________________ >>>> > FreeSWITCH-dev mailing list >>>> > FreeSWITCH-dev at 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/ >>>> Twitter: http://twitter.com/FreeSWITCH_wire >>>> >>>> AIM: anthm >>>> MSN:anthony_minessale at hotmail.com >>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>>> IRC: irc.freenode.net #freeswitch >>>> >>>> FreeSWITCH Developer Conference >>>> sip:888 at conference.freeswitch.org >>>> googletalk:conf+888 at conference.freeswitch.org >>>> pstn:+19193869900 >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at 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 at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev at 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 at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org From stamm at lyth.de Fri Oct 29 03:53:28 2010 From: stamm at lyth.de (Achim Stamm) Date: Fri, 29 Oct 2010 12:53:28 +0200 Subject: [Freeswitch-dev] INCOMPATIBLE_DESTINATION after bridging LinkSys3102 and X-Lite In-Reply-To: References: <4CC69D48.9060707@lyth.de> <4CC6E704.2020707@lyth.de> <4CC6F8E8.4060308@lyth.de> Message-ID: <4CCAA7A8.7030005@lyth.de> Anthony Minessale schrieb: > your code appears out of date. > please reproduce on latest GIT HEAD > > > On Tue, Oct 26, 2010 at 10:51 AM, Achim Stamm wrote: > >> Anthony Minessale schrieb: >> >>> Well then you should show a log of it happening with 2 x-lites then. >>> >>> >>> >>> On Tue, Oct 26, 2010 at 9:34 AM, Achim Stamm wrote: >>> >>> >>>> Anthony Minessale schrieb: >>>> >>>> >>>>> what is mod_evb? if it's a proprietary endpoint i'd look into that code. >>>>> >>>>> >>>>> On Tue, Oct 26, 2010 at 4:20 AM, Achim Stamm wrote: >>>>> >>>>> >>>>> >>>>>> 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>>> 2010-10-25 17:00:58.296875 [NOTICE] sofia.c:4733 Channel >>>>>> [sofia/internal/sip:60 at 192.168.1.114:52111] has been answered >>>>>> 2010-10-25 17:00:58.312500 [NOTICE] switch_channel.c:2424 Hangup >>>>>> sofia/internal/50 at 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 at 192.168.1.114 [KILL] >>>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:348 >>>>>> (sofia/internal/50 at 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 at 192.168.1.114 [BREAK] >>>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>>>> (sofia/internal/50 at 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 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>>>> 2010-10-25 17:01:05.375000 [DEBUG] switch_core_state_machine.c:314 >>>>>> (sofia/internal/sip:60 at 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 at 192.168.1.114) State HANGUP >>>>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>>>> sofia/internal/50 at 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 at 192.168.1.114:52111) State HANGUP >>>>>> 2010-10-25 17:01:05.375000 [DEBUG] mod_sofia.c:414 Channel >>>>>> sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>>>> (sofia/internal/50 at 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 at 192.168.1.114) State REPORTING >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:53 >>>>>> sofia/internal/50 at 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 at 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 at 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 at 192.168.1.114 [BREAK] >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_session.c:1164 Session 23 >>>>>> (sofia/internal/50 at 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 at 192.168.1.114) Ended >>>>>> 2010-10-25 17:01:05.390625 [NOTICE] switch_core_session.c:1184 Close >>>>>> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:428 >>>>>> (sofia/internal/50 at 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 at 192.168.1.114) State DESTROY >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] mod_sofia.c:341 >>>>>> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:60 >>>>>> sofia/internal/50 at 192.168.1.114 Standard DESTROY >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:439 >>>>>> (sofia/internal/50 at 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 at 192.168.1.114:52111 >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:46 >>>>>> sofia/internal/sip:60 at 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 at 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 at 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 at 192.168.1.114:52111 [BREAK] >>>>>> 2010-10-25 17:01:05.390625 [DEBUG] switch_core_state_machine.c:314 >>>>>> (sofia/internal/sip:60 at 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 at 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 at 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 at 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 at 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 at 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 at 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> FreeSWITCH-dev mailing list >>>>>> FreeSWITCH-dev at lists.freeswitch.org >>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>>>> http://www.freeswitch.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> Hello Anthony, >>>> >>>> mod_ebv is an own module implementation. >>>> Here 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 at 192.168.1.114,user/61 at 192.168.1.114", timelimit, NULL, NULL, >>>> NULL, NULL, NULL, SOF_NONE,NULL) != SWITCH_STATUS_SUCCESS) >>>> >>>> Both Phones with number 60 and 61 rings. >>>> The problem with INCOMPATIBLE_DESTINATION occurs also with two X-Lites. >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> FreeSWITCH-dev mailing list >>>> FreeSWITCH-dev at lists.freeswitch.org >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >>>> http://www.freeswitch.org >>>> >>>> >>>> >>> >>> >>> >> Here is a full Log with two X-Lites: >> EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_audiosync=10) >> 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [ebv_audiosync]=[10] >> EXECUTE sofia/internal/50 at 192.168.1.114 set(call_timeout=120) >> 2010-10-26 16:12:35.671875 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [call_timeout]=[120] >> EXECUTE sofia/internal/50 at 192.168.1.114 set(hangup_after_bridge=false) >> 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [hangup_after_bridge]=[false] >> EXECUTE sofia/internal/50 at 192.168.1.114 set(ignore_early_media=true) >> 2010-10-26 16:12:35.687500 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [ignore_early_media]=[true] >> 2010-10-26 16:12:35.687500 [DEBUG] switch_core_session.c:1751 >> Application easybyvoice Requires media! pre_answering channel >> sofia/internal/50 at 192.168.1.114 >> 2010-10-26 16:12:35.703125 [INFO] switch_core_session.c:1753 Sending >> early media >> 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2594 AUDIO RTP >> [sofia/internal/50 at 192.168.1.114] 192.168.1.114 port 27666 -> >> 192.168.1.114 port 51244 codec: 8 ms: 20 >> 2010-10-26 16:12:35.703125 [DEBUG] switch_rtp.c:1182 Starting timer >> [soft] 160 bytes per 20ms >> 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send >> payload to 101 >> 2010-10-26 16:12:35.703125 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf >> receive payload to 101 >> 2010-10-26 16:12:35.703125 [DEBUG] mod_sofia.c:1904 Ring SDP: >> v=0 >> o=FreeSWITCH 1288074689 1288074690 IN IP4 192.168.1.114 >> s=FreeSWITCH >> c=IN IP4 192.168.1.114 >> t=0 0 >> m=audio 27666 RTP/AVP 8 101 >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-16 >> a=silenceSupp:off - - - - >> a=ptime:20 >> a=sendrecv >> >> 2010-10-26 16:12:35.703125 [NOTICE] mod_sofia.c:1907 Pre-Answer >> sofia/internal/50 at 192.168.1.114! >> 2010-10-26 16:12:35.703125 [DEBUG] switch_core_session.c:641 Send signal >> sofia/internal/50 at 192.168.1.114 [BREAK] >> EXECUTE sofia/internal/50 at 192.168.1.114 >> easybyvoice(EProcessCallExtern,50,70) >> 2010-10-26 16:12:35.703125 [DEBUG] sofia.c:4148 Channel >> sofia/internal/50 at 192.168.1.114 skipping state [early][183] >> 2010-10-26 16:12:35.718750 [WARNING] mod_ebv.cpp:1536 mod_ebv built >> 14.04.2010 20:15! >> 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:1120 Die Nebenstelle >> [user/60 at 192.168.1.114,user/61 at 192.168.1.114] wird angerufen. >> 2010-10-26 16:12:35.718750 [INFO] Extension.cpp:481 Mailbox-Timer mit >> [45] Sekunden wird gestartet. >> 2010-10-26 16:12:35.718750 [INFO] mod_ebv.cpp:152 Starte Bridge-Call >> Thread .... >> 2010-10-26 16:12:35.718750 [DEBUG] switch_ivr_originate.c:1885 variable >> string 0 = [presence_id=60 at 192.168.1.114] >> 2010-10-26 16:12:35.734375 [NOTICE] switch_channel.c:669 New Channel >> sofia/internal/sip:60 at 192.168.1.101:10488 >> [11d0f556-8770-408c-be71-f2d5689435d2] >> 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:3384 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_NEW -> CS_INIT >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_INIT >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT >> 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:83 >> sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA INIT >> 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:117 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_INIT -> >> CS_ROUTING >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State INIT going to sleep >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_ROUTING >> 2010-10-26 16:12:35.734375 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:60 at 192.168.1.101:10488 entering state [calling][0] >> 2010-10-26 16:12:35.734375 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING >> 2010-10-26 16:12:35.734375 [DEBUG] switch_ivr_originate.c:1885 variable >> string 0 = [presence_id=61 at 192.168.1.114] >> 2010-10-26 16:12:35.734375 [DEBUG] mod_sofia.c:140 >> sofia/internal/sip:60 at 192.168.1.101:10488 SOFIA ROUTING >> 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_ROUTING -> >> CS_CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State ROUTING going to sleep >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change >> CS_CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [NOTICE] switch_channel.c:669 New Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 >> [f56c3295-51e9-4e65-a6b8-d72e8ecc9832] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:3384 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_NEW -> CS_INIT >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State CONSUME_MEDIA going to >> sleep >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_INIT >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT >> 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:83 >> sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA INIT >> 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:117 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_INIT -> >> CS_ROUTING >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State INIT going to sleep >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_ROUTING >> 2010-10-26 16:12:35.750000 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 entering state [calling][0] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING >> 2010-10-26 16:12:35.750000 [DEBUG] mod_sofia.c:140 >> sofia/internal/sip:61 at 192.168.1.148:15716 SOFIA ROUTING >> 2010-10-26 16:12:35.750000 [DEBUG] switch_ivr_originate.c:66 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_ROUTING -> >> CS_CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State ROUTING going to sleep >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change >> CS_CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA >> 2010-10-26 16:12:35.750000 [DEBUG] switch_core_state_machine.c:360 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State CONSUME_MEDIA going to >> sleep >> 2010-10-26 16:12:35.796875 [DEBUG] switch_rtp.c:2066 Correct ip/port >> confirmed. >> 2010-10-26 16:12:35.890625 [INFO] sofia.c:662 Update Callee ID to "61" <61> >> 2010-10-26 16:12:35.906250 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 entering state [proceeding][180] >> 2010-10-26 16:12:35.906250 [NOTICE] sofia.c:4223 Ring-Ready >> sofia/internal/sip:61 at 192.168.1.148:15716! >> 2010-10-26 16:12:36.046875 [INFO] sofia.c:662 Update Callee ID to "60" <60> >> 2010-10-26 16:12:36.062500 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:60 at 192.168.1.101:10488 entering state [proceeding][180] >> 2010-10-26 16:12:36.062500 [NOTICE] sofia.c:4223 Ring-Ready >> sofia/internal/sip:60 at 192.168.1.101:10488! >> 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 entering state [completing][200] >> 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4164 Remote SDP: >> v=0 >> o=- 5 2 IN IP4 192.168.1.148 >> s=CounterPath eyeBeam 1.5 >> c=IN IP4 192.168.1.148 >> t=0 0 >> m=audio 32706 RTP/AVP 8 101 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-15 >> a=x-rtp-session-id:7FD79621EBE842499E1736EE7C1A6E58 >> >> 2010-10-26 16:12:52.859375 [DEBUG] sofia.c:4153 Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 entering state [ready][200] >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3585 Audio Codec Compare >> [PCMA:8:8000:20]/[PCMA:8:8000:20] >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2354 Set Codec >> sofia/internal/sip:61 at 192.168.1.148:15716 PCMA/8000 20 ms 160 samples >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:3518 Set 2833 dtmf send >> payload to 101 >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2594 AUDIO RTP >> [sofia/internal/sip:61 at 192.168.1.148:15716] 192.168.1.114 port 17306 -> >> 192.168.1.148 port 32706 codec: 8 ms: 20 >> 2010-10-26 16:12:52.859375 [DEBUG] switch_rtp.c:1182 Starting timer >> [soft] 160 bytes per 20ms >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2774 Set 2833 dtmf send >> payload to 101 >> 2010-10-26 16:12:52.859375 [DEBUG] sofia_glue.c:2779 Set 2833 dtmf >> receive payload to 101 >> 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3079 Hangup >> sofia/internal/sip:60 at 192.168.1.101:10488 [CS_CONSUME_MEDIA] [LOSE_RACE] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2324 Send signal >> sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal >> sofia/internal/sip:60 at 192.168.1.101:10488 [KILL] >> 2010-10-26 16:12:52.875000 [NOTICE] sofia.c:4733 Channel >> [sofia/internal/sip:61 at 192.168.1.148:15716] has been answered >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:52.875000 [NOTICE] switch_channel.c:2424 Hangup >> sofia/internal/50 at 192.168.1.114 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change CS_HANGUP >> 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal >> sofia/internal/50 at 192.168.1.114 [KILL] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3111 >> sofia/internal/50 at 192.168.1.114 Media Establishment Failed. >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change CS_HANGUP >> 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:1264 leavin >> ebv_process_call_extern >> 2010-10-26 16:12:52.875000 [NOTICE] switch_ivr_originate.c:3113 Hangup >> sofia/internal/sip:61 at 192.168.1.148:15716 [CS_CONSUME_MEDIA] >> [INCOMPATIBLE_DESTINATION] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:348 >> (sofia/internal/50 at 192.168.1.114) State EXECUTE going to sleep >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_HANGUP >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP >> 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel >> sofia/internal/sip:60 at 192.168.1.101:10488 hanging up, cause: LOSE_RACE >> 2010-10-26 16:12:52.875000 [DEBUG] switch_channel.c:2102 Send signal >> sofia/internal/sip:61 at 192.168.1.148:15716 [KILL] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:52.875000 [DEBUG] switch_ivr_originate.c:3228 Originate >> Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION] >> 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:2219 Originate Failed. >> Cause: INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.875000 [INFO] mod_ebv.cpp:154 .... Bridge-Call >> Thread beendet!! >> 2010-10-26 16:12:52.875000 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP >> 2010-10-26 16:12:52.875000 [DEBUG] mod_sofia.c:414 Channel >> sofia/internal/sip:61 at 192.168.1.148:15716 hanging up, cause: >> INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.890625 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/50 at 192.168.1.114) State HANGUP >> 2010-10-26 16:12:52.890625 [DEBUG] mod_sofia.c:414 Channel >> sofia/internal/50 at 192.168.1.114 hanging up, cause: INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:467 Sending CANCEL to >> sofia/internal/sip:60 at 192.168.1.101:10488 >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 >> sofia/internal/sip:60 at 192.168.1.101:10488 Standard HANGUP, cause: LOSE_RACE >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State HANGUP going to sleep >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:333 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_HANGUP -> >> CS_REPORTING >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Running State Change >> CS_REPORTING >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:53 >> sofia/internal/sip:60 at 192.168.1.101:10488 Standard REPORTING, cause: >> LOSE_RACE >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State REPORTING going to sleep >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:327 >> (sofia/internal/sip:60 at 192.168.1.101:10488) State Change CS_REPORTING -> >> CS_DESTROY >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:60 at 192.168.1.101:10488 [BREAK] >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_session.c:1164 Session 62 >> (sofia/internal/sip:60 at 192.168.1.101:10488) Locked, Waiting on external >> entities >> 2010-10-26 16:12:52.906250 [DEBUG] mod_sofia.c:457 Sending BYE to >> sofia/internal/sip:61 at 192.168.1.148:15716 >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:46 >> sofia/internal/sip:61 at 192.168.1.148:15716 Standard HANGUP, cause: >> INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.906250 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State HANGUP going to sleep >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:333 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_HANGUP -> >> CS_REPORTING >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Running State Change >> CS_REPORTING >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:53 >> sofia/internal/sip:61 at 192.168.1.148:15716 Standard REPORTING, cause: >> INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State REPORTING going to sleep >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:327 >> (sofia/internal/sip:61 at 192.168.1.148:15716) State Change CS_REPORTING -> >> CS_DESTROY >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/sip:61 at 192.168.1.148:15716 [BREAK] >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_session.c:1164 Session 63 >> (sofia/internal/sip:61 at 192.168.1.148:15716) Locked, Waiting on external >> entities >> 2010-10-26 16:12:52.921875 [DEBUG] mod_sofia.c:476 Responding to INVITE >> with: 488 >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:46 >> sofia/internal/50 at 192.168.1.114 Standard HANGUP, cause: >> INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.921875 [DEBUG] switch_core_state_machine.c:499 >> (sofia/internal/50 at 192.168.1.114) State HANGUP going to sleep >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:333 >> (sofia/internal/50 at 192.168.1.114) State Change CS_HANGUP -> CS_REPORTING >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_REPORTING >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/50 at 192.168.1.114) State REPORTING >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:53 >> sofia/internal/50 at 192.168.1.114 Standard REPORTING, cause: >> INCOMPATIBLE_DESTINATION >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:590 >> (sofia/internal/50 at 192.168.1.114) State REPORTING going to sleep >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:327 >> (sofia/internal/50 at 192.168.1.114) State Change CS_REPORTING -> CS_DESTROY >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_session.c:1164 Session 61 >> (sofia/internal/50 at 192.168.1.114) Locked, Waiting on external entities >> 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1182 Session >> 61 (sofia/internal/50 at 192.168.1.114) Ended >> 2010-10-26 16:12:52.937500 [NOTICE] switch_core_session.c:1184 Close >> Channel sofia/internal/50 at 192.168.1.114 [CS_DESTROY] >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:428 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_DESTROY >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 >> (sofia/internal/50 at 192.168.1.114) State DESTROY >> 2010-10-26 16:12:52.937500 [DEBUG] mod_sofia.c:341 >> sofia/internal/50 at 192.168.1.114 SOFIA DESTROY >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:60 >> sofia/internal/50 at 192.168.1.114 Standard DESTROY >> 2010-10-26 16:12:52.937500 [DEBUG] switch_core_state_machine.c:439 >> (sofia/internal/50 at 192.168.1.114) State DESTROY going to sleep >> 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 >> Rejected by acl "domains". Falling back to Digest auth. >> 2010-10-26 16:13:04.296875 [DEBUG] sofia.c:5847 IP 192.168.1.114 >> Rejected by acl "domains". Falling back to Digest auth. >> 2010-10-26 16:13:04.312500 [NOTICE] switch_channel.c:669 New Channel >> sofia/internal/50 at 192.168.1.114 [164c4fd7-a814-4dc1-af21-585c313914c4] >> 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_NEW >> 2010-10-26 16:13:04.312500 [DEBUG] switch_core_state_machine.c:320 >> (sofia/internal/50 at 192.168.1.114) State NEW >> 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4153 Channel >> sofia/internal/50 at 192.168.1.114 entering state [received][100] >> 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4164 Remote SDP: >> v=0 >> o=- 6 2 IN IP4 192.168.1.114 >> s=CounterPath X-Lite 3.0 >> c=IN IP4 192.168.1.114 >> t=0 0 >> m=audio 35824 RTP/AVP 107 0 8 101 >> a=rtpmap:107 BV32/16000 >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-15 >> a=alt:1 3 : KqvAzzQb 8KWQrMqE 192.168.1.114 35824 >> a=alt:2 2 : 7/J0Lq0c 31UYb9xD 192.168.197.1 35824 >> a=alt:3 1 : KVftFEHN Agl/D+Em 192.168.254.1 35824 >> >> 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare >> [BV32:107:16000:20]/[PCMA:8:8000:20] >> 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare >> [PCMU:0:8000:20]/[PCMA:8:8000:20] >> 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3585 Audio Codec Compare >> [PCMA:8:8000:20]/[PCMA:8:8000:20] >> 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:2354 Set Codec >> sofia/internal/50 at 192.168.1.114 PCMA/8000 20 ms 160 samples >> 2010-10-26 16:13:04.312500 [DEBUG] sofia_glue.c:3524 Set 2833 dtmf >> send/recv payload to 101 >> 2010-10-26 16:13:04.312500 [DEBUG] sofia.c:4310 >> (sofia/internal/50 at 192.168.1.114) State Change CS_NEW -> CS_INIT >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_INIT >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/50 at 192.168.1.114) State INIT >> 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:83 >> sofia/internal/50 at 192.168.1.114 SOFIA INIT >> 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:117 >> (sofia/internal/50 at 192.168.1.114) State Change CS_INIT -> CS_ROUTING >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:338 >> (sofia/internal/50 at 192.168.1.114) State INIT going to sleep >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:314 >> (sofia/internal/50 at 192.168.1.114) Running State Change CS_ROUTING >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:341 >> (sofia/internal/50 at 192.168.1.114) State ROUTING >> 2010-10-26 16:13:04.328125 [DEBUG] mod_sofia.c:140 >> sofia/internal/50 at 192.168.1.114 SOFIA ROUTING >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:77 >> sofia/internal/50 at 192.168.1.114 Standard ROUTING >> 2010-10-26 16:13:04.328125 [INFO] mod_dialplan_xml.c:418 Processing >> 50->70 in context default >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Nebenstellen-extern] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Nebenstellen-extern] caller_id_number(50) =~ /^6[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern10_11] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern10_11] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern12_13] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern12_13] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern14_15] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern14_15] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern16_17] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern16_17] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern18_19] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern18_19] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Systemnummern] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) >> [EBV-Systemnummern] destination_number(70) =~ /^2[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Mailboxen] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Mailboxen] >> destination_number(70) =~ /^3[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing [default->EBV-Tuerruf] >> continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) [EBV-Tuerruf] >> destination_number(70) =~ /^7[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (FAIL) [EBV-Tuerruf] >> caller_id_number(50) =~ /^4[0-9]$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 parsing >> [default->EBV-Amtsleitungen_50] continue=false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) >> [EBV-Amtsleitungen_50] caller_id_number(50) =~ /^.*/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 Regex (PASS) >> [EBV-Amtsleitungen_50] destination_number(70) =~ /^70$/ break=on-false >> Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE >> EBV-Amtsleitungen) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE >> ------------------------) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE >> caller_id_number : ${caller_id_number}) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE >> destination_number : ${destination_number}) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action log(CONSOLE user_name : >> ${user_name}) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action info() >> Dialplan: sofia/internal/50 at 192.168.1.114 Action >> set(ebv_nebenstellen=60,61) INLINE >> EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_nebenstellen=60,61) >> 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [ebv_nebenstellen]=[60,61] >> Dialplan: sofia/internal/50 at 192.168.1.114 Action >> set(ebv_mailbox_record=30) INLINE >> EXECUTE sofia/internal/50 at 192.168.1.114 set(ebv_mailbox_record=30) >> 2010-10-26 16:13:04.328125 [DEBUG] mod_dptools.c:816 >> sofia/internal/50 at 192.168.1.114 SET [ebv_mailbox_record]=[30] >> Dialplan: sofia/internal/50 at 192.168.1.114 Action set(ebv_audiosync=10) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action set(call_timeout=120) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action >> set(hangup_after_bridge=false) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action >> set(ignore_early_media=true) >> Dialplan: sofia/internal/50 at 192.168.1.114 Action >> easybyvoice(EProcessCallExtern,${user_name},${destination_number}) >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_state_machine.c:119 >> (sofia/internal/50 at 192.168.1.114) State Change CS_ROUTING -> CS_EXECUTE >> 2010-10-26 16:13:04.328125 [DEBUG] switch_core_session.c:1021 Send >> signal sofia/internal/50 at 192.168.1.114 [BREAK] >> >> >> >> 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 >> >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev >> http://www.freeswitch.org >> >> > > > > Thanks, I can not reproduce INCOMPATIBLE_DESTINATION with latest Sourcen from GIT Head. So it seams that all is working fine. I will continue testing. 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 From stamm at lyth.de Fri Oct 29 05:01:39 2010 From: stamm at lyth.de (Achim Stamm) Date: Fri, 29 Oct 2010 14:01:39 +0200 Subject: [Freeswitch-dev] How to get Peer Session after Bridge (Originate) Message-ID: <4CCAB7A3.2000002@lyth.de> 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 at 192.168.1.50,user/61 at 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 From grw.freeswitch at gmail.com Fri Oct 29 05:47:39 2010 From: grw.freeswitch at gmail.com (Geovani Ricardo Wiedenhoft) Date: Fri, 29 Oct 2010 10:47:39 -0200 Subject: [Freeswitch-dev] Searching for a valid extension. In-Reply-To: References: Message-ID: Thanks for help. We solved the problem with a specific digit at the end of the dialed number. On calls originated from an FXS branch, the Endpoint searches for a valid extension (digits sent) after the DTMF '#' or after the timeout (option fxs-digit-timeout). That search is done in the context defined in section , or if no context configured, the search is done in context defined in context-fxs. :) On Thu, Oct 14, 2010 at 2:45 PM, Anthony Minessale wrote: > You have to run the call into your own logic, either some XML REGEX or > a script etc and you manually return ?INVALID_NUMBER_FORMAT when you > want to signal to your phone to collect more digits. > > again, the dialplan is dynamic, fluid and stackable you cannot > statically map every extension but you don't need to. ?Once you build > the functionality that hanging up with INVALID_NUMBER_FORMAT means > collect more digits and any other cause means you have dialed an > invalid number, you can go develop a million ways to send this message > back to your module and not make the module care about it. ?So you are > hijacking that one cause to not actually hangup the channel. > > > > > > > > > > On Thu, Oct 14, 2010 at 12:16 PM, Geovani Ricardo Wiedenhoft > wrote: >> Thanks for the sugestions. >> >> I checked carefully every step, however, I got some questions. >> >> We tested the originate with the loopback endpoint, because we need to pass >> through the dialplan. >> >> My context: >> >> >> ? >> ??? >> ????? >> ??? >> ? >> >> >> >> Test: >> freeswitch at geovani> originate loopback/10/khomp-SIP/XML 1002 >> >> >> -ERR NO_ROUTE_DESTINATION >> >> >> >> In this test, we send the digits 10 (simulating the reception of these >> digits in the FXS) for khomp-SIP context in XML. I expected the >> INVALID_NUMBER_FORMAT return (accept more digits and try again), but the >> result was NO_ROUTE_DESTINATION. This happened with the switch_ivr_originate >> function too. >> >> switch_ivr_originate(NULL, &session, &cause, dialstring.c_str(), timeout, >> NULL, NULL, NULL, NULL, NULL, SOF_NONE, NULL); >> >> cause = 3 = NO_ROUTE_DESTINATION >> >> >> In previous email I did not say, we can make calls with timeout between >> digits, but my goal is to anticipate the call if possible checking of the >> extension/context(exact match). Also, we need verify what context configured >> by the user is used. >> >> >> Thanks again Anthony Minessale and Mathieu Parent, but the others options >> use timeout for connections, if we understand completely. >> >> >> >> On Mon, Oct 11, 2010 at 5:44 PM, Anthony Minessale >> wrote: >>> >>> We don't have a static monolithic dialplan like asterisk, there can be >>> many dialplans or dynamic dialplans that reach out to external >>> services. >>> >>> The proper way to implement overlap dialing on a per-protocol basis would >>> be: >>> >>> 1) Separate your native channel from the FreeSWITCH channel so you can >>> create a FreeSWITCH session and attach the native channel. >>> >>> 2) send the call to the configured dialplan and allow that dialplan >>> module to work out it's own ambiguities and respond: >>> >>> SWITCH_CAUSE_INVALID_NUMBER_FORMAT or cause 28 >>> >>> 3) when you see this cause accept more digits and try again until you >>> get some other cause code. >>> >>> >>> This is how it's done in sip by doing an entire new call each time you >>> need to dial more digits. >>> >>> >>> >>> The other way which we do in FreeTDM is to define 2 regex, one for >>> anything that is valid and one for anything that is invalid and >>> consult this regex on each digit until you know one way or another. >>> >>> >>> >>> >>> >>> >>> On Mon, Oct 11, 2010 at 3:12 PM, Geovani Ricardo Wiedenhoft >>> wrote: >>> > 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 >>> > >>> > _______________________________________________ >>> > FreeSWITCH-dev mailing list >>> > FreeSWITCH-dev at 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/ >>> Twitter: http://twitter.com/FreeSWITCH_wire >>> >>> AIM: anthm >>> MSN:anthony_minessale at hotmail.com >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>> IRC: irc.freenode.net #freeswitch >>> >>> FreeSWITCH Developer Conference >>> sip:888 at conference.freeswitch.org >>> googletalk:conf+888 at conference.freeswitch.org >>> pstn:+19193869900 >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > From anthony.minessale at gmail.com Fri Oct 29 07:44:11 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 29 Oct 2010 09:44:11 -0500 Subject: [Freeswitch-dev] How to get Peer Session after Bridge (Originate) In-Reply-To: <4CCAB7A3.2000002@lyth.de> References: <4CCAB7A3.2000002@lyth.de> Message-ID: you should not be interacting with originate like that from another thread. you do not have access to the channels it's trying to call, peer_session is only populated with the call that succeeds once it happens. If none of them succeed, the pointer to cause code you supply to originate will return the cause. originate is designed to produce either a session or a cause code based on the input you provide and that's all. On Fri, Oct 29, 2010 at 7:01 AM, Achim Stamm wrote: > 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 at 192.168.1.50,user/61 at 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 > > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From anthony.minessale at gmail.com Fri Oct 29 07:59:40 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Fri, 29 Oct 2010 09:59:40 -0500 Subject: [Freeswitch-dev] mod_loopback no ringback tone In-Reply-To: References: <20101025204118.4e281b00@mail.winet.ch> <6e4039f4-6577-4191-9215-3ea0ef3d7bc5@winet.ch> <3451ded7-c923-4cb5-b200-7c24e886e5fe@winet.ch> Message-ID: A is already answered or you have ignore_early_media=true somewhere. type these CLI commands: console loglevel debug sofia global siptrace on make the call and the debug will spell it out, if you can't find it post the log on pastebin. On Fri, Oct 29, 2010 at 4:59 AM, Bernhard Suttner wrote: > Hi, > > I get the ringback correctly, but from the signaling point of view, I get no register: > > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B > > B does send the ringing to FS. Loopback will set the flag to send the ringback to A but A does not get a RINGING. > > Is there maybe something other to set to get that working? > > Best regards, > Bernhard > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Bernhard Suttner > Gesendet: Dienstag, 26. Oktober 2010 19:07 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > Fixed. Problem was within mod_loopback but anthm did fix it. Thanks a lot again! > > -----Urspr?ngliche Nachricht----- > Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale > Gesendet: Dienstag, 26. Oktober 2010 18:03 > An: freeswitch-dev at lists.freeswitch.org > Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone > > you still did not update to latest git then > > On Tue, Oct 26, 2010 at 10:48 AM, Bernhard Suttner > wrote: >> Hi, >> >> I have not activated inbound-bypass-media and I tried with ignore-eary-media set to true and to false. Both times, I have no ringback. I added some debug stuff within mod_loopback.c and saw, that the code after switch_core_session_get_partner will not be called for msg->message_id = 7. >> >> Best regards, >> Bernhard >> >> -----Urspr?ngliche Nachricht----- >> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale >> Gesendet: Dienstag, 26. Oktober 2010 16:22 >> An: freeswitch-dev at lists.freeswitch.org >> Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone >> >> do you have inbound-bypass-media on? >> or are you not setting {ignore_early_media=true} when you call loopback >> >> The default config ext 9181 demonstrates this functionality and is >> confirmed to work. >> >> >> >> On Tue, Oct 26, 2010 at 3:09 AM, Bernhard Suttner >> wrote: >>> Hi, >>> >>> it does not work. I think the switch_core_get_partner function does not return the required session - so, the BOND_VARIABLE for sofia-/loopback-a is not set. >>> >>> Best regards, >>> Bernhard >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] Im Auftrag von Anthony Minessale >>> Gesendet: Montag, 25. Oktober 2010 21:22 >>> An: freeswitch-dev at lists.freeswitch.org >>> Betreff: Re: [Freeswitch-dev] mod_loopback no ringback tone >>> >>> We try. We're not always on top of things as much as we'd like but we >>> sure try =p >>> >>> >>> On Mon, Oct 25, 2010 at 1:41 PM, Bernhard Suttner >>> wrote: >>>> Hi, >>>> >>>> thanks for your fast answer. I tried the version about 4 hours ago. I will re-check it tomorrow. >>>> >>>> Thanks a lot for your VERY FAST RESPONSES. Within the asterisk project it does need more than X days to get a response if the whole asterisk does crash :-) >>>> >>>> Best regards, >>>> Bernhard >>>> >>>> >>>> ----- Original Message ----- >>>> From: Anthony Minessale [mailto:anthony.minessale at gmail.com] >>>> To: freeswitch-dev at lists.freeswitch.org >>>> Sent: Mon, 25 Oct 2010 19:00:57 +0200 >>>> Subject: Re: [Freeswitch-dev] mod_loopback no ringback tone >>>> >>>> >>>>> try again on latest HEAD that may have been broken over the weekend. >>>>> >>>>> >>>>> On Mon, Oct 25, 2010 at 11:11 AM, Bernhard Suttner >>>>> wrote: >>>>> > Hi, >>>>> > >>>>> > I have the following scenario >>>>> > >>>>> > A ----(SIP) ---> FS ---(loopback)---> FS ----(SIP)---> B >>>>> > >>>>> > FS is of course the same Freeswitch Sever. If B sends RINGING to FS the >>>>> RINGING will not be passed through to A because of the loopback module. >>>>> (That is was the trace does say). What has to happen on mod_loopback if it >>>>> does receive the RINGING? Does it have to do something like >>>>> switch_channel_mark_ring_ready, switch_channel_ring_ready or something else? >>>>> I think it has maybe something to do with the missing INDICATE_RINGING >>>>> section in mod_loopback. >>>>> > >>>>> > Best regards, >>>>> > Bernhard Suttner >>>>> > >>>>> > _______________________________________________ >>>>> > FreeSWITCH-dev mailing list >>>>> > FreeSWITCH-dev at 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/ >>>>> Twitter: http://twitter.com/FreeSWITCH_wire >>>>> >>>>> AIM: anthm >>>>> MSN:anthony_minessale at hotmail.com >>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>>>> IRC: irc.freenode.net #freeswitch >>>>> >>>>> FreeSWITCH Developer Conference >>>>> sip:888 at conference.freeswitch.org >>>>> googletalk:conf+888 at conference.freeswitch.org >>>>> pstn:+19193869900 >>>>> >>>>> _______________________________________________ >>>>> FreeSWITCH-dev mailing list >>>>> FreeSWITCH-dev at 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 at 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/ >>> Twitter: http://twitter.com/FreeSWITCH_wire >>> >>> AIM: anthm >>> MSN:anthony_minessale at hotmail.com >>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >>> IRC: irc.freenode.net #freeswitch >>> >>> FreeSWITCH Developer Conference >>> sip:888 at conference.freeswitch.org >>> googletalk:conf+888 at conference.freeswitch.org >>> pstn:+19193869900 >>> >>> _______________________________________________ >>> FreeSWITCH-dev mailing list >>> FreeSWITCH-dev at 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 at 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/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_minessale at hotmail.com >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:888 at conference.freeswitch.org >> googletalk:conf+888 at conference.freeswitch.org >> pstn:+19193869900 >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at 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/ > Twitter: http://twitter.com/FreeSWITCH_wire > > AIM: anthm > MSN:anthony_minessale at hotmail.com > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888 at conference.freeswitch.org > googletalk:conf+888 at conference.freeswitch.org > pstn:+19193869900 > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at 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 at 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 at 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/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale at hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888 at conference.freeswitch.org googletalk:conf+888 at conference.freeswitch.org pstn:+19193869900 From dujinfang at gmail.com Sat Oct 30 18:07:34 2010 From: dujinfang at gmail.com (Seven Du) Date: Sun, 31 Oct 2010 09:07:34 +0800 Subject: [Freeswitch-dev] playback in background Message-ID: Hi, I didn't find a way to playback in background in normal dialplan/lua scripts. I know how to use event socket to do async, but I still think it's useful in the following scenario and don't need a socket. - start playback in background - long time query (http or db query) - explicitly stop background playback, or implicitly stop when any further app executes(or when new data writes to the channel) - do other things using the query result Is there any existing solutions? or how hart to make a patch? if I make a patch to achieve that, would it be better to make in mod_commands or should I make a new module? What I'm thinking is to make a BUG in another thread and feed sound data to the channel. Is that the right approach? Thanks. -- Blog: http://www.dujinfang.com Proj:? http://www.freeswitch.org.cn From anthony.minessale at gmail.com Sat Oct 30 20:16:05 2010 From: anthony.minessale at gmail.com (Anthony Minessale) Date: Sat, 30 Oct 2010 22:16:05 -0500 Subject: [Freeswitch-dev] playback in background In-Reply-To: References: Message-ID: Lookup displace and uuid_displace On Oct 30, 2010 8:14 PM, "Seven Du" wrote: > Hi, > > I didn't find a way to playback in background in normal dialplan/lua > scripts. I know how to use event socket to do async, but I still think > it's useful in the following scenario and don't need a socket. > > - start playback in background > - long time query (http or db query) > - explicitly stop background playback, or implicitly stop when any > further app executes(or when new data writes to the channel) > - do other things using the query result > > Is there any existing solutions? or how hart to make a patch? if I > make a patch to achieve that, would it be better to make in > mod_commands or should I make a new module? > > What I'm thinking is to make a BUG in another thread and feed sound > data to the channel. Is that the right approach? > > Thanks. > > -- > Blog: http://www.dujinfang.com > Proj: http://www.freeswitch.org.cn > > _______________________________________________ > FreeSWITCH-dev mailing list > FreeSWITCH-dev at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101030/ecd36b24/attachment.html From dujinfang at gmail.com Sat Oct 30 23:23:39 2010 From: dujinfang at gmail.com (Seven Du) Date: Sun, 31 Oct 2010 14:23:39 +0800 Subject: [Freeswitch-dev] playback in background In-Reply-To: References: Message-ID: Cool. Thank you Anthony. Sorry I didn't look much hard. And, I found a few problems: 1) instead of displace, it's called displace_session. 2) the calling party hear nothing before echo, with or without the m flag. I want to hear MOH?while waiting in the sleep. 3) inconsistent syntax: limit mux vs flags limit, with or without + uuid_displace, [start|stop] [] [mux],session displace,mod_commands displace_session: [] [+time_limit_ms] I understand fix it might beak backward compatibilities, however, as they go to the same switch_ivr function it would be better if they looks like consistent. On Sun, Oct 31, 2010 at 11:16 AM, Anthony Minessale wrote: > Lookup displace and uuid_displace > > On Oct 30, 2010 8:14 PM, "Seven Du" wrote: >> Hi, >> >> I didn't find a way to playback in background in normal dialplan/lua >> scripts. I know how to use event socket to do async, but I still think >> it's useful in the following scenario and don't need a socket. >> >> - start playback in background >> - long time query (http or db query) >> - explicitly stop background playback, or implicitly stop when any >> further app executes(or when new data writes to the channel) >> - do other things using the query result >> >> Is there any existing solutions? or how hart to make a patch? if I >> make a patch to achieve that, would it be better to make in >> mod_commands or should I make a new module? >> >> What I'm thinking is to make a BUG in another thread and feed sound >> data to the channel. Is that the right approach? >> >> Thanks. >> >> -- >> Blog: http://www.dujinfang.com >> Proj:? http://www.freeswitch.org.cn >> >> _______________________________________________ >> FreeSWITCH-dev mailing list >> FreeSWITCH-dev at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > -- Blog: http://www.dujinfang.com Proj:? http://www.freeswitch.org.cn From jcherukuri_necc at yahoo.com Wed Oct 27 12:26:15 2010 From: jcherukuri_necc at yahoo.com (Jyotshna Cherukuri) Date: Wed, 27 Oct 2010 19:26:15 -0000 Subject: [Freeswitch-dev] stfu jitterbuffer in FS Message-ID: <92332.76985.qm@web110303.mail.gq1.yahoo.com> Hi, I enabled Jitterbuffer in FS for A leg of the call and when I set up packet loss simulation(4%) on my end client I expected FS to tag the lost packets as SFF_PLC but its not .I rather see the below code being executed . Could you please explain what this code does in stfu.c? i->miss_count++; if (i->miss_count > 10 || (i->in_queue->array_len == i->in_queue->array_size) || tried >= i->in_queue->array_size) { i->running = 0; i->interval = 0; i->out_queue->wr_len = i->out_queue->array_size; return NULL; } Any help is greatly appreciated Thanks Jyotshna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101027/cb6ea262/attachment.html