Call transfer fails in proxy media and bypass media modes in FreeSWITCH revision 15700
I have updated my FreeSWITCH installation to revision 15700. I am experiencing call transfer problems whenever proxy media or bypass media is enabled. When proxy media and bypass media are both disabled, the call transfer does not fail and there are no audio issues. When proxy media mode is enabled, the call stays up after the transfer occurs, but there is no audio flowing on either end of the call. When bypass media mode is enabled, there is no audio flowing on either end of the call, and the call actually gets disconnected. I have collected detailed traces using the TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch command. I have attached a ZIP file named freeswitch-rev15700-traces-112809-2210.zip, which includes the following traces: - freeswitch-rev15700-trace-112809-2210-proxyandbypassoff.txt - A trace with both media proxying and media bypass disabled. The call is being transferred without any problems in this scenario. - freeswitch-rev15700-trace-112809-2210-proxyonandbypassoff.txt - A trace with media proxying enabled and media bypass disabled. Media proxying is enabled for the call legs in this scenario. The call stays up in this scenario, but there is no audio flowing after the transfer completed. In this scenario, FreeSWITCH does not shutdown cleanly, and there is a segmentation violation when FreeSWITCH is terminated. - freeswitch-rev15700-trace-112809-2210-proxyandbypasson.txt - A trace with both media proxying and media bypass enabled. Media bypass is enabled for the call legs in this scenario. The call actually gets dropped and there is no audio after the transfer is completed in this scenario. I have looked over the SIP traces of the failing scenarios. I have caught the following problems in the failing scenarios: - The o= line in SDP descriptors coming from the IP phone contains the private IP address, but the c= line in the SDP descriptors coming from the IP phone contains the public IP address. I have noticed a problem in re-INVITEs being sent from in proxy media and bypass media modes. The c= line in the re-invites contains the private IP address instead of the public IP address. The c= line was modified by a SIP ALG to contain a public IP address, but FreeSWITCH is actually not handling this correctly when calls are transferred. - The wrong codec is being negotiated in re-INVITE to the transferred number in the scenario when media proxying is enabled but media bypass is disabled. - In the scenario where media bypass is used, the re-INVITE actually appears to contain the correct details, and we are receiving the correct responses from our IP to IP gateway, but FreeSWITCH is not handling the media streams properly. Example of SDP descriptor coming from IP phone (with SDP descriptor modified by SIP ALG): v=0 o=- 123576 123576 IN IP4 192.168.1.4 s=- c=IN IP4 173.57.44.212 t=0 0 m=audio 16406 RTP/AVP 18 0 8 2 9 104 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/8000 a=rtpmap:104 L16/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv Notice that the c= line has the correct public IP address and the m= line containing the correct port. Example of incorrect SDP descriptor being sent by FreeSWITCH in re-INVITES: v=0 o=- 121397 121398 IN IP4 192.168.1.4 s=- c=IN IP4 192.168.1.4 t=0 0 m=audio 16404 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendonly a=ptime:20 Note that the c= line contains the wrong IP address, but the m= line contains the correct RTP port. Example of wrong re-INVITE message being sent to the number that the call was being transferred to: INVITE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKF1KrDreNFQgaj Max-Forwards: 69 From: "John Platts" <sip:19725357722@168.75.202.212>;tag=c61Drt38KF72m To: <sip:19729831777@ipipgw.ipdimensions.com>;tag=2B1339E0-1A2C Call-ID: 1c095553-5741-122d-33a8-00185167f91d CSeq: 123615824 INVITE Contact: <sip:mod_sofia@168.75.202.212:5062> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 183 X-FS-Support: update_display Remote-Party-ID: "John Platts" <sip:19725357722@168.75.202.212>;party=calling;screen=yes;privacy=off v=0 o=- 123576 123577 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 30186 RTP/AVP 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 Here is the correct re-INVITE for the call that was unsuccessfully transferred (after the transfer was completed): INVITE sip:19729555871@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKgaDHFKZrc06vD Max-Forwards: 16 From: <sip:19725357722@168.75.202.212>;tag=BX8mpZj5p6ggS To: <sip:19729555871@168.75.202.246>;tag=2B12D184-BEC Call-ID: 15A1F95-DBD611DE-8C95D9DF-3419A306@168.75.202.246 CSeq: 123615820 INVITE Contact: <sip:19725357722@168.75.202.212:5062;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 222 X-FS-Support: update_display v=0 o=- 121397 121399 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 26106 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 _________________________________________________________________ Windows 7: I wanted simpler, now it's simpler. I'm a rock star. http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID247...
To clarify the problem, the invite message is incorrect because comfort noise is being negotiated in the re-invite instead of G.711 or G.729: INVITE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKF1KrDreNFQgaj Max-Forwards: 69 From: "John Platts" <sip:19725357722@168.75.202.212>;tag=c61Drt38KF72m To: <sip:19729831777@ipipgw.ipdimensions.com>;tag=2B1339E0-1A2C Call-ID: 1c095553-5741-122d-33a8-00185167f91d CSeq: 123615824 INVITE Contact: <sip:mod_sofia@168.75.202.212:5062> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 183 X-FS-Support: update_display Remote-Party-ID: "John Platts" <sip:19725357722@168.75.202.212>;party=calling;screen=yes;privacy=off v=0 o=- 123576 123577 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 30186 RTP/AVP 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 How do I get it to negotiate G.711, G.729, or other codec instead of comfort noise? Our IP phones, our FXS gateways, and our IP to IP gateways expect G.711, G.729, iLBC (if supported by the endpoints), G.722 (if supported by the endpoints), or G.726 (if supported by the endpoints) be negotiated. ----------------------------------------
From: john_platts@hotmail.com To: freeswitch-users@lists.freeswitch.org Date: Sat, 28 Nov 2009 23:34:24 -0600 Subject: [Freeswitch-users] Call transfer fails in proxy media and bypass media modes in FreeSWITCH revision 15700
I have updated my FreeSWITCH installation to revision 15700. I am experiencing call transfer problems whenever proxy media or bypass media is enabled. When proxy media and bypass media are both disabled, the call transfer does not fail and there are no audio issues. When proxy media mode is enabled, the call stays up after the transfer occurs, but there is no audio flowing on either end of the call. When bypass media mode is enabled, there is no audio flowing on either end of the call, and the call actually gets disconnected.
I have collected detailed traces using the TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch command. I have attached a ZIP file named freeswitch-rev15700-traces-112809-2210.zip, which includes the following traces: - freeswitch-rev15700-trace-112809-2210-proxyandbypassoff.txt - A trace with both media proxying and media bypass disabled. The call is being transferred without any problems in this scenario. - freeswitch-rev15700-trace-112809-2210-proxyonandbypassoff.txt - A trace with media proxying enabled and media bypass disabled. Media proxying is enabled for the call legs in this scenario. The call stays up in this scenario, but there is no audio flowing after the transfer completed. In this scenario, FreeSWITCH does not shutdown cleanly, and there is a segmentation violation when FreeSWITCH is terminated. - freeswitch-rev15700-trace-112809-2210-proxyandbypasson.txt - A trace with both media proxying and media bypass enabled. Media bypass is enabled for the call legs in this scenario. The call actually gets dropped and there is no audio after the transfer is completed in this scenario.
I have looked over the SIP traces of the failing scenarios.
I have caught the following problems in the failing scenarios: - The o= line in SDP descriptors coming from the IP phone contains the private IP address, but the c= line in the SDP descriptors coming from the IP phone contains the public IP address. I have noticed a problem in re-INVITEs being sent from in proxy media and bypass media modes. The c= line in the re-invites contains the private IP address instead of the public IP address. The c= line was modified by a SIP ALG to contain a public IP address, but FreeSWITCH is actually not handling this correctly when calls are transferred. - The wrong codec is being negotiated in re-INVITE to the transferred number in the scenario when media proxying is enabled but media bypass is disabled. - In the scenario where media bypass is used, the re-INVITE actually appears to contain the correct details, and we are receiving the correct responses from our IP to IP gateway, but FreeSWITCH is not handling the media streams properly.
Example of SDP descriptor coming from IP phone (with SDP descriptor modified by SIP ALG): v=0 o=- 123576 123576 IN IP4 192.168.1.4 s=- c=IN IP4 173.57.44.212 t=0 0 m=audio 16406 RTP/AVP 18 0 8 2 9 104 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/8000 a=rtpmap:104 L16/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
Notice that the c= line has the correct public IP address and the m= line containing the correct port.
Example of incorrect SDP descriptor being sent by FreeSWITCH in re-INVITES: v=0 o=- 121397 121398 IN IP4 192.168.1.4 s=- c=IN IP4 192.168.1.4 t=0 0 m=audio 16404 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendonly a=ptime:20
Note that the c= line contains the wrong IP address, but the m= line contains the correct RTP port.
Example of wrong re-INVITE message being sent to the number that the call was being transferred to: INVITE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKF1KrDreNFQgaj Max-Forwards: 69 From: "John Platts" ;tag=c61Drt38KF72m To: ;tag=2B1339E0-1A2C Call-ID: 1c095553-5741-122d-33a8-00185167f91d CSeq: 123615824 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 183 X-FS-Support: update_display Remote-Party-ID: "John Platts" ;party=calling;screen=yes;privacy=off
v=0 o=- 123576 123577 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 30186 RTP/AVP 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000
Here is the correct re-INVITE for the call that was unsuccessfully transferred (after the transfer was completed): INVITE sip:19729555871@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKgaDHFKZrc06vD Max-Forwards: 16 From: ;tag=BX8mpZj5p6ggS To: ;tag=2B12D184-BEC Call-ID: 15A1F95-DBD611DE-8C95D9DF-3419A306@168.75.202.246 CSeq: 123615820 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 222 X-FS-Support: update_display
v=0 o=- 121397 121399 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 26106 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20
_________________________________________________________________ Windows 7: I wanted simpler, now it's simpler. I'm a rock star. http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID247...
_________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/
I don't quite understand what you are talking about? So you have bypass_media=true and you attempt to make an attended xfer as soon as you complete the transfer according to your trace FS does re-invites to convert the call to be exchanging media with FS. The o= lines you don't like are being set by the anonymous device in your callflow and should not impact anything at all. Are you saying something that used to work suddenly has caused you problems or is this the first time you are trying this because we have tested this scenario many times. Are you getting packet captures also and checking where the media is going after those re-invites? if you are intentionally using an ALG you might try without it because 100% of ALG we have ever seen have been badly broken when working with something like FS. On Sun, Nov 29, 2009 at 6:51 AM, John Platts <john_platts@hotmail.com>wrote:
To clarify the problem, the invite message is incorrect because comfort noise is being negotiated in the re-invite instead of G.711 or G.729: INVITE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKF1KrDreNFQgaj Max-Forwards: 69 From: "John Platts" <sip:19725357722@168.75.202.212<sip%3A19725357722@168.75.202.212>
;tag=c61Drt38KF72m To: <sip:19729831777@ipipgw.ipdimensions.com<sip%3A19729831777@ipipgw.ipdimensions.com> ;tag=2B1339E0-1A2C Call-ID: 1c095553-5741-122d-33a8-00185167f91d CSeq: 123615824 INVITE Contact: <sip:mod_sofia@168.75.202.212:5062> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 183 X-FS-Support: update_display Remote-Party-ID: "John Platts" <sip:19725357722@168.75.202.212<sip%3A19725357722@168.75.202.212> ;party=calling;screen=yes;privacy=off
v=0 o=- 123576 123577 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 30186 RTP/AVP 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000
How do I get it to negotiate G.711, G.729, or other codec instead of comfort noise? Our IP phones, our FXS gateways, and our IP to IP gateways expect G.711, G.729, iLBC (if supported by the endpoints), G.722 (if supported by the endpoints), or G.726 (if supported by the endpoints) be negotiated.
----------------------------------------
From: john_platts@hotmail.com To: freeswitch-users@lists.freeswitch.org Date: Sat, 28 Nov 2009 23:34:24 -0600 Subject: [Freeswitch-users] Call transfer fails in proxy media and bypass media modes in FreeSWITCH revision 15700
I have updated my FreeSWITCH installation to revision 15700. I am experiencing call transfer problems whenever proxy media or bypass media is enabled. When proxy media and bypass media are both disabled, the call transfer does not fail and there are no audio issues. When proxy media mode is enabled, the call stays up after the transfer occurs, but there is no audio flowing on either end of the call. When bypass media mode is enabled, there is no audio flowing on either end of the call, and the call actually gets disconnected.
I have collected detailed traces using the TPORT_LOG=1 /usr/local/freeswitch/bin/freeswitch command. I have attached a ZIP file named freeswitch-rev15700-traces-112809-2210.zip, which includes the following traces: - freeswitch-rev15700-trace-112809-2210-proxyandbypassoff.txt - A trace with both media proxying and media bypass disabled. The call is being transferred without any problems in this scenario. - freeswitch-rev15700-trace-112809-2210-proxyonandbypassoff.txt - A trace with media proxying enabled and media bypass disabled. Media proxying is enabled for the call legs in this scenario. The call stays up in this scenario, but there is no audio flowing after the transfer completed. In this scenario, FreeSWITCH does not shutdown cleanly, and there is a segmentation violation when FreeSWITCH is terminated. - freeswitch-rev15700-trace-112809-2210-proxyandbypasson.txt - A trace with both media proxying and media bypass enabled. Media bypass is enabled for the call legs in this scenario. The call actually gets dropped and there is no audio after the transfer is completed in this scenario.
I have looked over the SIP traces of the failing scenarios.
I have caught the following problems in the failing scenarios: - The o= line in SDP descriptors coming from the IP phone contains the private IP address, but the c= line in the SDP descriptors coming from the IP phone contains the public IP address. I have noticed a problem in re-INVITEs being sent from in proxy media and bypass media modes. The c= line in the re-invites contains the private IP address instead of the public IP address. The c= line was modified by a SIP ALG to contain a public IP address, but FreeSWITCH is actually not handling this correctly when calls are transferred. - The wrong codec is being negotiated in re-INVITE to the transferred number in the scenario when media proxying is enabled but media bypass is disabled. - In the scenario where media bypass is used, the re-INVITE actually appears to contain the correct details, and we are receiving the correct responses from our IP to IP gateway, but FreeSWITCH is not handling the media streams properly.
Example of SDP descriptor coming from IP phone (with SDP descriptor modified by SIP ALG): v=0 o=- 123576 123576 IN IP4 192.168.1.4 s=- c=IN IP4 173.57.44.212 t=0 0 m=audio 16406 RTP/AVP 18 0 8 2 9 104 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:9 G722/8000 a=rtpmap:104 L16/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
Notice that the c= line has the correct public IP address and the m= line containing the correct port.
Example of incorrect SDP descriptor being sent by FreeSWITCH in re-INVITES: v=0 o=- 121397 121398 IN IP4 192.168.1.4 s=- c=IN IP4 192.168.1.4 t=0 0 m=audio 16404 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendonly a=ptime:20
Note that the c= line contains the wrong IP address, but the m= line contains the correct RTP port.
Example of wrong re-INVITE message being sent to the number that the call was being transferred to: INVITE sip:19729831777@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKF1KrDreNFQgaj Max-Forwards: 69 From: "John Platts" ;tag=c61Drt38KF72m To: ;tag=2B1339E0-1A2C Call-ID: 1c095553-5741-122d-33a8-00185167f91d CSeq: 123615824 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 183 X-FS-Support: update_display Remote-Party-ID: "John Platts" ;party=calling;screen=yes;privacy=off
v=0 o=- 123576 123577 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 30186 RTP/AVP 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000
Here is the correct re-INVITE for the call that was unsuccessfully transferred (after the transfer was completed): INVITE sip:19729555871@168.75.202.246:5060 SIP/2.0 Via: SIP/2.0/UDP 168.75.202.212:5062;rport;branch=z9hG4bKgaDHFKZrc06vD Max-Forwards: 16 From: ;tag=BX8mpZj5p6ggS To: ;tag=2B12D184-BEC Call-ID: 15A1F95-DBD611DE-8C95D9DF-3419A306@168.75.202.246 CSeq: 123615820 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15700M Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 222 X-FS-Support: update_display
v=0 o=- 121397 121399 IN IP4 192.168.1.4 s=- c=IN IP4 168.75.202.212 t=0 0 m=audio 26106 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20
_________________________________________________________________ Windows 7: I wanted simpler, now it's simpler. I'm a rock star.
http://www.microsoft.com/Windows/windows-7/default.aspx?h=myidea?ocid=PID247...
_________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/ _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (2)
-
Anthony Minessale
-
John Platts