Hi Remco,
I agree - t38 should not be seen as a codec, but rather as stream...
Maybe adding 2 new functions will do the trick:
1) stream_search("");
2) stream_remove("");
And use as param the name of the streams.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 01/23/2013 11:55 AM, Remco . wrote:
Hi Bogdan,
Thanks, I will try the fix ASAP.
Only removing t38 is enough to trick the UA in this case to accept the
SDP, however the resulting packet is not valid which can cause issues
with firewalls that do spi.
For it to be valid, the whole media description (including all the
lines starting with T38) should be removed.
T38 is a whole different animal in this perspective being related to a
different stream type instead of a codec option.. Perhaps the
implementation of a remove_stream([audio,video,image]) function or
something like it is an idea for future versions? The use of this
function would be to remove incompatible stream types (e.g. carriers
that do not support video and/or image type streams).
For now, I'll test the fix and report back.
Regards,
Remco.
On Tue, Jan 22, 2013 at 1:35 PM, Bogdan-Andrei Iancu
<[email protected]> wrote:
Hi Remco,
Indeed, I found some issues in the sipmsgops module - the T38 stream seems
to be slightly different than an audio stream. I made a fix on SVN (trunk
rev #9612, 1.8 rev #9613 and 1.7 rev #9614) - please update and re-test.
Now, the "search" part is fine, but on the delete part is strange. If you do
the delete, you end up with like:
v=0
o=- 144969 144969 IN IP4 111.222.111.111
s=-
c=IN IP4 111.222.111.111
t=0 0
m=audio 12345 RTP/AVP 8 0 18
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
m=image 13444 udptl
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:200
a=T38FaxUdpEC:t38UDPRedundancy
See the 'm' line for image, where the codec name was removed, but you end up
with a stream with no codec at all....Is this something valid ? or should
the entire stream be removed ? if we remove the stream (and let's say there
is only one stream), a session without any stream is still valid ??
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 01/22/2013 01:36 AM, Remco . wrote:
Hi Bogdan,
I'm using opensips 1.7.2 (debian package from opensips apt sources).
$> opensips -V
version: opensips 1.7.2-notls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:9543M
@(#) $Id: main.c 9331 2012-10-16 17:26:53Z bogdan_iancu $
main.c compiled on 05:29:22 Jan 9 2013 with gcc 4.4.5
I modified sipp a bit to accept t.38, to be able to reproduce the
issue (I don't have the offending equipment at hand), using the
following xml config:
v=0
o=- 144969 144969 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 8 0 18
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
m=image [media_port] udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:200
a=T38FaxUdpEC:t38UDPRedundancy
That's the plaintext version of the exact SDP, except for addresses and
ports.
I tried the different matching options (regex, non-regex). I ended up
using subst_body() to solve the issue for now but that feels a bit
like modifying the SDP with a chainsaw ;).
Thanks,
Remco.
On Mon, Jan 21, 2013 at 7:57 PM, Bogdan-Andrei Iancu
<[email protected]> wrote:
Hi Remco,
The double "m" means you have two media streams in your SDP. This should
not
affect the codec related functions.
What exact version/revision of OpenSIPs are you using (OpenSIPS -V) ?
also
could you paste here the plain/text SDP you are fighting against ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 01/21/2013 11:15 AM, Remco . wrote:
Hi,
Trying to remove T.38 using the following:
if (is_method("INVITE")&&
codec_exists_re(".*(T38|t38|t.38|T.38).*")) {
xlog("L_WARN", "[$Tf]: A=[$fU] : B=[$rU] :
Call-id=[$ci] : T.38 found in SDP");
# Test if other codec present, and delete T.38 if so.
if (codec_exists("PCMU") || codec_exists("PCMA")) {
codec_delete_re(".*(T38|t38|t.38|T.38).*");
xlog("L_WARN", "[$Tf]: A=[$fU] : B=[$rU] :
Call-id=[$ci] : T.38 removed from SDP");
} else {
xlog("L_WARN", "[$Tf]: A=[$fU] : B=[$rU] :
Call-id=[$ci] : SDP with only T.38");
}
}
It seems not to match the following SDP:
Media Description, name and address (m): audio 54106
RTP/AVP
8 0 101
Media Type: audio
Media Port: 54106
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:101 TELEPHONE-EVENT/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: TELEPHONE-EVENT
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [TELEPHONE-EVENT]
Media format specific parameters: 0-15
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Description, name and address (m): image 56122 udptl
t38
Media Type: image
Media Port: 56122
Media Protocol: udptl
Media Format: t38
Media Attribute (a): T38FaxRateManagement:transferredTCF
Media Attribute Fieldname: T38FaxRateManagement
Media Attribute Value: transferredTCF
Media Attribute (a): T38FaxudpEC:t38UDPFEC
Media Attribute Fieldname: T38FaxudpEC
Media Attribute Value: t38UDPFEC
Could it be that the double media description (m=) is confusing the
codec_* functions from the textops module?
According to the relevant RFC's, it shouldn't but somehow I can't get
it to work..
Regards,
Remco.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users