21 Feb
2015
21 Feb
'15
2:19 a.m.
Hi Klaus, did you find a solution to this problem? I'm working with SIP-I and having
the same issue with Binary encoding. I need to encode a 0x00 value and when the config
script gets to that point, it breaks. If I encode any other hex value it's fine. This
is the config part I'm using:
route[INSERT_ACM]{
if(has_body()){
# Save the SDP body for future reference
$var(sdp_body) = $rb;
replace_body_atonce("^.+$", "");
remove_hf("Content-Type");
append_hf("MIME-Version: 1.0\r\n", "Content-Length");
append_hf("Content-Type: multipart/mixed;
boundary=unique-boundary-1\r\n", "Allow");
replace_body_atonce("^.+$",
"--unique-boundary-1\r\nContent-Disposition: signal;
handling=optional\r\nContent-Type: application/isup;
version=itu-t92+\r\n\r\n'\x06''\x02''\x04''\x01''\x29''\x01''\x01''\x00'\r\n-unique-boundary-1\r\n");
msg_apply_changes();
replace_body_all("\047", "");
append_body_part("$var(sdp_body)","application/sdp");
}
return;
}
I tried with the escape character \0 which should be translated to ASCII hex value
'00' but it's parsed as ASCII literal values \0...
Thanks!
Federico
Federico San Martín
e-mail : fsanmartin(a)telecentro.net.ar
On 9/17/13 4:34 PM, Daniel wrote:
Hello,
most of the functions for pseudo-variables work with string types, that
because a script variable can have only integer or string values. Even
the length can be higher, these functions truncate at first 0. But
internally all should be kept, just not passed to config variables.
Have you tried exec_msg(), that should pass entire msg?
Otherwise, I presume there is need for some C coding to make binary
values work with variables in config.
Cheers,
Daniel
On 9/17/13 4:03 PM, Klaus Feichtinger wrote:
Hello,
I have an update to the side effects of receiving an INVITE message that
contains a MIME body with binary data:
- pseudo variables are affected, too
- the message buffer ($mb) does not include the whole message; it is
ending with the nul character
- as the message buffer does not include all data, the modification
cannot be done with an external script / program (e.g. perl, bash script)
The behaviour was tested with kamailio 4.0.3, too - no difference!
In general, the whole message is stored in a buffer, but parts of it are
inaccessible for parsing / text functions.
Any idea, what could cause this problem?
regards,
Klaus
Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding "binary data" in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the "text" type are defined to have a default charset
value of "UTF-8".
However, the Kamailio function "Regular Expression Transformation"
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the "x-q931" and "gtd" body parts is depending on
(UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the "User-to-User" header field). The content of these UUS1 data
may contain also byte values "00", which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question is:
- is this a bug in Kamailio parsing functions?
- is this a design issue of Kamailio text parsers (as binary data are
allowed acc. RFC3261) - does anybody know a solution for this problem?
This "bug" is causing big troubles....
Thanks in advance,
Klaus Feichtinger
P.S. trace data (1)...(3) of my problem
(1) exemplary content of the x-q931 body
======================Sending: Binary Message Body
Sep 13 10:50:19: Content-Type: application/x-q931
08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70
05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00
2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A
(2) SIP INVITE message (debugger view)
=============================INVITE sip:115101@<ipv4>:5060 SIP/2.0 Via:
SIP/2.0/UDP <ipv4>:5060;branch=z9hG4bK171164E
From: <sip:1101015004@<ipv4>>;tag=29E16410-2541
To: <sip:115101@<ipv4>>
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@<ipv4>
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: <sip:1101015004@<ipv4>:5060>
Expires: 1800
P-Asserted-Identity: <sip:1101015004@<ipv4>>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 820
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 <ipv4>
s=SIP Call
c=IN IP4 <ipv4>
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 <ipv4>
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 62
4" l15004p15001}~Bu%C1b..,h d.brA9W
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,,
USI,rate,c,s,c,1
USI,lay1,ulaw
TMR,00
CPN,08,,1,5001
CGN,08,,1,,,5004
UUS,3,1d427525924331629400002c6820640062f21041b9d7bd
CPC,09
FCI,,,,,,,y,
GCI,185ef1291b9911e381d500270dff3fa0
--uniqueBoundary--
(3) config excerpt
============if (has_body("multipart/mixed")) {
if (filter_body("application/sdp")) {
remove_hf("Mime-Version");
remove_hf("Content-Type");
append_hf("Content-Type: application/sdp\r\n");
} else {
xlog("L_WARN", " <route> message body part
'application/sdp' not
found\n");
}
$var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s});
append_hf("User-to-User: $var(UUS)\r\n", "CSeq");
if
!(subst_body('/Content-Disposition..session.handling=required....//s'))
{
xlog("L_WARN", " <route> substituting Content-Disposition
FAILED!!! \n");
}
msg_apply_changes();
if (search_body("a=[a-z]+:.+[\r\n]{4}$")) {
#!ifdef WITH_XLOGDEBUG
xlog("L_INFO", " <route> double CRLF at the end of the
message
body detected - is reduced to one now. \n"); #!endif
$var(sdp) = $(rb{s.striptail,2});
set_body("$var(sdp)", "application/sdp");
}
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com - 
26 Feb
26 Feb
10:10 p.m.
Hi Frederico,
the only (quick) solution I had found was doing message parsing (MIME
body) in an external PERL script, returning the information that I was
searching for (from that body) to the config script and reducing the
multipart body to a single body. This is (until now) working fine...
However, I was using Kamailio version 3.2.x in this situation, but I
think that there will be no change to the newest version, as it is a
basic C language problem.
Please note that PERL was the language that I was finding the fastest
solution with. Maybe you can use an alternative language, too.
regards,
Klaus
Am 21.02.2015 um 01:19 schrieb Federico San Martín:
Hi Klaus, did you find a solution to this problem?
I'm working with SIP-I and having the same issue with Binary encoding. I need to
encode a 0x00 value and when the config script gets to that point, it breaks. If I encode
any other hex value it's fine. This is the config part I'm using:
route[INSERT_ACM]{
if(has_body()){
# Save the SDP body for future reference
$var(sdp_body) = $rb;
replace_body_atonce("^.+$", "");
remove_hf("Content-Type");
append_hf("MIME-Version: 1.0\r\n",
"Content-Length");
append_hf("Content-Type: multipart/mixed;
boundary=unique-boundary-1\r\n", "Allow");
replace_body_atonce("^.+$",
"--unique-boundary-1\r\nContent-Disposition: signal;
handling=optional\r\nContent-Type: application/isup;
version=itu-t92+\r\n\r\n'\x06''\x02''\x04''\x01''\x29''\x01''\x01''\x00'\r\n-unique-boundary-1\r\n");
msg_apply_changes();
replace_body_all("\047", "");
append_body_part("$var(sdp_body)","application/sdp");
}
return;
}
I tried with the escape character \0 which should be translated to ASCII hex value
'00' but it's parsed as ASCII literal values \0...
Thanks!
Federico
Federico San Martín
e-mail : fsanmartin(a)telecentro.net.ar
On 9/17/13 4:34 PM, Daniel wrote:
Hello,
most of the functions for pseudo-variables work with string types, that
because a script variable can have only integer or string values. Even
the length can be higher, these functions truncate at first 0. But
internally all should be kept, just not passed to config variables.
Have you tried exec_msg(), that should pass entire msg?
Otherwise, I presume there is need for some C coding to make binary
values work with variables in config.
Cheers,
Daniel
On 9/17/13 4:03 PM, Klaus Feichtinger wrote:
Hello,
I have an update to the side effects of receiving an INVITE message that
contains a MIME body with binary data:
- pseudo variables are affected, too
- the message buffer ($mb) does not include the whole message; it is
ending with the nul character
- as the message buffer does not include all data, the modification
cannot be done with an external script / program (e.g. perl, bash script)
The behaviour was tested with kamailio 4.0.3, too - no difference!
In general, the whole message is stored in a buffer, but parts of it are
inaccessible for parsing / text functions.
Any idea, what could cause this problem?
regards,
Klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding "binary data" in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the "text" type are defined to have a default charset
value of "UTF-8".
However, the Kamailio function "Regular Expression Transformation"
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the "x-q931" and "gtd" body parts is depending on
(UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the "User-to-User" header field). The content of these UUS1 data
may contain also byte values "00", which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question is:
- is this a bug in Kamailio parsing functions?
- is this a design issue of Kamailio text parsers (as binary data are
allowed acc. RFC3261) - does anybody know a solution for this problem?
This "bug" is causing big troubles....
Thanks in advance,
Klaus Feichtinger
P.S. trace data (1)...(3) of my problem
(1) exemplary content of the x-q931 body
======================Sending: Binary Message Body
Sep 13 10:50:19: Content-Type: application/x-q931
08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70
05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00
2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A
(2) SIP INVITE message (debugger view)
=============================INVITE sip:115101@<ipv4>:5060 SIP/2.0 Via:
SIP/2.0/UDP <ipv4>:5060;branch=z9hG4bK171164E
From: <sip:1101015004@<ipv4>>;tag=29E16410-2541
To: <sip:115101@<ipv4>>
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@<ipv4>
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: <sip:1101015004@<ipv4>:5060>
Expires: 1800
P-Asserted-Identity: <sip:1101015004@<ipv4>>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 820
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 <ipv4>
s=SIP Call
c=IN IP4 <ipv4>
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 <ipv4>
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 62
4" l15004p15001}~Bu%C1b..,h d.brA9W
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,,
USI,rate,c,s,c,1
USI,lay1,ulaw
TMR,00
CPN,08,,1,5001
CGN,08,,1,,,5004
UUS,3,1d427525924331629400002c6820640062f21041b9d7bd
CPC,09
FCI,,,,,,,y,
GCI,185ef1291b9911e381d500270dff3fa0
--uniqueBoundary--
(3) config excerpt
============if (has_body("multipart/mixed")) {
if (filter_body("application/sdp")) {
remove_hf("Mime-Version");
remove_hf("Content-Type");
append_hf("Content-Type: application/sdp\r\n");
} else {
xlog("L_WARN", " <route> message body part
'application/sdp' not
found\n");
}
$var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s});
append_hf("User-to-User: $var(UUS)\r\n", "CSeq");
if
!(subst_body('/Content-Disposition..session.handling=required....//s'))
{
xlog("L_WARN", " <route> substituting Content-Disposition
FAILED!!! \n");
}
msg_apply_changes();
if (search_body("a=[a-z]+:.+[\r\n]{4}$")) {
#!ifdef WITH_XLOGDEBUG
xlog("L_INFO", " <route> double CRLF at the end of the
message
body detected - is reduced to one now. \n"); #!endif
$var(sdp) = $(rb{s.striptail,2});
set_body("$var(sdp)", "application/sdp");
}
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
27 Feb
27 Feb
4:12 p.m.
Thank you for the quick reply Klaus! I'm currently trying a new patch for the SIPT
module created by Torrey Searle that allows me to modify the binary data on the BCI byte,
the only caveat is that you have to receive the BCI to modify it, you can't create it
on the fly.
BR,
Federico
----- Original Message -----
From: "Klaus Feichtinger" <klaus.lists(a)inode.at>
To: sr-users(a)lists.sip-router.org, fsanmartin(a)telecentro.net.ar
Sent: Thursday, February 26, 2015 5:10:22 PM
Subject: Re: [SR-Users] TEXTOPS parser problem with binary data in MIME body
Hi Frederico,
the only (quick) solution I had found was doing message parsing (MIME
body) in an external PERL script, returning the information that I was
searching for (from that body) to the config script and reducing the
multipart body to a single body. This is (until now) working fine...
However, I was using Kamailio version 3.2.x in this situation, but I
think that there will be no change to the newest version, as it is a
basic C language problem.
Please note that PERL was the language that I was finding the fastest
solution with. Maybe you can use an alternative language, too.
regards,
Klaus
Am 21.02.2015 um 01:19 schrieb Federico San Martín:
Hi Klaus, did you find a solution to this problem?
I'm working with SIP-I and having the same issue with Binary encoding. I need to
encode a 0x00 value and when the config script gets to that point, it breaks. If I encode
any other hex value it's fine. This is the config part I'm using:
route[INSERT_ACM]{
if(has_body()){
# Save the SDP body for future reference
$var(sdp_body) = $rb;
replace_body_atonce("^.+$", "");
remove_hf("Content-Type");
append_hf("MIME-Version: 1.0\r\n", "Content-Length");
append_hf("Content-Type: multipart/mixed; boundary=unique-boundary-1\r\n",
"Allow");
replace_body_atonce("^.+$", "--unique-boundary-1\r\nContent-Disposition:
signal; handling=optional\r\nContent-Type: application/isup;
version=itu-t92+\r\n\r\n'\x06''\x02''\x04''\x01''\x29''\x01''\x01''\x00'\r\n-unique-boundary-1\r\n");
msg_apply_changes();
replace_body_all("\047", "");
append_body_part("$var(sdp_body)","application/sdp");
}
return;
}
I tried with the escape character \0 which should be translated to ASCII hex value
'00' but it's parsed as ASCII literal values \0...
Thanks!
Federico
Federico San Martín
e-mail : fsanmartin(a)telecentro.net.ar
On 9/17/13 4:34 PM, Daniel wrote:
Hello,
most of the functions for pseudo-variables work with string types, that
because a script variable can have only integer or string values. Even
the length can be higher, these functions truncate at first 0. But
internally all should be kept, just not passed to config variables.
Have you tried exec_msg(), that should pass entire msg?
Otherwise, I presume there is need for some C coding to make binary
values work with variables in config.
Cheers,
Daniel
On 9/17/13 4:03 PM, Klaus Feichtinger wrote:
Hello,
I have an update to the side effects of receiving an INVITE message that
contains a MIME body with binary data:
- pseudo variables are affected, too
- the message buffer ($mb) does not include the whole message; it is
ending with the nul character
- as the message buffer does not include all data, the modification
cannot be done with an external script / program (e.g. perl, bash script)
The behaviour was tested with kamailio 4.0.3, too - no difference!
In general, the whole message is stored in a buffer, but parts of it are
inaccessible for parsing / text functions.
Any idea, what could cause this problem?
regards,
Klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding "binary data" in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the "text" type are defined to have a default charset
value of "UTF-8".
However, the Kamailio function "Regular Expression Transformation"
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the "x-q931" and "gtd" body parts is depending on
(UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the "User-to-User" header field). The content of these UUS1 data
may contain also byte values "00", which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question is:
- is this a bug in Kamailio parsing functions?
- is this a design issue of Kamailio text parsers (as binary data are
allowed acc. RFC3261) - does anybody know a solution for this problem?
This "bug" is causing big troubles....
Thanks in advance,
Klaus Feichtinger
P.S. trace data (1)...(3) of my problem
(1) exemplary content of the x-q931 body
======================Sending: Binary Message Body
Sep 13 10:50:19: Content-Type: application/x-q931
08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70
05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00
2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A
(2) SIP INVITE message (debugger view)
=============================INVITE sip:115101@<ipv4>:5060 SIP/2.0 Via:
SIP/2.0/UDP <ipv4>:5060;branch=z9hG4bK171164E
From: <sip:1101015004@<ipv4>>;tag=29E16410-2541
To: <sip:115101@<ipv4>>
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@<ipv4>
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: <sip:1101015004@<ipv4>:5060>
Expires: 1800
P-Asserted-Identity: <sip:1101015004@<ipv4>>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 820
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 <ipv4>
s=SIP Call
c=IN IP4 <ipv4>
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 <ipv4>
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 62
4" l15004p15001}~Bu%C1b..,h d.brA9W
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,,
USI,rate,c,s,c,1
USI,lay1,ulaw
TMR,00
CPN,08,,1,5001
CGN,08,,1,,,5004
UUS,3,1d427525924331629400002c6820640062f21041b9d7bd
CPC,09
FCI,,,,,,,y,
GCI,185ef1291b9911e381d500270dff3fa0
--uniqueBoundary--
(3) config excerpt
============if (has_body("multipart/mixed")) {
if (filter_body("application/sdp")) {
remove_hf("Mime-Version");
remove_hf("Content-Type");
append_hf("Content-Type: application/sdp\r\n");
} else {
xlog("L_WARN", " <route> message body part 'application/sdp'
not
found\n");
}
$var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s});
append_hf("User-to-User: $var(UUS)\r\n", "CSeq");
if
!(subst_body('/Content-Disposition..session.handling=required....//s'))
{
xlog("L_WARN", " <route> substituting Content-Disposition
FAILED!!! \n");
}
msg_apply_changes();
if (search_body("a=[a-z]+:.+[\r\n]{4}$")) {
#!ifdef WITH_XLOGDEBUG
xlog("L_INFO", " <route> double CRLF at the end of the message
body detected - is reduced to one now. \n"); #!endif
$var(sdp) = $(rb{s.striptail,2});
set_body("$var(sdp)", "application/sdp");
}
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
3556
days inactive
3562
days old
2 comments
2 participants
participants (2)
-
Federico San Martín -
Klaus Feichtinger