Hi List,
Is there a way to configure SER to properly reject T.38 FAX calls (with a "circuit fast-busy" or something)?
I have tried to google for this but haven't found anything.
Cheers, Jean-Michel.
Jean-Michel Hiver wrote:
Hi List,
Is there a way to configure SER to properly reject T.38 FAX calls (with a "circuit fast-busy" or something)?
I have tried to google for this but haven't found anything.
Cheers, Jean-Michel.
You can use search() to search for a T.38 media line in the SDP and then reject the INVITE using sl_send_reply("403","T.38 not allowed");
To get a fast-busy, you have to take a look at your gateway the see which SIP error code is mapped to fast-busy.
regards klaus
You can use search() to search for a T.38 media line in the SDP and then reject the INVITE using sl_send_reply("403","T.38 not allowed");
OK. Typically, I have this in the SDP media lines:
m=image 6202 udptl t38. a=T38FaxVersion:0. a=T38MaxBitRate:14400. a=T38FaxMaxBuffer:1024. a=T38FaxMaxDatagram:122. a=T38FaxRateManagement:transferredTCF. a=T38FaxUdpEC:t38UDPRedundancy.
So, do you reckon doing:
if (search("(a|A)=(T|t)38")) { sl_send_reply("403","T.38 not allowed. Use ulaw instead"); }
Will do the trick?
Cheers, Jean-Michel.
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
regards klaus
Jean-Michel Hiver wrote:
You can use search() to search for a T.38 media line in the SDP and then reject the INVITE using sl_send_reply("403","T.38 not allowed");
OK. Typically, I have this in the SDP media lines:
m=image 6202 udptl t38. a=T38FaxVersion:0. a=T38MaxBitRate:14400. a=T38FaxMaxBuffer:1024. a=T38FaxMaxDatagram:122. a=T38FaxRateManagement:transferredTCF. a=T38FaxUdpEC:t38UDPRedundancy.
So, do you reckon doing:
if (search("(a|A)=(T|t)38")) { sl_send_reply("403","T.38 not allowed. Use ulaw instead"); }
Will do the trick?
Cheers, Jean-Michel.
Klaus Darilion a écrit :
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
Thanks for this. Now this leads to another question... is it possible to restart / reload SER without interrupting current conversations? Otherwise I'll have to wait 'till very late (or wake up very early) to perform this :)
Cheers, Jean-Michel.
A restart of ser does not interrupt current calls. Maybe current transaction will be lost (to say: if someone dials just in the moment the server is restartet).
regards klaus
Jean-Michel Hiver wrote:
Klaus Darilion a écrit :
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
Thanks for this. Now this leads to another question... is it possible to restart / reload SER without interrupting current conversations? Otherwise I'll have to wait 'till very late (or wake up very early) to perform this :)
Cheers, Jean-Michel.
Since SER is stateless, so restarting SER does not cause a problem with current calls. This assumes you are using a database to store information is, such as registrations etc.
Simon
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Jean-Michel Hiver Sent: 29 March 2006 09:37 To: Klaus Darilion Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Rejecting FAX
Klaus Darilion a écrit :
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
Thanks for this. Now this leads to another question... is it possible to restart / reload SER without interrupting current conversations? Otherwise I'll have to wait 'till very late (or wake up very early) to perform this :)
Cheers, Jean-Michel.
Hi everyone: I have a very strange ser's behavior, I have setup my ser server, it works very well but when I hang up a call, then I recieve many messages like those below.
Max-Forwards: 59 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 213.132.115.200:5060;branch=z9hG4bK2213168
0(15486) DEBUG : sl_filter_ACK: to late to be a local ACK! 0(15486) DEBUG:maxfwd:is_maxfwd_present: value = 59 0(15486) parse_headers: flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) parse_headers: this is the second via 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <z9hG4bK2213168>; state=16
The problem here is that sometimes it doesnt stop sending these messages until it finds the branch ID. What is the reason of this Via Branch=0???
I appreciate any comment about it, Cheers, /Carlos
CUANDO UNO SABE A DONDE VA, EL MUNDO SE ABRE PARA DEJARLO PASAR.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
looks like the message is looped. you can verify this by sniffing on the loopback device too:
ngrep -d any tcpdump -i any
if looping is the case, you have a bug in your ser.cfg
regards klaus
Carlos Loarca wrote:
Hi everyone: I have a very strange ser's behavior, I have setup my ser server, it works very well but when I hang up a call, then I recieve many messages like those below.
Max-Forwards: 59 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 213.132.115.200:5060;branch=z9hG4bK2213168
0(15486) DEBUG : sl_filter_ACK: to late to be a local ACK! 0(15486) DEBUG:maxfwd:is_maxfwd_present: value = 59 0(15486) parse_headers: flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) parse_headers: this is the second via 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <z9hG4bK2213168>; state=16
The problem here is that sometimes it doesnt stop sending these messages until it finds the branch ID. What is the reason of this Via Branch=0???
I appreciate any comment about it, Cheers, /Carlos
CUANDO UNO SABE A DONDE VA, EL MUNDO SE ABRE PARA DEJARLO PASAR.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Yes Klaus, it seems that it is looping. but the strange behaviour occurs when there is a missdialled call and gets the error message from other equipment (ie. voip gateway). Otherwise, the ser performance is correct.
Any clue?. I have checked my traces and the repeated ACK coming from the voip-gateway has the right Via and the ACK sent my ser are ok as well. Where can the problem be?
Cheers, /Carlos
--- Klaus Darilion klaus.mailinglists@pernau.at wrote:
looks like the message is looped. you can verify this by sniffing on the loopback device too:
ngrep -d any tcpdump -i any
if looping is the case, you have a bug in your ser.cfg
regards klaus
Carlos Loarca wrote:
Hi everyone: I have a very strange ser's behavior, I have setup
my
ser server, it works very well but when I hang up
a
call, then I recieve many messages like those
below.
Max-Forwards: 59 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 213.132.115.200:5060;branch=z9hG4bK2213168
0(15486) DEBUG : sl_filter_ACK: to late to be a
local
ACK! 0(15486) DEBUG:maxfwd:is_maxfwd_present: value =
59
0(15486) parse_headers: flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) parse_headers: this is the second via 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <z9hG4bK2213168>; state=16
The problem here is that sometimes it doesnt stop sending these messages until it finds the branch
ID.
What is the reason of this Via Branch=0???
I appreciate any comment about it, Cheers, /Carlos
CUANDO UNO SABE A DONDE VA, EL MUNDO SE ABRE PARA
DEJARLO PASAR.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
To debug this, we would need a complete ngrep trace and ser.cfg (remove sensitive information like passwords)
regards klaus
Carlos Loarca wrote:
Yes Klaus, it seems that it is looping. but the strange behaviour occurs when there is a missdialled call and gets the error message from other equipment (ie. voip gateway). Otherwise, the ser performance is correct.
Any clue?. I have checked my traces and the repeated ACK coming from the voip-gateway has the right Via and the ACK sent my ser are ok as well. Where can the problem be?
Cheers, /Carlos
--- Klaus Darilion klaus.mailinglists@pernau.at wrote:
looks like the message is looped. you can verify this by sniffing on the loopback device too:
ngrep -d any tcpdump -i any
if looping is the case, you have a bug in your ser.cfg
regards klaus
Carlos Loarca wrote:
Hi everyone: I have a very strange ser's behavior, I have setup
my
ser server, it works very well but when I hang up
a
call, then I recieve many messages like those
below.
Max-Forwards: 59 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 83.140.44.243;branch=0 Via: SIP/2.0/UDP 213.132.115.200:5060;branch=z9hG4bK2213168
0(15486) DEBUG : sl_filter_ACK: to late to be a
local
ACK! 0(15486) DEBUG:maxfwd:is_maxfwd_present: value =
59
0(15486) parse_headers: flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) parse_headers: this is the second via 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <0>; state=16 0(15486) end of header reached, state=5 0(15486) parse_headers: Via found, flags=200 0(15486) Found param type 232, <branch> = <z9hG4bK2213168>; state=16
The problem here is that sometimes it doesnt stop sending these messages until it finds the branch
ID.
What is the reason of this Via Branch=0???
I appreciate any comment about it, Cheers, /Carlos
CUANDO UNO SABE A DONDE VA, EL MUNDO SE ABRE PARA
DEJARLO PASAR.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi Klaus, when I run the command "ngrep -d any" I get olny irrelevant packets like
# T 83.140.44.243:22 -> 83.140.44.242:32965 [AP] ,...............AL. ..xI.b.V...........#.$../.KN.;.......e....".P.5.6.8.... .s.{#.`..R.....U4.......}.A.+.l....92 exit 9313 received, 75 dropped
Is that the command I should use???
Cheers, /Carlos
--- Klaus Darilion klaus.mailinglists@pernau.at wrote:
To debug this, we would need a complete ngrep trace and ser.cfg (remove sensitive information like passwords)
regards klaus
Carlos Loarca wrote:
Yes Klaus, it seems that it is looping. but the strange behaviour occurs when there is a
missdialled
call and gets the error message from other
equipment
(ie. voip gateway). Otherwise, the ser performance
is
correct.
Any clue?. I have checked my traces and the
repeated
ACK coming from the voip-gateway has the right Via
and
the ACK sent my ser are ok as well. Where can the problem be?
Cheers, /Carlos
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Carlos Loarca wrote:
Hi Klaus, when I run the command "ngrep -d any" I get
I meant to use the -d any parameter to sniff also on the loopnack interface. You should also have a filter, e.g:
ngrep -d any port 5060
If you do not see any SIP requests with the above command, then there are other problems :-)
regards klaus
olny irrelevant packets like
# T 83.140.44.243:22 -> 83.140.44.242:32965 [AP] ,...............AL. ..xI.b.V...........#.$../.KN.;.......e....".P.5.6.8.... .s.{#.`..R.....U4.......}.A.+.l....92 exit 9313 received, 75 dropped
Is that the command I should use???
Cheers, /Carlos
--- Klaus Darilion klaus.mailinglists@pernau.at wrote:
To debug this, we would need a complete ngrep trace and ser.cfg (remove sensitive information like passwords)
regards klaus
Carlos Loarca wrote:
Yes Klaus, it seems that it is looping. but the strange behaviour occurs when there is a
missdialled
call and gets the error message from other
equipment
(ie. voip gateway). Otherwise, the ser performance
is
correct.
Any clue?. I have checked my traces and the
repeated
ACK coming from the voip-gateway has the right Via
and
the ACK sent my ser are ok as well. Where can the problem be?
Cheers, /Carlos
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Klaus Darilion a écrit :
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
Actually it doesn't seem to block anything. I wonder if search() works only on headers and not on the body of the SDP? In which case I would have no way of performing a condition on T.38... :(
Here is what I have:
if (method!="REGISTER") {
# Reject T.38 Faxing if (search("(a|A)=(T|t)38")) { sl_send_reply("403","T.38 not allowed"); };
<snipped the rest>
};
Cheers, Jean-Michel.
It should work also on the SDP. Try if other regexp match: search("T38")
if the request is sent in-dialog make sure the reject before losse_route
regards klaus
Jean-Michel Hiver wrote:
Klaus Darilion a écrit :
This will certainly block T.38. MAybe we should send some other error code which indicates that this media is not supported. Intelligent devices may then try to fallback to G.711.
Actually it doesn't seem to block anything. I wonder if search() works only on headers and not on the body of the SDP? In which case I would have no way of performing a condition on T.38... :(
Here is what I have:
if (method!="REGISTER") {
# Reject T.38 Faxing if (search("(a|A)=(T|t)38")) { sl_send_reply("403","T.38 not allowed"); }; <snipped the rest>};
Cheers, Jean-Michel.
-
Carlos Loarca -
Jean-Michel Hiver -
Klaus Darilion -
Simon