[Freeswitch-users] Call Recovery when using TCP

Anthony McGarry agtmcgarry at gmail.com
Thu Jul 25 00:49:27 MSD 2013


So this would make more sense. was scratching my head earlier… didn't make sense

Here's what fs gets 

INVITE sip:+353877857933 at voice.plannet21.ie:5060 SIP/2.0
Via: SIP/2.0/TCP 198.19.255.1:5060;branch=z9hG4bK42DC2424

Here's whats sent from recovering fs

INVITE sip:+35319032109 at 198.19.255.1:5060 SIP/2.0
Via: SIP/2.0/UDP 78.158.110.24;rport;branch=z9hG4bKXggpr14eHNNKH
Route: <sip:+35319032109 at 198.19.255.1:35556;transport=tcp>

Looking for differences the only one I can see is rport. I see on fisheye, for the update, I can see reference to sip_network_port, is it related, I have no experience with C. Does the initial invite need to have rport in the via?
As a test I added rport but still the same behaviour, although 33333 is not real and I just statically set it outgoing from uac, but this causes subsequent packets to update and have the rport present

FS in

INVITE sip:+353877857933 at voice.plannet21.ie:5060 SIP/2.0
Via: SIP/2.0/TCP 198.19.255.1:5060;branch=z9hG4bK4306116E;rport=33333

SIP/2.0 100 Trying
Via: SIP/2.0/TCP 198.19.255.1:5060;branch=z9hG4bK4306116E;rport=13129

FS Recover

INVITE sip:+35319032109 at 198.19.255.1:5060 SIP/2.0
Via: SIP/2.0/UDP 78.158.110.24;rport;branch=z9hG4bKKB0t2By0am6HB
Route: <sip:+35319032109 at 198.19.255.1:13129;transport=tcp>


On 24 Jul 2013, at 18:18, Anthony Minessale <anthony.minessale at gmail.com> wrote:

> Interesting. In the test I did when making the patch, the recover INVITE was tcp, it depends heavily on the VIA header on the original invite having TCP present in it.
> 
> send 1281 bytes to tcp/[1.x.x.x]:5060 at 17:14:42.035251:
>    ------------------------------------------------------------------------
>    INVITE sip:mod_sofia at 1.x.x.x:5060 SIP/2.0
>    Via: SIP/2.0/TCP 1.x.x.x;branch=z9hG4bKS0Q3SKXvB2Q9r;rport=50938
>    Route: <sip:1004 at 1.x.x.x:50938;transport=tcp>
> 
> 
> 
> On Wed, Jul 24, 2013 at 5:34 AM, Anthony McGarry <agtmcgarry at gmail.com> wrote:
> Thanks Anthony, yes latest head worked.
> 
> A leg still sends the recovery INVITE as UDP however now it has the route header with no loose routing. 
> 
> Route: <sip:+35314611947 at 198.19.255.1:61767;transport=tcp>
> 
> So I'm assuming the UAC uses this info to find session in UAC Table and reestablishes the session, but as UDP, even though UAC specifically is told to only use TCP.
> 
> To test I put a firewall in the path and blocked UDP 5060 and the call failed to recover, as expected.
> 
> So I think for this to work UDP will still need to be open on the UAC to recover the call.
> 
> As you said it won't work for all UACs or all situations but its a workable solution.
> 
> For reference this works when UAC is either Cisco or Dialogic.
> 
> 
> On 23 Jul 2013, at 19:53, Anthony Minessale <anthony.minessale at gmail.com> wrote:
> 
>> Try latest head, no promises on every endpoint.
>> P.S. try Jira next time.
>> 
>> 
>> 
>> On Tue, Jul 23, 2013 at 11:24 AM, Anthony McGarry <agtmcgarry at gmail.com> wrote:
>> I have pasted up the logs from a test call A leg UDP, B leg TCP that recovered ok
>> 
>> initial call - fs crashed
>> http://pastebin.com/0xe0QyFC
>> 
>> recovered call
>> http://pastebin.com/ByjJ4nhf
>> 
>> 
>> On 23 Jul 2013, at 16:39, Steven Ayre <steveayre at gmail.com> wrote:
>> 
>>> Is the B-leg the same call, or a new call?
>>> 
>>> 
>>> 
>>> On 23 July 2013 16:31, Anthony McGarry <agtmcgarry at gmail.com> wrote:
>>> Thanks Brian,
>>> 
>>> Initially I though the same and looked for something to migrate the tcp session, tcpcp and sockmi, but no joy.
>>> 
>>> I was doing some more testing and noticed that if the B leg was TCP and the A leg UDP the call recovered.
>>> 
>>> So I though my earlier assumption about TCP connection dropping was wrong as it seems the B leg reestablishes the session on the recovering server.
>>> The issue just seems to be the recovery of the A leg. FS always sends the A leg recovery INVITE as UDP. Even if original call was TCP. If I could force it to use TCP I believe it would recover the call.
>>> 
>>> Below is a call with A leg as UDP and B leg as TCP thats recovers fine.
>>> 
>>> 2013-07-23 16:19:46.419717 [NOTICE] switch_channel.c:1030 New Channel sofia/private/+35319032109 at 198
>>> 2013-07-23 16:19:46.419717 [NOTICE] switch_channel.c:1028 Rename Channel sofia/private/+35319032109@
>>> 2013-07-23 16:19:46.419717 [NOTICE] switch_core_sqldb.c:2744 Resurrecting fallen channel sofia/priva
>>> 2013-07-23 16:19:46.439717 [NOTICE] switch_channel.c:1030 New Channel sofia/internal/0877857933 at 10.1
>>> 2013-07-23 16:19:46.439717 [NOTICE] switch_channel.c:1028 Rename Channel sofia/internal/0877857933 at 1
>>> 2013-07-23 16:19:46.439717 [NOTICE] switch_core_sqldb.c:2744 Resurrecting fallen channel sofia/inter
>>> send 1110 bytes to udp/[10.101.23.203]:5060 at 15:19:46.459562:
>>>    ------------------------------------------------------------------------
>>>    INVITE sip:0877857933 at 10.101.23.203:5060 SIP/2.0
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK3tjcc8KU636FS
>>>    Route: <sip:0877857933 at 10.101.23.203:5060;lr>
>>>    Max-Forwards: 70
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    CSeq: 46960329 INVITE
>>>    Contact: <sip:0877857933 at 10.101.23.110:5060>
>>>    User-Agent: LAB - SBC
>>>    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
>>>    Supported: timer, precondition, path, replaces
>>>    Allow-Events: talk, hold, conference, refer
>>>    Privacy: none
>>>    Content-Type: application/sdp
>>>    Content-Disposition: session
>>>    Content-Length: 246
>>>    X-FS-Support: update_display,send_info
>>>    P-Asserted-Identity: "ae019032109" <sip:ae019032109 at 10.101.23.203>
>>> 
>>>    v=0
>>>    o=FreeSWITCH 1374564092 1374564094 IN IP4 10.101.24.110
>>>    s=FreeSWITCH
>>>    c=IN IP4 10.101.24.110
>>>    t=0 0
>>>    m=audio 28694 RTP/AVP 8 101 13
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-16
>>>    a=rtpmap:13 CN/8000
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> recv 398 bytes from udp/[10.101.23.203]:5060 at 15:19:46.463116:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 100 Trying
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK3tjcc8KU636FS;received=10.101.23.110
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    CSeq: 46960329 INVITE
>>>    Server: Dialogic-SIP/10.5.3.372 IMG2_DEG 2
>>>    Content-Length: 0
>>> 
>>>    ------------------------------------------------------------------------
>>> recv 961 bytes from udp/[10.101.23.203]:5060 at 15:19:46.463966:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 200 OK
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK3tjcc8KU636FS;received=10.101.23.110
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    Contact: <sip:0877857933 at 10.101.23.203:5060>
>>>    CSeq: 46960329 INVITE
>>>    Server: Dialogic-SIP/10.5.3.372 IMG2_DEG 2
>>>    Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
>>>    Supported: path, replaces, timer, tdialog
>>>    Require: timer
>>>    Session-Expires: 1800;refresher=uas
>>>    Accept: application/sdp, application/dtmf-relay, text/plain
>>>    Content-Type: application/sdp
>>>    Content-Length: 239
>>> 
>>>    v=0
>>>    o=Dialogic_SDP 963778 1 IN IP4 10.101.23.203
>>>    s=Dialogic-SIP
>>>    c=IN IP4 10.101.24.203
>>>    t=0 0
>>>    m=audio 8332 RTP/AVP 8 101
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-15
>>>    a=silenceSupp:off - - - -
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> recv 961 bytes from udp/[10.101.23.203]:5060 at 15:19:47.101507:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 200 OK
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK3tjcc8KU636FS;received=10.101.23.110
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    Contact: <sip:0877857933 at 10.101.23.203:5060>
>>>    CSeq: 46960329 INVITE
>>>    Server: Dialogic-SIP/10.5.3.372 IMG2_DEG 2
>>>    Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
>>>    Supported: path, replaces, timer, tdialog
>>>    Require: timer
>>>    Session-Expires: 1800;refresher=uas
>>>    Accept: application/sdp, application/dtmf-relay, text/plain
>>>    Content-Type: application/sdp
>>>    Content-Length: 239
>>> 
>>>    v=0
>>>    o=Dialogic_SDP 963778 1 IN IP4 10.101.23.203
>>>    s=Dialogic-SIP
>>>    c=IN IP4 10.101.24.203
>>>    t=0 0
>>>    m=audio 8332 RTP/AVP 8 101
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-15
>>>    a=silenceSupp:off - - - -
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> recv 961 bytes from udp/[10.101.23.203]:5060 at 15:19:48.070746:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 200 OK
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK3tjcc8KU636FS;received=10.101.23.110
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    Contact: <sip:0877857933 at 10.101.23.203:5060>
>>>    CSeq: 46960329 INVITE
>>>    Server: Dialogic-SIP/10.5.3.372 IMG2_DEG 2
>>>    Allow: INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
>>>    Supported: path, replaces, timer, tdialog
>>>    Require: timer
>>>    Session-Expires: 1800;refresher=uas
>>>    Accept: application/sdp, application/dtmf-relay, text/plain
>>>    Content-Type: application/sdp
>>>    Content-Length: 239
>>> 
>>>    v=0
>>>    o=Dialogic_SDP 963778 1 IN IP4 10.101.23.203
>>>    s=Dialogic-SIP
>>>    c=IN IP4 10.101.24.203
>>>    t=0 0
>>>    m=audio 8332 RTP/AVP 8 101
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-15
>>>    a=silenceSupp:off - - - -
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> send 1175 bytes to tcp/[198.19.255.1]:5060 at 15:19:49.473346:
>>>    ------------------------------------------------------------------------
>>>    INVITE sip:+35319032109 at 198.19.255.1:5060;transport=tcp SIP/2.0
>>>    Via: SIP/2.0/TCP 78.158.110.24;rport;branch=z9hG4bKBNF06yNpU187Q
>>>    Via: SIP/2.0/TCP 78.158.110.24;rport;branch=z9hG4bKZ21tSFUQvy38c
>>>    Max-Forwards: 69
>>>    From: "+353877857933" <sip:+353877857933 at 78.158.110.24>;tag=BK8QvjBeDHXtN
>>>    To: <sip:+35319032109 at 198.19.255.1;transport=tcp>;tag=397C7E04-26CA
>>>    Call-ID: f9547f1f-6e4d-1231-028b-001f290685a4
>>>    CSeq: 46960329 INVITE
>>>    Contact: <sip:+35319032109 at 78.158.110.24:5060;transport=tcp>
>>>    User-Agent: PlanNet21 Communications - SBC
>>>    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
>>>    Supported: timer, precondition, path, replaces
>>>    Allow-Events: talk, hold, conference, refer
>>>    Privacy: none
>>>    Content-Type: application/sdp
>>>    Content-Disposition: session
>>>    Content-Length: 246
>>>    X-FS-Support: update_display,send_info
>>>    P-Asserted-Identity: "+353877857933" <sip:+353877857933 at 78.158.110.24>
>>> 
>>>    v=0
>>>    o=FreeSWITCH 1374569678 1374569680 IN IP4 78.158.110.24
>>>    s=FreeSWITCH
>>>    c=IN IP4 78.158.110.24
>>>    t=0 0
>>>    m=audio 23108 RTP/AVP 8 101 13
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-16
>>>    a=rtpmap:13 CN/8000
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> recv 484 bytes from tcp/[198.19.255.1]:5060 at 15:19:49.536636:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 100 Trying
>>>    Via: SIP/2.0/TCP 78.158.110.24;rport;branch=z9hG4bKBNF06yNpU187Q,SIP/2.0/TCP 78.158.110.24;rport;
>>>    From: "+353877857933" <sip:+353877857933 at 78.158.110.24>;tag=BK8QvjBeDHXtN
>>>    To: <sip:+35319032109 at 198.19.255.1;transport=tcp>;tag=397C7E04-26CA
>>>    Date: Tue, 23 Jul 2013 15:19:49 GMT
>>>    Call-ID: f9547f1f-6e4d-1231-028b-001f290685a4
>>>    CSeq: 46960329 INVITE
>>>    Allow-Events: telephone-event
>>>    Server: Cisco-SIPGateway/IOS-12.x
>>>    Content-Length: 0
>>> 
>>>    ------------------------------------------------------------------------
>>> recv 1073 bytes from tcp/[198.19.255.1]:5060 at 15:19:49.601460:
>>>    ------------------------------------------------------------------------
>>>    SIP/2.0 200 OK
>>>    Via: SIP/2.0/TCP 78.158.110.24;rport;branch=z9hG4bKBNF06yNpU187Q,SIP/2.0/TCP 78.158.110.24;rport;
>>>    From: "+353877857933" <sip:+353877857933 at 78.158.110.24>;tag=BK8QvjBeDHXtN
>>>    To: <sip:+35319032109 at 198.19.255.1;transport=tcp>;tag=397C7E04-26CA
>>>    Date: Tue, 23 Jul 2013 15:19:49 GMT
>>>    Call-ID: f9547f1f-6e4d-1231-028b-001f290685a4
>>>    CSeq: 46960329 INVITE
>>>    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
>>>    Allow-Events: telephone-event
>>>    Remote-Party-ID: "Ian McGrath" <sip:+1947 at 198.19.255.1>;party=called;screen=yes;privacy=off
>>>    Contact: <sip:+35319032109 at 198.19.255.1:5060;transport=tcp>
>>>    Supported: replaces
>>>    Supported: sdp-anat
>>>    Server: Cisco-SIPGateway/IOS-12.x
>>>    Supported: timer
>>>    Content-Type: application/sdp
>>>    Content-Length: 247
>>> 
>>>    v=0
>>>    o=CiscoSystemsSIP-GW-UserAgent 3902 8614 IN IP4 198.19.255.1
>>>    s=SIP Call
>>>    c=IN IP4 198.19.255.1
>>>    t=0 0
>>>    m=audio 19050 RTP/AVP 8 101
>>>    c=IN IP4 198.19.255.1
>>>    a=rtpmap:8 PCMA/8000
>>>    a=rtpmap:101 telephone-event/8000
>>>    a=fmtp:101 0-16
>>>    a=ptime:20
>>>    ------------------------------------------------------------------------
>>> send 440 bytes to tcp/[198.19.255.1]:5060 at 15:19:49.603288:
>>>    ------------------------------------------------------------------------
>>>    ACK sip:+35319032109 at 198.19.255.1:5060;transport=tcp SIP/2.0
>>>    Via: SIP/2.0/TCP 78.158.110.24;rport;branch=z9hG4bKcy8r8S6SraZtK
>>>    Max-Forwards: 70
>>>    From: "+353877857933" <sip:+353877857933 at 78.158.110.24>;tag=BK8QvjBeDHXtN
>>>    To: <sip:+35319032109 at 198.19.255.1;transport=tcp>;tag=397C7E04-26CA
>>>    Call-ID: f9547f1f-6e4d-1231-028b-001f290685a4
>>>    CSeq: 46960329 ACK
>>>    Contact: <sip:+35319032109 at 78.158.110.24:5060;transport=tcp>
>>>    Content-Length: 0
>>> 
>>>    ------------------------------------------------------------------------
>>> send 466 bytes to udp/[10.101.23.203]:5060 at 15:19:49.606747:
>>>    ------------------------------------------------------------------------
>>>    ACK sip:0877857933 at 10.101.23.203:5060 SIP/2.0
>>>    Via: SIP/2.0/UDP 10.101.23.110;rport;branch=z9hG4bK43B5D34y3cX2m
>>>    Route: <sip:0877857933 at 10.101.23.203:5060;lr>
>>>    Max-Forwards: 70
>>>    From: <sip:ae019032109 at 10.101.23.110:5060>;tag=B8BUB47FmmerF
>>>    To: <sip:0877857933 at 10.101.23.203>;tag=95ffcd055e0f78f7d5d397020e89288dba056a96
>>>    Call-ID: 1054-453-6232013151830-IMG2_DEG-2-10.101.23.203
>>>    CSeq: 46960329 ACK
>>>    Contact: <sip:0877857933 at 10.101.23.110:5060>
>>>    Content-Length: 0
>>> 
>>>    ------------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> 
>>> On 23 Jul 2013, at 14:47, Brian West <brian at freeswitch.org> wrote:
>>> 
>>> > You can't do call recovery on TCP at the moment,  You have no way to re-establish the TCP connections once FreeSWITCH goes down.
>>> >
>>> > /b
>>> >
>>> > Em Jul 23, 2013, às 8:01 AM, Anthony McGarry <agtmcgarry at gmail.com> escreveu:
>>> >
>>> >> Anyone using TCP in this scenario? Cannot find what I'm missing.
>>> >
>>> >
>>> > _________________________________________________________________________
>>> > Professional FreeSWITCH Consulting Services:
>>> > consulting at freeswitch.org
>>> > http://www.freeswitchsolutions.com
>>> >
>>> > 
>>> > 
>>> >
>>> > Official FreeSWITCH Sites
>>> > http://www.freeswitch.org
>>> > http://wiki.freeswitch.org
>>> > http://www.cluecon.com
>>> >
>>> > FreeSWITCH-users mailing list
>>> > FreeSWITCH-users at lists.freeswitch.org
>>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> > http://www.freeswitch.org
>>> 
>>> 
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>> 
>>> 
>>> 
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>> 
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>> 
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>> 
>>> 
>>> 
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>> 
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>> 
>> 
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>> 
>> 
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>> 
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> 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
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>> 
>> 
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>> 
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130724/580e2f6b/attachment-0001.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list