Forums Read-only archive

How to block codecs in dial plans? *SOLVED*

16 posts · Brekeke SIP Server Forum

KentC Original post
1. Brekeke Product Name and version:
Sip Server 2.x|3.x
2. Java version:
Any
3. OS type and the version:
Any
4. UA (phone), gateway or other hardware/software involved:
N/A
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :
Any
6. Your problem:

In the dial-plan, how do you block codecs that are unsupported like GSM so they are not passed through the proxy?

Thank you!

Kent C.
tuie2
Use $body in the Matching Pattern.

Code: 

$body( "(m=audio .+ RTP/AVP.* 3 )" ) = .+
If a SDP indicates GSM (3 is GMS's payloadtype), the above $body matches.
KentC
Thank you for the help! I will save and test, then update if this is solved!











Kent C.
tuie2
Refer to the following page. Is is the list of codec payload types.
http://www.iana.org/assignments/rtp-par ... rameters-1
KentC
Matching Patterns:

$addr=*\.*\.*\.*
$request=INVITE
$body=( "(m=audio .+ RTP/AVP.* 3 )" ) = .+
From=sip:(.+)@

Deploy Patterns:

From=sip:(.+)@ To=sip:210xxxxxxx@IP
$rtp=true


When i add the $body, the call fails pretty fast.
I did run a trace and that blocked the call all together. I will test to a different term and see if that works. Does the plan above look ok?


When I remove that $body, call completes.

This is traveling like this:

Orig Carrier > Carrier Proxy > Our Proxy > Term Carrier

I have it configured to go through both proxies. Any additional help is appreciated.
tuie2
> $body=( "(m=audio .+ RTP/AVP.* 3 )" ) = .+

It is wrong..
It must be
$body( "(m=audio .+ RTP/AVP.* 3 )" ) = .+
KentC
False Positive. Still not working with dial-pattern addon setup as specified.
tuie2
:D
KentC
Hey, I retested and found it was taking another rule that was working. I disabled the rule and now those that I thought with that codec that would work aren't.

Can you please advise what else could be the issue.

I tried with a second DID i have configured that works no problem with that code added and it also fails. Any helps is greatly debted. Thank you.


EDIT - When I did a pcap, it's showing '404' not found with that $body string text placed.





Kent C.
tuie2
Can you paste your rules here?

If you are using Brekeke ver3, set "dialplan.debug.log=true" in the Config's Advanced page for debugging DialPlan.
KentC

Code: 


Matching Pattern:

$addr=*\.*\.*\.*
$request=INVITE
$body( "(m=audio .+ RTP/AVP.* 3 )" )=.+
From=sip:(.+)@

Deploy Pattern:

To=sip:2102023212@*.*.*.* 
$rtp=true
I'm using Brekeke Sip Server v2
tuie2
Are you sure that the INVITE's SDP indicates GSM as a codec?
If not, the above rule doesn't match and "404" will be returned.

Can you paste the SDP part of INVITE here?
KentC

Code: 


Here is the filter I ran in wireshark:
sdp.media == "audio 17882 RTP/AVP 18 0 8 101"

Media Description, name and address (m): audio 17882 RTP/AVP 18 0 8 101
                Media Type: audio
                Media Port: 17882
                Media Protocol: RTP/AVP
                Media Format: ITU-T G.729
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.711 PCMA
I appreciate your help, so the codec has to exist to be blocked or call fails... So if i change that to block like G.711, and test it will work then i assume?
KentC
Tested with your advice and now the call completes. Does that look right to block G.729? Where can i see if its blocked? Would it show that it's actually blocked on Brekeke or just the INVITE SDP of the trace pcap? I didn't see where to find that.

Code: 

$addr=*
$request=INVITE
From=sip:(.+)@
$body( "(m=audio .+ RTP/AVP.* 18 )" )=.+
tuie2
Yes. the payload type 18 means G729.
(See http://www.iana.org/assignments/rtp-par ... rameters-1)


> Where can i see if its blocked?

If the above rule matches, its Deploy Patterns will be executed.


If you want to debug DialPlan rules, I recommend that you use brekeke v3 because it has DialPlan History feature.
KentC
Thank you for all your help. I will study this more and try the new version of brekeke.

This is fully resolved.