January 2011 - FreeSWITCH-users - FreeSWITCH Mailing Lists

SpanDSP: Timed out waiting for initial communication
by Jonas Gauffin 19 Jan '11

19 Jan '11

Hello, I've got a fax service used to send an outbound faxes to lot of receivers. Sometimes I get "Timed out waiting for initial communication". What does it mean? Have freeswitch connected to the other end, but no fax tone is detected? Or something else? Should I retry again or remove the receiver from the list? Thanks, Jonas

1 0

Next version of Gemeinschaft based on FreeSWITCH
by Thomas Mueller 19 Jan '11

19 Jan '11

just read at GOLEM* that next verion of "Gemeinschaft"** is backed by FreeSWITCH and not Asterisk anymore. Article states that the relase is expected Q3 2011. IMHO a nice frontend . - Thomas * http://www.golem.de/1101/80818.html ** http://amooma.de/

3 3

Re: [Freeswitch-users] my FS doesn't answer on OK from the provider
by ZILOT 19 Jan '11

19 Jan '11

I have entered "sofia profile sipinterface_1 siptrace off" and have seen Trying from my provider, but i can't see "OK" If I enter "sofia loglevel all 9" it I don't manage to disassemble with a stream of messages. freeswitch> sofia loglevel <all|default|tport|iptsec|nea|nta|nth_client|nth_server|nua|soa|sresolv|stun> [0-9] That from this it is better to look? recv 416 bytes from udp/[77.72.17.23]:5060 at 12:25:57.236897: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bKy0U8cX4FFvDQr From: "DEN78141_140" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=52egjQQgr1Kmr To: <sip:79213777763@77.72.17.23>;tag=7aff7900ffff3610ff00001372630472 Call-ID: 1ba1a990-9e6a-122e-1782-33002db2a994 CSeq: 7383914 INVITE Contact: <sip:79213777763@77.72.17.23;user=phone> Server: MERA MSIP v.1.0.2 Content-Length: 0 Wed, 19 Jan 2011 11:05:18 +0000 письмо от Steven Ayre <steveayre(a)gmail.com>: What does debugging log and siptrace show? > sofia global siptrace on You can also look at the Sofia SIP stack debugging information to see if there's an error occuring in the stack that's ignoring the packet. > sofia loglevel all 9 -Steve 2011/1/19 ZILOT < yurazilot1(a)list.ru (http://win.mail.ru/cgi-bin/sentmsg?compose&To=yurazilot1@list.ru) > I have one problem - my FS doesn't answer on OK from the provider. Probably the problem consists in an incorrectness incoming OK. Please help. U 2011/01/19 11:04:05.243062 194.190.211.190:5060 (http://194.190.211.190:5060/) -> 77.72.17.23:5060 (http://77.72.17.23:5060/) INVITE sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) SIP/2.0. Via: SIP/2.0/UDP 194.190.211.190;rport;branch=z9hG4bK6rQjK6B04ZeNN. Max-Forwards: 69. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:gw+trunk_8@194.190.211.190:5060;transport=udp;gw=trunk_8>. User-Agent: Configured by 2600hz. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: precondition, path, replaces. Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 298. X-FS-Support: update_display. Remote-Party-ID: "DEN78141_120" < sip:DEN78141_120@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ADEN78141_120@77.72.…) >;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1295404175 1295404176 IN IP4 194.190.211.190. s=FreeSWITCH. c=IN IP4 194.190.211.190. t=0 0. m=audio 20070 RTP/AVP 0 9 8 101 13. a=rtpmap:0 PCMU/8000. a=rtpmap:9 G722/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=ptime:30. U 2011/01/19 11:04:05.288882 77.72.17.23:5060 (http://77.72.17.23:5060/) -> 194.190.211.190:5060 (http://194.190.211.190:5060/) SIP/2.0 100 Trying. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) ;user=phone>. Server: MERA MSIP v.1.0.2. Content-Length: 0. . U 2011/01/19 11:04:06.609863 77.72.17.23:5060 (http://77.72.17.23:5060/) -> 194.190.211.190:5060 (http://194.190.211.190:5060/) SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) ;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424317 1295424317 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.238660 77.72.17.23:5060 (http://77.72.17.23:5060/) -> 194.190.211.190:5060 (http://194.190.211.190:5060/) SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) ;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.246657 77.72.17.23:5060 (http://77.72.17.23:5060/) -> 194.190.211.190:5060 (http://194.190.211.190:5060/) SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) ;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.747863 77.72.17.23:5060 (http://77.72.17.23:5060/) -> 194.190.211.190:5060 (http://194.190.211.190:5060/) SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" < sip:TCAPI_User@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3ATCAPI_User@77.72.17…) ;transport=udp>;tag=vZcKXKa0Q7B1e. To: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) >;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: < sip:74742515541@77.72.17.23 (http://win.mail.ru/cgi-bin/sentmsg?compose&To=sip%3A74742515541@77.72.1…) ;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. -- Почта(a)Mail.Ru в твоем мобильном. Просто зайди с телефона на m.mail.ru (http://m.mail.ru/) _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org (http://win.mail.ru/cgi-bin/sentmsg?compose&To=FreeSWITCH-users@lists.fr…) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users (http://lists.freeswitch.org/mailman/listinfo/freeswitch-users) UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users (http://lists.freeswitch.org/mailman/options/freeswitch-users) http://www.freeswitch.org (http://www.freeswitch.org/) _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org (http://win.mail.ru/cgi-bin/sentmsg?compose&To=FreeSWITCH%2dusers@lists.…) http://lists.freeswitch.org/mailman/listinfo/freeswitch-users (http://lists.freeswitch.org/mailman/listinfo/freeswitch-users) UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users (http://lists.freeswitch.org/mailman/options/freeswitch-users) http://www.freeswitch.org (http://www.freeswitch.org/)

1 0

TDM line maximum
by Holger Esser 19 Jan '11

19 Jan '11

All, Does anybody have experience with implementing 4 Sangoma octal cards and bridge these channels to SIP sessions on a single server for a total of 1536 sessions (TDM+SIP) Regards, Holger

4 9

Using "Reason" from hangup
by Ross McKillop 19 Jan '11

19 Jan '11

I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows; > SIP/2.0 480 Temporarily Unavailable. > Reason: Q.850;cause=31. This is then passed by FreeSWITCH back to the A party as > SIP/2.0 480 Temporarily Unavailable. > Reason: Q.850;cause=16;text="NORMAL_CLEARING". Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ? I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.; > <action application="hangup" data="${bridge_hangup_cause}" /> But that hasn't affected the behaviour at all. Regards, Ross

5 10

my FS doesn't answer on OK from the provider
by ZILOT 19 Jan '11

19 Jan '11

I have one problem - my FS doesn't answer on OK from the provider. Probably the problem consists in an incorrectness incoming OK. Please help. U 2011/01/19 11:04:05.243062 194.190.211.190:5060 -> 77.72.17.23:5060 INVITE sip:74742515541@77.72.17.23 SIP/2.0. Via: SIP/2.0/UDP 194.190.211.190;rport;branch=z9hG4bK6rQjK6B04ZeNN. Max-Forwards: 69. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:gw+trunk_8@194.190.211.190:5060;transport=udp;gw=trunk_8>. User-Agent: Configured by 2600hz. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: precondition, path, replaces. Allow-Events: talk, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 298. X-FS-Support: update_display. Remote-Party-ID: "DEN78141_120" <sip:DEN78141_120@77.72.17.23>;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1295404175 1295404176 IN IP4 194.190.211.190. s=FreeSWITCH. c=IN IP4 194.190.211.190. t=0 0. m=audio 20070 RTP/AVP 0 9 8 101 13. a=rtpmap:0 PCMU/8000. a=rtpmap:9 G722/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=ptime:30. U 2011/01/19 11:04:05.288882 77.72.17.23:5060 -> 194.190.211.190:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:74742515541@77.72.17.23;user=phone>. Server: MERA MSIP v.1.0.2. Content-Length: 0. . U 2011/01/19 11:04:06.609863 77.72.17.23:5060 -> 194.190.211.190:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:74742515541@77.72.17.23;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424317 1295424317 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.238660 77.72.17.23:5060 -> 194.190.211.190:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:74742515541@77.72.17.23;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.246657 77.72.17.23:5060 -> 194.190.211.190:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:74742515541@77.72.17.23;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. U 2011/01/19 11:04:14.747863 77.72.17.23:5060 -> 194.190.211.190:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 194.190.211.190:5060;rport;branch=z9hG4bK6rQjK6B04ZeNN. From: "DEN78141_120" <sip:TCAPI_User@77.72.17.23;transport=udp>;tag=vZcKXKa0Q7B1e. To: <sip:74742515541@77.72.17.23>;tag=0eff5d003cff3610ff00001372630472. Call-ID: 86959393-9e45-122e-1782-33002db2a994. CSeq: 7376058 INVITE. Contact: <sip:74742515541@77.72.17.23;user=phone>. Server: MERA MSIP v.1.0.2. Content-Type: application/sdp. Content-Length: 212. . v=0. o=- 1295424325 1295424325 IN IP4 77.72.17.23. s=-. c=IN IP4 77.72.17.23. t=0 0. m=audio 18360 RTP/AVP 0 8 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. -- Почта(a)Mail.Ru в твоем мобильном. Просто зайди с телефона на m.mail.ru

2 1

Dial Plan timing error
by Charles Bujold 19 Jan '11

19 Jan '11

Need help configuring the following dial plan. To make a PSTN call I have to call extension 510 or 520, then bridge and answer the call to get a dial tone. Then dial the outgoing number. My problem is that the send_dtmf command does not wait 1 second (W command) after the answer. It seems to delay the answer command by 1 second. How do I get the call to answer and then wait 1 second and then send /dial the number? Thanks CJB <extension name="Local 7 digit calls" > <condition field="destination_number" expression="^(\d{7})$"> <action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/> <action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/> <action application="set" data="hangup_after_bridge=true"/> <action application="send_dtmf" data="W$1@100"/> <action application="bridge" data="sofia/${domain}/510"/> <action application="bridge" data="sofia/${domain}/520"/> <action application="bridge" data="error/user_busy" /> </condition> </extension>

3 2

user hangup in a conference
by Madovsky 19 Jan '11

19 Jan '11

is there a way to know whe a conference doesn't exist anymore from the dialplan ? like after this line <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="conference" data="conf_name}@default+${conf_pin}"/> i'd like to know if there are members yet in the conference <action application="set" data="myVar=${conference(conf_name list)}"/> it works if the user send a dtmf key lke # (from conference default control keys) but if the user hangup as normal so the dialplan doesn't continue after the conference XML line. Any idea ? Thanks

2 2

Music on hold runs only once with bind_meta_app or bind_digit_action
by Dmitry Sytchev 18 Jan '11

18 Jan '11

Hi all, Sorry for duplicating this issue (http://lists.freeswitch.org/pipermail/freeswitch-users/2011-January/067460.…) but I run some tests and have additional info. A calls B B answers A A launches meta app by using *7, application calls read() and collects extension digits. B listens to MOH A calls att_xfer to entered extension via local channel or direct sofia bridge to C. (no difference for the issue). We are testing situation when bridge fails - in this case A trying to repeat *7 and re-enter extension, so: A is still connected to B A launches meta app by using *7, application calls read() and collects digits. B DOESN'T hear MOH, just silence A calls att_xfer to entered extension via local channel or direct sofia bridge to C. Att_xfer works fine by itself except for second and following retries there is no MOH at all. There are no difference for local channel proxy or direct sofia bridge. What can be done to track down and fix this issue? Also, to make att_xfer work with local_channel I had to set loopback_bowout=false and loopback_bowout_on_execute=false, but I can't find any details on their behavior. Which one is really needed, and what they exactly do? Thanks in advance -- Best regards, Dmitry Sytchev, IT Engineer

1 0

C# new ESLevent(
by John Rose 18 Jan '11

18 Jan '11

Does someone have an example of the C# EslConnection method SendEvent with a new ESLevent ? Like how to fill in any info on the ESLevent object before sending it? Thanks, John

3 3