[Freeswitch-users] RTP problems in recent revisions?
Revision 15904 is fine, but after upgrading to revision 16003 I get the following. 1. No problems with a FreeSWITCH to FreeSWITCH call (Celt codec). 2. A PCMU call to a SIP provider is fine for the first 20 to 30 seconds, then the audio breaks up completely. I have ZRTP compiled in, if that makes any difference. Obviously there's a regression somewhere. Let me know if I can provide further help. ___ 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
Re: [Freeswitch-users] RTP problems in recent revisions?
The best help to track this down is to try to identify the specific svn revision that caused the issue and to supply a full freeswitch debug with sip trace. Mike On Dec 19, 2009, at 3:31 AM, Jason White ja...@jasonjgw.net wrote: Revision 15904 is fine, but after upgrading to revision 16003 I get the following. 1. No problems with a FreeSWITCH to FreeSWITCH call (Celt codec). 2. A PCMU call to a SIP provider is fine for the first 20 to 30 seconds, then the audio breaks up completely. I have ZRTP compiled in, if that makes any difference. Obviously there's a regression somewhere. Let me know if I can provide further help. ___ 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 ___ 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
Re: [Freeswitch-users] RTP problems in recent revisions?
Also retest with no zrtp send a full console debug log with sip trace On Dec 19, 2009 8:33 AM, Michael Jerris m...@jerris.com wrote: The best help to track this down is to try to identify the specific svn revision that caused the issue and to supply a full freeswitch debug with sip trace. Mike On Dec 19, 2009, at 3:31 AM, Jason White ja...@jasonjgw.net wrote: Revision 15904 is fine, but... ___ 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
Re: [Freeswitch-users] Park with Pre Answer
how are you parking it? do you have a debug log showing it happen? On Fri, Dec 18, 2009 at 11:42 PM, Ron McLeod ron.freeswi...@mcleodnet.comwrote: Is there any way to park a channel without causing pre-answer (resulting is a SIP 183 Session Progress)? Thanks, Ron ___ 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_miness...@hotmail.com msn%3aanthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.compaypal%3aanthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org sip%3a...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.orggoogletalk%3aconf%2b...@conference.freeswitch.org pstn:+19193869900 ___ 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
Re: [Freeswitch-users] ACLs through proxy
Bill,
I think you would add this to the user profile in the directory. The
brian.xml example (located in ${confdir}/directory/) provided with the
default/sample configuration files demonstrates how to to do this by
introducing a cidr attribute to the the user element.
Example:
user id=7105551212 cidr=127.0.0.0/8//
params
param name=password value=opensaysme/
param name=vm-password value=14916/
/params
variables
variable name=user_context value=default/
/variables
/user
http://wiki.freeswitch.org/wiki/Acl; contains some great info
(including a relevant example).
-metik
Bill W. wrote:
Hey Metik,
Thanks so much for your insights and your help. And yes, I was able to
append the X-AUTH-IP header with no problem. But that didn't solve the
issue. After some more research, it appears that the problem isn't with
auth-calls at all.
I disabled all auth-call directives in every sip profile and the
registration through a proxy is still being rejected.
I looked in sofia_reg.c and if auth_acl is defined, sofia_reg checks the
ip variable against the auth_acl cidr.
if (auth_acl) {
if (!switch_check_network_list_ip(ip, auth_acl)) {
switch_log_printf(SWITCH_CHANNEL_LOG,
SWITCH_LOG_WARNING, IP %s Rejected by user acl %s\n, ip, auth_acl);
ret = AUTH_FORBIDDEN;
goto end;
}
So I guess the question is, is it possible to control what gets put into
the ip variable?
Thanks,
Bill
Metik wrote:
Honestly, several years ago I accomplished this by mod'ing SER (which
became OpenSER which was then forked to OpenSIPS and Kamalio) and using
one cluster of proxies for subscriber endpoints and another for
infrastructure (so that I could keep RTP flows optimized yet support
double NAT when required by an endpoint). Although the network looks
different today.
However, we were never quite happy about the lack of media failover
(complicated NAT) and evaluated several commercial solutions until
finding Covergence (which is now, for better or for worse since the jury
is still out, owned by ACME Packet). At the time, they offered the best
mix of security (their forte) yet scaled very well in comparison to
their competitors that I had tested in our lab (ACME Packet, Kagoor,
Netrake, NexTone, Kagoor, and Jasomi). In fact, they made a great
decision, not unlike that of the FS developers, to implement a
proven/stable SIP protocol stack. Nothing is perfect and that does not
mean that we did not spend a considerable amount of time documenting
bugs so that they could be addressed and it would work as it should
We still use OpenSIPS for certain CSCF functionality (due to its speed
and flexibility since it is not a B2BUA).
Based on Mathieu's response (and he is definitely someone that would
know), it looks like you should be able to easily append a X-AUTH-IP
header (via OpenSIPS) containing the IP address of the endpoint and call
it a day.
-metik
Bill W wrote:
Hey Metik,
That's exactly what I'm trying to do... load balance across multiple FS
boxes, and have any machine in the cluster be able to reach a device
behind a NAT firewall. Hence the need for the proxy. Also, I'm trying
to keep the proxy relatively dumb and put all the logic in the FS boxes.
True I could do the auth on the proxies as well, but then I'm setting up
another authentication scheme in addition to what is on the FS boxes,
and then integrating the databases so everything is consistent.
I also have hosts that talk to the FS boxes directly, rather than
through the proxy. So I can't get rid of auth_acl on FS either, even if
I do implement it on the proxies. So my setup becomes much more
complex and potentially brittle.
And all we're really talking about for FreeSWITCH, conceptually
speaking, is populating a variable with a different IP. We could even
make it configurable, as to which IP is to be used for the auth-acl.
What are you using for SBCs? (if you are allowed to divulge that) I'm
currently using OpenSIPS for my proxy.
Thanks,
Bill
Metik wrote:
Why not simply implement this feature in the PROXY itself?
FS has a pretty comprehensive security feature set for endpoints that
directly register with it.
Don't get me wrong, I do agree this is useful especially if you are
going to be using your proxies to load balance across multiple FS boxes
to create an ad-hoc cluster. I actually have session border controllers
that have this feature and use it quite often.
-metik
Bill W wrote:
Hey Metik,
Thanks for the reply, and the pointers for doing it with xml_curl.
I'll guess have to do that in the short term, but in my opinion, having
auth-acl be able to work through a proxy is very important as it is a
vital part of a comprehensive security feature set. And it would be
Re: [Freeswitch-users] Allow/Deny REGISTER Request Based on User-Agent Header
we do this based XML-Curl. Jerry Richards schrieb: Is it possible to allow/deny REGISTER requests based on the User-Agent header? I need to know/manage what devices are registering. Best Regards, Jerry ___ 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 ___ 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
Re: [Freeswitch-users] ACLs through proxy
I noticed a typo in my post that may easily confuse someone...
user id=7105551212 cidr=127.0.0.0/8//
should be:
user id=7105551212 cidr=127.0.0.0/8
-metik
Metik wrote:
Bill,
I think you would add this to the user profile in the directory. The
brian.xml example (located in ${confdir}/directory/) provided with the
default/sample configuration files demonstrates how to to do this by
introducing a cidr attribute to the the user element.
Example:
user id=7105551212 cidr=127.0.0.0/8//
params
param name=password value=opensaysme/
param name=vm-password value=14916/
/params
variables
variable name=user_context value=default/
/variables
/user
http://wiki.freeswitch.org/wiki/Acl; contains some great info
(including a relevant example).
-metik
Bill W. wrote:
Hey Metik,
Thanks so much for your insights and your help. And yes, I was able to
append the X-AUTH-IP header with no problem. But that didn't solve the
issue. After some more research, it appears that the problem isn't with
auth-calls at all.
I disabled all auth-call directives in every sip profile and the
registration through a proxy is still being rejected.
I looked in sofia_reg.c and if auth_acl is defined, sofia_reg checks the
ip variable against the auth_acl cidr.
if (auth_acl) {
if (!switch_check_network_list_ip(ip, auth_acl)) {
switch_log_printf(SWITCH_CHANNEL_LOG,
SWITCH_LOG_WARNING, IP %s Rejected by user acl %s\n, ip, auth_acl);
ret = AUTH_FORBIDDEN;
goto end;
}
So I guess the question is, is it possible to control what gets put into
the ip variable?
Thanks,
Bill
Metik wrote:
Honestly, several years ago I accomplished this by mod'ing SER (which
became OpenSER which was then forked to OpenSIPS and Kamalio) and using
one cluster of proxies for subscriber endpoints and another for
infrastructure (so that I could keep RTP flows optimized yet support
double NAT when required by an endpoint). Although the network looks
different today.
However, we were never quite happy about the lack of media failover
(complicated NAT) and evaluated several commercial solutions until
finding Covergence (which is now, for better or for worse since the jury
is still out, owned by ACME Packet). At the time, they offered the best
mix of security (their forte) yet scaled very well in comparison to
their competitors that I had tested in our lab (ACME Packet, Kagoor,
Netrake, NexTone, Kagoor, and Jasomi). In fact, they made a great
decision, not unlike that of the FS developers, to implement a
proven/stable SIP protocol stack. Nothing is perfect and that does not
mean that we did not spend a considerable amount of time documenting
bugs so that they could be addressed and it would work as it should
We still use OpenSIPS for certain CSCF functionality (due to its speed
and flexibility since it is not a B2BUA).
Based on Mathieu's response (and he is definitely someone that would
know), it looks like you should be able to easily append a X-AUTH-IP
header (via OpenSIPS) containing the IP address of the endpoint and call
it a day.
-metik
Bill W wrote:
Hey Metik,
That's exactly what I'm trying to do... load balance across multiple FS
boxes, and have any machine in the cluster be able to reach a device
behind a NAT firewall. Hence the need for the proxy. Also, I'm trying
to keep the proxy relatively dumb and put all the logic in the FS boxes.
True I could do the auth on the proxies as well, but then I'm setting up
another authentication scheme in addition to what is on the FS boxes,
and then integrating the databases so everything is consistent.
I also have hosts that talk to the FS boxes directly, rather than
through the proxy. So I can't get rid of auth_acl on FS either, even if
I do implement it on the proxies. So my setup becomes much more
complex and potentially brittle.
And all we're really talking about for FreeSWITCH, conceptually
speaking, is populating a variable with a different IP. We could even
make it configurable, as to which IP is to be used for the auth-acl.
What are you using for SBCs? (if you are allowed to divulge that) I'm
currently using OpenSIPS for my proxy.
Thanks,
Bill
Metik wrote:
Why not simply implement this feature in the PROXY itself?
FS has a pretty comprehensive security feature set for endpoints that
directly register with it.
Don't get me wrong, I do agree this is useful especially if you are
going to be using your proxies to load balance across multiple FS boxes
to create an ad-hoc cluster. I actually have session border controllers
that have this feature and use it quite often.
-metik
Bill W wrote:
Hey Metik,
Thanks for the reply, and the pointers for doing it with
Re: [Freeswitch-users] RTP problems in recent revisions?
I tried a patch out of pure deduction and speculation from your post. Can you update and test it for me please? On Sat, Dec 19, 2009 at 9:19 AM, Anthony Minessale anthony.miness...@gmail.com wrote: Also retest with no zrtp send a full console debug log with sip trace On Dec 19, 2009 8:33 AM, Michael Jerris m...@jerris.com wrote: The best help to track this down is to try to identify the specific svn revision that caused the issue and to supply a full freeswitch debug with sip trace. Mike On Dec 19, 2009, at 3:31 AM, Jason White ja...@jasonjgw.net wrote: Revision 15904 is fine, but... -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_miness...@hotmail.com msn%3aanthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.compaypal%3aanthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org sip%3a...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.orggoogletalk%3aconf%2b...@conference.freeswitch.org pstn:+19193869900 ___ 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
Re: [Freeswitch-users] Park with Pre Answer
This is what I am doing . DIALPLAN ?xml version=1.0 encoding=utf-8? include context name=mytest extension name=mytest condition field=destination_number expression=^.*$ action application=park/ /condition /extension /context /include NETWORK TRACE 0.00 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.000749 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.053820 192.168.100.132 - 192.168.100.140 SIP Status: 407 Proxy Authentication Required 0.185859 192.168.100.140 - 192.168.100.132 SIP Request: ACK sip:6042772...@192.168.100.132:5090 0.247509 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.248226 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.259591 192.168.100.132 - 192.168.100.140 SIP/SDP Status: 183 Session Progress, with session description CONSOLE 2009-12-19 10:47:59.556850 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [NOTICE] switch_channel.c:602 New Channel sofia/internal/6...@192.168.100.132:5060 [07a14700-eccf-11de-8080-6fed700309ce] 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3289 Channel sofia/internal/6...@192.168.100.132:5060 entering state [received][100] 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3296 Remote SDP: v=0 o=695 123456 654323 IN IP4 192.168.100.140 s=none c=IN IP4 192.168.100.140 t=0 0 m=audio 10900 RTP/AVP 0 8 18 2 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729A/8000 a=fmtp:18 annexb=no a=rtpmap:2 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:404 (sofia/internal/6...@192.168.100.132:5060) State NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:115:32000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:107:16000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G722:9:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[PCMU:0:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:2029 Set Codec sofia/internal/6...@192.168.100.132:5060 PCMU/8000 20 ms 160 samples 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3031 Set 2833 dtmf payload to 101 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3455 (sofia/internal/6...@192.168.100.132:5060) State Change CS_NEW - CS_INIT 2009-12-19 10:47:59.804984 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_INIT 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:83 sofia/internal/6...@192.168.100.132:5060 SOFIA INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:111 (sofia/internal/6...@192.168.100.132:5060) State Change CS_INIT - CS_ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT going to sleep 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:484 (sofia/internal/6...@192.168.100.132:5060) State ROUTING 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:130 sofia/internal/6...@192.168.100.132:5060 SOFIA ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:78 sofia/internal/6...@192.168.100.132:5060 Standard ROUTING 2009-12-19 10:47:59.812026 [INFO] mod_dialplan_xml.c:315 Processing Phone 300-6042772011 in context mytest Dialplan: sofia/internal/6...@192.168.100.132:5060 parsing [mytest-mytest] continue=false Dialplan: sofia/internal/6...@192.168.100.132:5060 Regex (PASS) [mytest] destination_number(6042772011) =~ /^.*$/ break=on-false Dialplan: sofia/internal/6...@192.168.100.132:5060 Action park() 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:114 (sofia/internal/6...@192.168.100.132:5060) State Change CS_ROUTING - CS_EXECUTE 2009-12-19 10:47:59.812026 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK]
Re: [Freeswitch-users] Park with Pre Answer
Good afternoon By default the internal profile is looking to have authed calls. If you want you can set an acl. Look at autoload_configs/acl.conf.xml. Also remember to set the context in the profile so that the dialplan for that context will be parsed. If you decide to register to it you can set the context in the directory entry for that user. Let us know how you do. --FC On Sat, Dec 19, Ron McLeod wrote: This is what I am doing . DIALPLAN ?xml version=1.0 encoding=utf-8? include context name=mytest extension name=mytest condition field=destination_number expression=^.*$ action application=park/ /condition /extension /context /include NETWORK TRACE 0.00 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.000749 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.053820 192.168.100.132 - 192.168.100.140 SIP Status: 407 Proxy Authentication Required 0.185859 192.168.100.140 - 192.168.100.132 SIP Request: ACK sip:6042772...@192.168.100.132:5090 0.247509 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.248226 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.259591 192.168.100.132 - 192.168.100.140 SIP/SDP Status: 183 Session Progress, with session description CONSOLE 2009-12-19 10:47:59.556850 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [NOTICE] switch_channel.c:602 New Channel sofia/internal/6...@192.168.100.132:5060 [07a14700-eccf-11de-8080-6fed700309ce] 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3289 Channel sofia/internal/6...@192.168.100.132:5060 entering state [received][100] 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3296 Remote SDP: v=0 o=695 123456 654323 IN IP4 192.168.100.140 s=none c=IN IP4 192.168.100.140 t=0 0 m=audio 10900 RTP/AVP 0 8 18 2 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729A/8000 a=fmtp:18 annexb=no a=rtpmap:2 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:404 (sofia/internal/6...@192.168.100.132:5060) State NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:115:32000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:107:16000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G722:9:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[PCMU:0:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:2029 Set Codec sofia/internal/6...@192.168.100.132:5060 PCMU/8000 20 ms 160 samples 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3031 Set 2833 dtmf payload to 101 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3455 (sofia/internal/6...@192.168.100.132:5060) State Change CS_NEW - CS_INIT 2009-12-19 10:47:59.804984 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_INIT 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:83 sofia/internal/6...@192.168.100.132:5060 SOFIA INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:111 (sofia/internal/6...@192.168.100.132:5060) State Change CS_INIT - CS_ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT going to sleep 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:484 (sofia/internal/6...@192.168.100.132:5060) State ROUTING 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:130 sofia/internal/6...@192.168.100.132:5060 SOFIA ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:78 sofia/internal/6...@192.168.100.132:5060 Standard ROUTING 2009-12-19 10:47:59.812026 [INFO] mod_dialplan_xml.c:315 Processing Phone
Re: [Freeswitch-users] Park with Pre Answer
My issue has nothing to do with registration or authentication. I am simply looking for a way to park a new call without having the call pre-answered (I don't want a SIP 183 sent back to the client). Ron -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch- users-boun...@lists.freeswitch.org] On Behalf Of Frank Carmickle Sent: Saturday, December 19, 2009 12:20 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Park with Pre Answer Good afternoon By default the internal profile is looking to have authed calls. If you want you can set an acl. Look at autoload_configs/acl.conf.xml. Also remember to set the context in the profile so that the dialplan for that context will be parsed. If you decide to register to it you can set the context in the directory entry for that user. Let us know how you do. --FC On Sat, Dec 19, Ron McLeod wrote: This is what I am doing . DIALPLAN ?xml version=1.0 encoding=utf-8? include context name=mytest extension name=mytest condition field=destination_number expression=^.*$ action application=park/ /condition /extension /context /include NETWORK TRACE 0.00 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.000749 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.053820 192.168.100.132 - 192.168.100.140 SIP Status: 407 Proxy Authentication Required 0.185859 192.168.100.140 - 192.168.100.132 SIP Request: ACK sip:6042772...@192.168.100.132:5090 0.247509 192.168.100.140 - 192.168.100.132 SIP/SDP Request: INVITE sip:6042772...@192.168.100.132:5090, with session description 0.248226 192.168.100.132 - 192.168.100.140 SIP Status: 100 Trying 0.259591 192.168.100.132 - 192.168.100.140 SIP/SDP Status: 183 Session Progress, with session description CONSOLE 2009-12-19 10:47:59.556850 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:4628 IP 192.168.100.140 Rejected by acl domains. Falling back to Digest auth. 2009-12-19 10:47:59.804984 [NOTICE] switch_channel.c:602 New Channel sofia/internal/6...@192.168.100.132:5060 [07a14700-eccf-11de-8080-6fed700309ce] 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3289 Channel sofia/internal/6...@192.168.100.132:5060 entering state [received][100] 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3296 Remote SDP: v=0 o=695 123456 654323 IN IP4 192.168.100.140 s=none c=IN IP4 192.168.100.140 t=0 0 m=audio 10900 RTP/AVP 0 8 18 2 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729A/8000 a=fmtp:18 annexb=no a=rtpmap:2 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2009-12-19 10:47:59.804984 [DEBUG] switch_core_state_machine.c:404 (sofia/internal/6...@192.168.100.132:5060) State NEW 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:115:32000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G7221:107:16000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[G722:9:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3071 Audio Codec Compare [PCMU:0:8000:20]/[PCMU:0:8000:20] 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:2029 Set Codec sofia/internal/6...@192.168.100.132:5060 PCMU/8000 20 ms 160 samples 2009-12-19 10:47:59.804984 [DEBUG] sofia_glue.c:3031 Set 2833 dtmf payload to 101 2009-12-19 10:47:59.804984 [DEBUG] sofia.c:3455 (sofia/internal/6...@192.168.100.132:5060) State Change CS_NEW - CS_INIT 2009-12-19 10:47:59.804984 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:398 (sofia/internal/6...@192.168.100.132:5060) Running State Change CS_INIT 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:83 sofia/internal/6...@192.168.100.132:5060 SOFIA INIT 2009-12-19 10:47:59.812026 [DEBUG] mod_sofia.c:111 (sofia/internal/6...@192.168.100.132:5060) State Change CS_INIT - CS_ROUTING 2009-12-19 10:47:59.812026 [DEBUG] switch_core_session.c:932 Send signal sofia/internal/6...@192.168.100.132:5060 [BREAK] 2009-12-19 10:47:59.812026 [DEBUG] switch_core_state_machine.c:481 (sofia/internal/6...@192.168.100.132:5060) State INIT going to
[Freeswitch-users] Third Party device connectivity from Freeswitch
Hi, Is there a way to have the Freeswitch to route the calls to physical device/phone rather than just routing the calls to soft phones like Xlite?. If available, What sort of settings that are required in Freeswitch to communicate with third party applications/hardwares (like PBX) so that the calls be switched to physical devices from Freeswitch? Can anyone help me in this regard?. Thanks, Scott. ___ 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
Re: [Freeswitch-users] Third Party device connectivity from Freeswitch
On Sun, Dec 20, Scott Fernandez wrote: Hi, Is there a way to have the Freeswitch to route the calls to physical device/phone rather than just routing the calls to soft phones like Xlite?. Very much so. It all depends on what you want to do. If available, What sort of settings that are required in Freeswitch to communicate with third party applications/hardwares (like PBX) so that the calls be switched to physical devices from Freeswitch? Have a read through http://wiki.freeswitch.org/wiki/Interop_List HTH --FC ___ 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
Re: [Freeswitch-users] ACLs through proxy
Hey Metik,
Yes. Well, actually, I can have the cidr in two places in the directory.
user cidr=190.218.97.83/32 id=testphone01
params
param name=auth-acl value=190.218.97.83/32/param
From what I understand the cidr= parmeter is used in conjunction with
the apply-inbound-acl parameter in the sofia profile to just allow
someone to make calls from a certain IP without authenticating.
And from what I understand the auth-acl= parameter is used to restrict a
user to a particular cidr, but the user has to authenticate as well.
*The second feature is the one I want to use.* I want to force users to
authenticate, but only allow that authentication from a particular cidr
as an added measure against toll fraud.
And this appears to be causing the issue. Because once I specify the
auth-acl parameter in the directory, sofia-reg enforces that acl. And
unfortunately it's using the IP of the proxy, not of the user-agent.
I looked in sofia.c and found this comment:
/*
* if network_ip is a proxy allowed to send calls, check for auth
* ip header and see if it matches against the inbound acl
*/
And this coincides with my testing.
I have param name=apply-proxy-acl value=ip_of_proxy/ in my
profile. I have my proxy sending the X-AUTH-IP header (verified with
tcpdump). And yet the REGISTER is still being denied.
So it appears that the apply-proxy-acl is set up to work with the
apply-inbound-acl ( to allow users from an IP without authenticating)
But that hasn't been carried over to sofia_reg.c, which appears to
simply check the IP of who FreeSWITCH is talking to against the auth-acl
cidr specified in the directory. (Line 1926)
So I guess the question is, is my analysis correct?
Thoughts anyone?
Thanks,
Bill
Metik wrote:
Bill,
I think you would add this to the user profile in the directory. The
brian.xml example (located in ${confdir}/directory/) provided with the
default/sample configuration files demonstrates how to to do this by
introducing a cidr attribute to the the user element.
Example:
user id=7105551212 cidr=127.0.0.0/8//
params
param name=password value=opensaysme/
param name=vm-password value=14916/
/params
variables
variable name=user_context value=default/
/variables
/user
http://wiki.freeswitch.org/wiki/Acl; contains some great info
(including a relevant example).
-metik
___
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
[Freeswitch-users] Difference between ESL execute() and executeAsync()
I don't notice any different in behavior between execute() and
executeAsync(). I was expecting that executeAsync() would return
right-away, and that execute() would only return after the specified
application runs to completion (CHANNEL_EXECUTE_COMPLETE event).
Running the sample app below, I see the About to call execute(playback)
and returned displayed one right-after the other, even though the file
being played takes about 4 minutes to play-out.
Do I have this wrong, or is there something incorrect in my app?
APP:
#!/usr/bin/php
?php
require_once ESL.php;
$eventSocket = New ESLconnection('192.168.100.132', '8021', 'ClueCon');
$eventSocket-events('plain', 'CHANNEL_STATE');
$eventSocket-filter('channel-state', 'CS_ROUTING');
// Wait for new call attempts
while($eventSocket-connected()){
$event = $eventSocket-recvEvent();
$serializedBody = $event-serialize();
$listOfLines = toArrayOfLines($serializedBody);
$nameValuePairs = toArrayOfNameValuePairs($listOfLines);
$uuid = $nameValuePairs['Caller-Unique-ID'];
printf(New call from uuid: $uuid\n);
// answer the caller and play announcement
$eventSocket-execute('answer', Null ,$uuid);
printf(About to call execute(playback)\n);
$eventSocket-execute('playback', '/tmp/ann.wav', $uuid);
printf(returned\n);
}
?
DIALPLAN:
?xml version=1.0 encoding=utf-8?
include
context name=mytest
extension name=mytest
condition field=destination_number expression=^.*$
action application=park/
/condition
/extension
/context
/include
___
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
Re: [Freeswitch-users] Difference between ESL execute() andexecuteAsync()
Here's the ES network trace:
Content-Length: 1502
Content-Type: text/event-plain
Event-Name: CHANNEL_STATE
Core-UUID: bb9ea62a-ed02-11de-91b1-8b7cb185f66f
FreeSWITCH-Hostname: ron-laptop
FreeSWITCH-IPv4: 192.168.100.132
FreeSWITCH-IPv6: %3A%3A1
Event-Date-Local: 2009-12-19%2019%3A12%3A09
Event-Date-GMT: Sun,%2020%20Dec%202009%2003%3A12%3A09%20GMT
Event-Date-Timestamp: 1261278729767397
Event-Calling-File: switch_channel.c
Event-Calling-Function: switch_channel_perform_set_running_state
Event-Calling-Line-Number: 1024
Channel-State: CS_ROUTING
Channel-State-Number: 2
Channel-Name: sofia/internal/699%40192.168.100.132
Unique-ID: 76021ab2-ed15-11de-91b1-8b7cb185f66f
Call-Direction: inbound
Presence-Call-Direction: inbound
Answer-State: ringing
Channel-Read-Codec-Name: PCMU
Channel-Read-Codec-Rate: 8000
Channel-Write-Codec-Name: PCMU
Channel-Write-Codec-Rate: 8000
Caller-Username: 699
Caller-Dialplan: XML
Caller-Caller-ID-Name: Ron%20Soft%20Phone
Caller-Caller-ID-Number: 699
Caller-Network-Addr: 192.168.100.3
Caller-Destination-Number: 444
Caller-Unique-ID: 76021ab2-ed15-11de-91b1-8b7cb185f66f
Caller-Source: mod_sofia
Caller-Context: mytest
Caller-Channel-Name: sofia/internal/699%40192.168.100.132
Caller-Profile-Index: 1
Caller-Profile-Created-Time: 1261278729764077
Caller-Channel-Created-Time: 1261278729764077
Caller-Channel-Answered-Time: 0
Caller-Channel-Progress-Time: 0
Caller-Channel-Progress-Media-Time: 0
Caller-Channel-Hangup-Time: 0
Caller-Channel-Transfer-Time: 0
Caller-Screen-Bit: true
Caller-Privacy-Hide-Name: false
Caller-Privacy-Hide-Number: false
sendmsg 76021ab2-ed15-11de-91b1-8b7cb185f66f
call-command: execute
execute-app-name: answer
execute-app-arg:
Content-Type: command/reply
Reply-Text: +OK
sendmsg 76021ab2-ed15-11de-91b1-8b7cb185f66f
call-command: execute
execute-app-name: playback
execute-app-arg: /tmp/ann.wav
Content-Type: command/reply
Reply-Text: +OK
-Original Message-
From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-
users-boun...@lists.freeswitch.org] On Behalf Of Ron McLeod
Sent: Saturday, December 19, 2009 5:30 PM
To: freeswitch-users@lists.freeswitch.org
Subject: [Freeswitch-users] Difference between ESL execute()
andexecuteAsync()
I don't notice any different in behavior between execute() and
executeAsync(). I was expecting that executeAsync() would return
right-away, and that execute() would only return after the specified
application runs to completion (CHANNEL_EXECUTE_COMPLETE event).
Running the sample app below, I see the About to call execute(playback)
and returned displayed one right-after the other, even though the file
being played takes about 4 minutes to play-out.
Do I have this wrong, or is there something incorrect in my app?
APP:
#!/usr/bin/php
?php
require_once ESL.php;
$eventSocket = New ESLconnection('192.168.100.132', '8021', 'ClueCon');
$eventSocket-events('plain', 'CHANNEL_STATE');
$eventSocket-filter('channel-state', 'CS_ROUTING');
// Wait for new call attempts
while($eventSocket-connected()){
$event = $eventSocket-recvEvent();
$serializedBody = $event-serialize();
$listOfLines = toArrayOfLines($serializedBody);
$nameValuePairs = toArrayOfNameValuePairs($listOfLines);
$uuid = $nameValuePairs['Caller-Unique-ID'];
printf(New call from uuid: $uuid\n);
// answer the caller and play announcement
$eventSocket-execute('answer', Null ,$uuid);
printf(About to call execute(playback)\n);
$eventSocket-execute('playback', '/tmp/ann.wav', $uuid);
printf(returned\n);
}
?
DIALPLAN:
?xml version=1.0 encoding=utf-8?
include
context name=mytest
extension name=mytest
condition field=destination_number expression=^.*$
action application=park/
/condition
/extension
/context
/include
___
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
--
This email was Anti Virus checked by Astaro Security Gateway.
http://www.astaro.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
[Freeswitch-users] [OT] Re: Scanning my firewall for open UDP ports?
On Thu, Dec 17, 2009 at 6:14 AM, Hristo Benev f...@abv.bg wrote: Just for your information there is a version of nmap for windows. So you can do the test from your desktop. Funny that you assume his desktop is running Windows (maybe it is). I would have guessed that the average person on this list doesn't run Windows on the desktop. But, what do I know? Gabe ___ 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
Re: [Freeswitch-users] [OT] Re: Scanning my firewall for open UDP ports?
Gabriel Gunderson g...@gundy.org wrote: Funny that you assume his desktop is running Windows (maybe it is). I would have guessed that the average person on this list doesn't run Windows on the desktop. But, what do I know? Some of us on the list have never run Windows on anything. It's Debian on my desktop, by the way, with FreeSWITCH acting as a soft-phone via a USB head set, and also handling my Snom 320 SIP phone. ___ 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
