[asterisk-bugs] [Asterisk 0016766]: T.38 negotiation fails with Patton SN2400
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Feb 8 10:29:49 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16766
======================================================================
Reported By: raivisr
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16766
Category: Channels/chan_sip/T.38
Reproducibility: always
Severity: major
Priority: normal
Status: acknowledged
Asterisk Version: SVN
JIRA: SWP-868
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 244639
Request Review:
======================================================================
Date Submitted: 2010-02-03 16:00 CST
Last Modified: 2010-02-08 10:29 CST
======================================================================
Summary: T.38 negotiation fails with Patton SN2400
Description:
Patton SN2400 refuses to negotiate T.38 session because of extra newline in
SDP.
[Feb 3 22:31:46] DEBUG[31017] chan_sip.c: Body 5 [ 22]: m=image 4326
udptl t38
[Feb 3 22:31:46] DEBUG[31017] chan_sip.c: Body 6 [ 0]:
[Feb 3 22:31:46] DEBUG[31017] chan_sip.c: Body 7 [ 17]:
a=T38FaxVersion:0
proposed fix:
--- asterisk.orig/channels/chan_sip.c 2010-02-03 23:52:03.000000000 +0200
+++ asterisk/channels/chan_sip.c 2010-02-03 23:58:41.000000000 +0200
@@ -9191,8 +9191,6 @@ static enum sip_result add_sdp(struct si
ast_str_append(&m_video, 0, "\r\n");
if (needtext)
ast_str_append(&m_text, 0, "\r\n");
- if (add_t38)
- ast_str_append(&m_modem, 0, "\r\n");
len = strlen(version) + strlen(subject) + strlen(owner) +
strlen(connection) + strlen(session_time);
======================================================================
----------------------------------------------------------------------
(0117840) lmadsen (administrator) - 2010-02-08 10:29
https://issues.asterisk.org/view.php?id=16766#c117840
----------------------------------------------------------------------
Information about where and why the change was added:
lmadsen at asterisk-releaser:~/WORKING/asterisk/trunk/channels$ svn annotate
-r100000:HEAD chan_sip.c | grep "m_modem" | more
184948 file struct ast_str *m_modem = ast_str_alloca(256); /*
Media declaration line for modem */
243860 russell ast_str_append(&m_modem, 0, "m=image %d udptl
t38\r\n", ntohs(udptldest.sin_port));
225089 file ast_str_append(&m_modem, 0, "c=IN IP4 %s\r\n",
ast_inet_ntoa(udptldest.sin_addr));
184948 file ast_str_append(&m_modem, 0, "\r\n");
184948 file len += m_modem->used + a_modem->used;
184948 file add_line(resp, m_modem->str);
lmadsen at asterisk-releaser:~/WORKING/asterisk/trunk/channels$ svn log
-r184948 http://svn.asterisk.org/svn/asterisk/trunk
------------------------------------------------------------------------
r184948 | file | 2009-03-30 09:37:47 -0500 (Mon, 30 Mar 2009) | 21 lines
Merged revisions 184947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14
lines
Improve our handling of T38 in the initial INVITE from a device.
We now answer with matching media streams to what is requested. If an
INVITE
is received with both a T38 and RTP media stream this means we answer
with both.
For any outgoing calls created as a result of this inbound one no T38 is
requested
in the initial INVITE. Instead if we start receiving udptl packets we
trigger a
reinvite on the outbound side.
(closes issue https://issues.asterisk.org/view.php?id=12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
........
------------------------------------------------------------------------
Issue History
Date Modified Username Field Change
======================================================================
2010-02-08 10:29 lmadsen Note Added: 0117840
======================================================================
More information about the asterisk-bugs
mailing list