Hi,
I vote for this. Stray packet filter exposed what is probably a bug in 
Snom firmwares handling Moh and preventing Moh functionality when 
putting on hold a call passing trough sipxbridge. Ranga taught me very 
well: disabling stray packet filter is definitely a bad idea.

On the other side after I spent 18 months (I did not believe it too when 
I saw dates of the first messages with Ranga, but it really happened so 
far away: "Once upon a time ...." ) testing sipxbridge with Snom and I 
finally discover Moh  doesn't work with them for one of the very latest 
security improvements added to sipxbridge. You agree with me that I 
won't have enough time to ask Snom for a bug fix.

Since stray packet filter was added very recently while working on 4.0.1 
not allowing enough testing on interoperability I proposed this to be at 
least configurable. Honestly I don't really mind if I can set stray 
packet behaviour it via sipxconfig. Manually editing a "secret" config 
file would be fine, even substituting sipxbridge.jar with a provided 
stray packet filter disabled version would be perfectly acceptable.

Thanks in advance
Alberto


M. Ranganathan ha scritto:
> Hello,
>
> I have had a couple of user reports already of media path falirures in
> sipxbridge after we turned on  packet filtering of "stray RTP packets"
> last week.
>
> I have also heard from Robert about some firewall products changing the source
> port after about an hour of functioning.
>
> I propose we add a flag in the Nat traversal page to indicate whether
> packet fitering (i.e. rejecting "stray packets" )  is enabled or not
> in sipxrelay.
>
> The default would be to reject stray packets.  Since I think this
> could have some significant operational impact,
> I propose we add that flag in the 4.0 branch. If that is unacceptable,
> we can add it to the
> main branch.
>
> Any comments?
>
> Thanks
>
>
>   


_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to