29 Mar
2006
29 Mar
'06
9:10 a.m.
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 - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
29 Mar
29 Mar
12:21 p.m.
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
1:13 p.m.
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.
--
Jean-Michel Hiver - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
1:24 p.m.
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.
1:36 p.m.
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.
--
Jean-Michel Hiver - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
1:44 p.m.
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.
1:47 p.m.
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(a)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(a)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.
--
Jean-Michel Hiver - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2:03 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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
2:09 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:57 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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(a)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:
__________________________________________________
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 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:23 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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(a)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:
__________________________________________________
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 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
30 Mar
30 Mar
1:58 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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(a)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:
__________________________________________________
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
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
3:14 p.m.
New subject: [Serusers] Via: SIP/2.0/UDP X.X.X.X; branch=0
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(a)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:
__________________________________________________
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 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
>
29 Mar
29 Mar
8:52 p.m.
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.
--
Jean-Michel Hiver - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
30 Mar
30 Mar
3:09 p.m.
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.
6621
days inactive
6622
days old
14 comments
4 participants
participants (4)
-
Carlos Loarca -
Jean-Michel Hiver -
Klaus Darilion -
Simon