try message_list=INVITE,ACK
what you are possibly looking for is codec (sdp) filter, not message filter. note that this is on codec name, not payload id (which may be dynamic). see the example profiles. stefan On 3/31/11, Andreas Granig <[email protected]> wrote: > Hi, > > I was experimenting with message_filter in SBC and tried to set this one: > > message_filter=whitelist > message_list=8,101 > > This seems quite broken. SDP infos are not filtered, instead the ACK is > blocked. > > What happens in detail is that SEMS (latest trunk) forwards the INVITE > unfiltered, like this: > > m=audio 8000 RTP/AVP 98 97 8 0 3 101 > a=rtpmap:98 speex/16000 > a=rtpmap:97 speex/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:3 GSM/8000 > a=rtpmap:101 telephone-event/8000 > > Then the 200 comes back from the called party, like this: > > m=audio 8000 RTP/AVP 98 97 8 0 3 101 > a=rtpmap:98 speex/16000 > a=rtpmap:101 telephone-event/8000 > > Also that one is passed trough unfiltered, but when the ACK comes back, > SEMS logs this: > > [onSipRequest, SBC.cpp:813] DEBUG: replying 405 to filtered message 'ACK' > [updateStatusReply, AmSipDialog.cpp:252] ERROR: could not find any > transaction matching request > [updateStatusReply, AmSipDialog.cpp:256] ERROR: reply code=405; > method=ACK; [email protected]; > local_tag=587A3B56-4D9462130008FE9E-D2131700; remote_tag=cnfit; cseq=381 > > The ACK is never forwarded, but the 405 is also not sent, letting the > dialog stay in a half-opened way until the called party tears down the > call because of the missing ACK. > > All works as expected if I set "message_filter=transparent". Any ideas? > > Andreas > > _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
