My provider is a Broadsoft vendor. Version unknown.
I have a polycom ip500 which was working just fine when I was running 0.6.1 on Netbsd 3. (Old and unsuportable, I know!)
Moved to OpenSolaris and 0.8.1. After a number of compile and other hics, things *seem* to work, but calls drop after half a minute.
I had to change from the old config to the new due to call logging moving to plugins. But I believe the net of the changes is to just comment out log_calls = 1
Again, I've filed bugs against a few things, and I have fixes for them in my code. But I can't find anything in the forums, on the web, or in the code to readily explain why my calls are being dropped. I have other problems, but I'm betting they're all related.
NB OpenSolaris lets me rename ethernets. (I've done this without them being renamed, and siproxd also doesn't work. The renaming is more fundamental than Linux' naming all ethernets to ethN.) So, I have macplaza0 as an interface name to help me remember which ethernet is inside and which is not.
I have the debug captures, and will send them to anyone who wants. They're just way to big to attach.
I have IPFilter set to properly redirect SIP so that I'm a transparent proxy, and to allow the RTP proxy.
Both OpenSolaris and NetBSD use ipfilter, so except for the interface names, the ipf.conf and ipnat.conf
were identical, as are the ifconfigs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Crud, I hate blog posting. ASCII text just gets all glommed up.
Here is that post without pretty print formatting:
Greetings,MyproviderisaBroadsoftvendor.Versionunknown.Ihaveapolycomip500whichwasworkingjustfinewhenIwasrunning0.6.1onNetbsd3.(Oldandunsuportable,Iknow!)MovedtoOpenSolarisand0.8.1.Afteranumberofcompileandotherhics,things*seem*towork,butcallsdropafterhalfaminute.Ihadtochangefromtheoldconfigtothenewduetocallloggingmovingtoplugins.ButIbelievethenetofthechangesistojustcommentoutlog_calls=1Again,I've filed bugs against a few things, and I have fixes for them in my code. But I can'tfindanythingintheforums,ontheweb,orinthecodetoreadilyexplainwhymycallsarebeingdropped.Ihaveotherproblems,butI'm betting they'reallrelated.NBOpenSolarisletsmerenameethernets.(I've done this without them being renamed, and siproxd also doesn'twork.TherenamingismorefundamentalthanLinux' naming all ethernets to ethN.) So, I have macplaza0 as an interface name to help me remember which ethernet is inside and which is not.if_inbound=macplaza0if_outbound=rge0hosts_allow_reg=198.98.1.0/24sip_listen_port=5060daemonize=1silence_log=1user=siproxdregistration_file=/var/db/siproxd_registrationsautosave_registrations=30pid_file=/var/run/siproxd.pidrtp_proxy_enable=1rtp_port_low=7000rtp_port_high=7999rtp_timeout=300rtp_dscp=46default_expires=600debug_level=0x00000feedebug_port=9050Ihavethedebugcaptures,andwillsendthemtoanyonewhowants.They're just way to big to attach.IhaveIPFiltersettoproperlyredirectSIPsothatI'm a transparent proxy, and to allow the RTP proxy.BothOpenSolarisandNetBSDuseipfilter,soexceptfortheinterfacenames,theipf.confandipnat.confwereidentical,asaretheifconfigs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
My provider is a Broadsoft vendor. Version unknown.
I have a polycom ip500 which was working just fine when I was running 0.6.1 on Netbsd 3. (Old and unsuportable, I know!)
Moved to OpenSolaris and 0.8.1. After a number of compile and other hics, things seem to work, but calls drop after half a minute.
I had to change from the old config to the new due to call logging moving to plugins. But I believe the net of the changes is to just comment out log_calls = 1
Again, I've filed bugs against a few things, and I have fixes for them in my code. But I can't find anything in the forums, on the web, or in the code to readily explain why my calls are being dropped. I have other problems, but I'm betting they're all related.
NB OpenSolaris lets me rename ethernets. (I've done this without them being renamed, and siproxd also doesn't work. The renaming is more fundamental than Linux' naming all ethernets to ethN.) So, I have macplaza0 as an interface name to help me remember which ethernet is inside and which is not.
if_inbound = macplaza0
if_outbound = rge0
hosts_allow_reg = 198.98.1.0/24
sip_listen_port = 5060
daemonize = 1
silence_log = 1
user = siproxd
registration_file = /var/db/siproxd_registrations
autosave_registrations = 30
pid_file = /var/run/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low = 7000
rtp_port_high = 7999
rtp_timeout = 300
rtp_dscp = 46
default_expires = 600
debug_level = 0x00000fee
debug_port = 9050
I have the debug captures, and will send them to anyone who wants. They're just way to big to attach.
I have IPFilter set to properly redirect SIP so that I'm a transparent proxy, and to allow the RTP proxy.
Both OpenSolaris and NetBSD use ipfilter, so except for the interface names, the ipf.conf and ipnat.conf
were identical, as are the ifconfigs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would you create a debug log (debuglevel=-1) for such a call (Call setup until it drops) and send it to me (my SF email address)? I'll have a look at it. Please also include a short description (with IP resp. hostnames) of your setup (local UA, router, SIP provider) so I get an idea on the setup you have.
Dropping a call after some time usually means that the call setup has not been completed properly and one party times out and then drops the call.
Regards,
/Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
My provider is a Broadsoft vendor. Version unknown.
I have a polycom ip500 which was working just fine when I was running 0.6.1 on Netbsd 3. (Old and unsuportable, I know!)
Moved to OpenSolaris and 0.8.1. After a number of compile and other hics, things *seem* to work, but calls drop after half a minute.
I had to change from the old config to the new due to call logging moving to plugins. But I believe the net of the changes is to just comment out log_calls = 1
Again, I've filed bugs against a few things, and I have fixes for them in my code. But I can't find anything in the forums, on the web, or in the code to readily explain why my calls are being dropped. I have other problems, but I'm betting they're all related.
NB OpenSolaris lets me rename ethernets. (I've done this without them being renamed, and siproxd also doesn't work. The renaming is more fundamental than Linux' naming all ethernets to ethN.) So, I have macplaza0 as an interface name to help me remember which ethernet is inside and which is not.
if_inbound = macplaza0
if_outbound = rge0
hosts_allow_reg = 198.98.1.0/24
sip_listen_port = 5060
daemonize = 1
silence_log = 1
user = siproxd
registration_file = /var/db/siproxd_registrations
autosave_registrations = 30
pid_file = /var/run/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low = 7000
rtp_port_high = 7999
rtp_timeout = 300
rtp_dscp = 46
default_expires = 600
debug_level = 0x00000fee
debug_port = 9050
I have the debug captures, and will send them to anyone who wants. They're just way to big to attach.
I have IPFilter set to properly redirect SIP so that I'm a transparent proxy, and to allow the RTP proxy.
Both OpenSolaris and NetBSD use ipfilter, so except for the interface names, the ipf.conf and ipnat.conf
were identical, as are the ifconfigs.
Crud, I hate blog posting. ASCII text just gets all glommed up.
Here is that post without pretty print formatting:
No, perhaps this will work:
OK, so I am incompetent to even post a question on this list.
My configs are also available via email if anyone has a clue.
Cheers!
and Thanks for slogging through that mess of text!
-sam
Would you create a debug log (debuglevel=-1) for such a call (Call setup until it drops) and send it to me (my SF email address)? I'll have a look at it. Please also include a short description (with IP resp. hostnames) of your setup (local UA, router, SIP provider) so I get an idea on the setup you have.
Dropping a call after some time usually means that the call setup has not been completed properly and one party times out and then drops the call.
Regards,
/Thomas