I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example: INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 .... v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
I think next reply will be whether you already opened Jira case or not yet :) 2012/2/14 Sergey Okhapkin <sos@sokhapkin.dyndns.org>
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
I can't open the case, because I don't know how to reproduce the problem and can't provide logs. On Tuesday 14 February 2012 08:07:38 Vitalie Colosov wrote:
I think next reply will be whether you already opened Jira case or not yet
:)
2012/2/14 Sergey Okhapkin <sos@sokhapkin.dyndns.org>
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
________________________________________________________________________ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
The word undefined does not even appear in that RFC. RFC 2327 (the one that actually describes SDP) is the relevant one: " A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: " The ptime attribute cannot be applied to a single codec mentioned in a m= line it must apply to all of them. Once you have 2 different ptimes in the same description you have no choice but to split it into different m= lines for each sep ptime. If you dislike this behavior then set: sdp_m_per_ptime=false either globally in vars.xml or in your dialplan on a per leg basis. On Tue, Feb 14, 2012 at 7:39 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
But RFC 3388 says (in 1. Introduction): An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams. On Tuesday 14 February 2012 11:40:40 Anthony Minessale wrote:
The word undefined does not even appear in that RFC.
RFC 2327 (the one that actually describes SDP) is the relevant one:
" A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: "
The ptime attribute cannot be applied to a single codec mentioned in a m= line it must apply to all of them. Once you have 2 different ptimes in the same description you have no choice but to split it into different m= lines for each sep ptime.
If you dislike this behavior then set:
sdp_m_per_ptime=false
either globally in vars.xml or in your dialplan on a per leg basis.
On Tue, Feb 14, 2012 at 7:39 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
________________________________________________________________________ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
On Tue, Feb 14, 2012 at 10:40 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
But RFC 3388 says (in 1. Introduction):
An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams.
If it's "up to the application what to do with them..." then the question is this: what do you want the application to do? Also, what is the "application" in this context? Anthony already showed that sending multiple m= lines is not only legal but is required if you need to have multiple ptimes. He even added a cheater param that lets you explicitly violate the RFC for the sake of interop with broken devices. It seems like FreeSWITCH not only "does the right thing" but it has a button you can press to "do the wrong thing for the sake of interop." I suppose I'm not seeing what the problem is. Could you elaborate? -MC
In your case FS to FS, your FS will parse both m= lines in order they are put in the sdp and choose the first stream it prefers based on your codec prefs. Its functionally identical to putting them all in one m= line only they are grouped by ptime. On Tue, Feb 14, 2012 at 12:40 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
But RFC 3388 says (in 1. Introduction):
An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams.
On Tuesday 14 February 2012 11:40:40 Anthony Minessale wrote:
The word undefined does not even appear in that RFC.
RFC 2327 (the one that actually describes SDP) is the relevant one:
" A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: "
The ptime attribute cannot be applied to a single codec mentioned in a m= line it must apply to all of them. Once you have 2 different ptimes in the same description you have no choice but to split it into different m= lines for each sep ptime.
If you dislike this behavior then set:
sdp_m_per_ptime=false
either globally in vars.xml or in your dialplan on a per leg basis.
On Tue, Feb 14, 2012 at 7:39 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
________________________________________________________________________ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Which ptime will be selected for codec 0? It is in both m=audio lines. m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 On Tuesday 14 February 2012 13:10:56 Anthony Minessale wrote:
In your case FS to FS, your FS will parse both m= lines in order they are put in the sdp and choose the first stream it prefers based on your codec prefs. Its functionally identical to putting them all in one m= line only they are grouped by ptime.
On Tue, Feb 14, 2012 at 12:40 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
But RFC 3388 says (in 1. Introduction):
An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams.
On Tuesday 14 February 2012 11:40:40 Anthony Minessale wrote:
The word undefined does not even appear in that RFC.
RFC 2327 (the one that actually describes SDP) is the relevant one:
" A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: "
The ptime attribute cannot be applied to a single codec mentioned in a m= line it must apply to all of them. Once you have 2 different ptimes in the same description you have no choice but to split it into different m= lines for each sep ptime.
If you dislike this behavior then set:
sdp_m_per_ptime=false
either globally in vars.xml or in your dialplan on a per leg basis.
On Tue, Feb 14, 2012 at 7:39 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
__________________________________________________________________ ______ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
________________________________________________________________________ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
On Tue, Feb 14, 2012 at 11:16 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Which ptime will be selected for codec 0? It is in both m=audio lines.
<snip> I believe Tony already answered your question:
On Tuesday 14 February 2012 13:10:56 Anthony Minessale wrote:
In your case FS to FS, your FS will parse both m= lines in order they are put in the sdp and choose the first stream it prefers based on your codec prefs.
So it depends on how you are doing your codec negotiation and how your codec prefs are set. -MC
if PCMU@30 is available it will be selected since its offered the highest in the list. On Tue, Feb 14, 2012 at 1:16 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
Which ptime will be selected for codec 0? It is in both m=audio lines.
m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
On Tuesday 14 February 2012 13:10:56 Anthony Minessale wrote:
In your case FS to FS, your FS will parse both m= lines in order they are put in the sdp and choose the first stream it prefers based on your codec prefs. Its functionally identical to putting them all in one m= line only they are grouped by ptime.
On Tue, Feb 14, 2012 at 12:40 PM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
But RFC 3388 says (in 1. Introduction):
An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams.
On Tuesday 14 February 2012 11:40:40 Anthony Minessale wrote:
The word undefined does not even appear in that RFC.
RFC 2327 (the one that actually describes SDP) is the relevant one:
" A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: "
The ptime attribute cannot be applied to a single codec mentioned in a m= line it must apply to all of them. Once you have 2 different ptimes in the same description you have no choice but to split it into different m= lines for each sep ptime.
If you dislike this behavior then set:
sdp_m_per_ptime=false
either globally in vars.xml or in your dialplan on a per leg basis.
On Tue, Feb 14, 2012 at 7:39 AM, Sergey Okhapkin
<sos@sokhapkin.dyndns.org> wrote:
I noticed that recent freeswitch versions could send SDP with 2 m=audio lines. Per RFC 3388, the behavior is undefined this case. I don't know how to reproduce the problem, I see such packets coming from my customers. Here is an example:
INVITE sip:xxxxxxxxxxxx@sip.callwithus.com SIP/2.0 ... User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-eeeaf41 2012-02-10 17-27-50 -0600 ....
v=0 o=FreeSWITCH 1329167961 1329167962 IN IP4 xx.xx.xx.xx s=FreeSWITCH c=IN IP4 xx.xx.xx.xx t=0 0 m=audio 24598 RTP/AVP 0 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:30 m=audio 24598 RTP/AVP 98 0 8 3 101 13 a=rtpmap:98 SILK/8000 a=fmtp:98 useinbandfec=1; usedtx=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Hmm, I just realized that this SDP is buggy - 2 audio streams on the same port, with common codecs, but with different ptime :-)
__________________________________________________________________ ______ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
________________________________________________________________________ _ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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 GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (4)
-
Anthony Minessale
-
Michael Collins
-
Sergey Okhapkin
-
Vitalie Colosov