Hi, Guys...
After trying a PSTN call through an AS5300-Cisco GW got this error: ==== ON-REPLY[1] incoming reply <200> for <INVITE> <8999>/<XXXXXXXXXXX> ERROR:nathelper:check_content_type: invalid type for a message ERROR:nathelper:extract_body: content type mismatching ERROR:nathelper:force_rtp_proxy: can't extract body from the message == Googling around I found an e-mail from Ovidus (23/12/2008) telling that a multi part SDP wasn't integrated on Nathelper. I suppose that I faced such an issue. How to circumvent/workaround this error message? As a side effect call gives no RTP flow, since one direction send it to RTPProxy and the other directly.
Edson.
-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x
Relevant info....
Using: ==== # kamailio -V version: kamailio 1.5.1-notls (i386/linux) flags: STATISTICS, USE_IPV6, USE_TCP, USE_SCTP, DISABLE_NAGLE, USE_MCAST, 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, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: 2:5868M @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 13:54:27 Jun 4 2009 with gcc 4.3 == The ON-REPLY code is: ==== onreply_route[1] { xlog("L_INFO","ON-REPLY[1] incoming reply <$rs> for <$rm> <$fU>/<$tU>");
if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset(6)) { fix_nated_contact(); } } == The ofending SDP in case is: ==== Content-Type: multipart/mixed;boundary=uniqueBoundary. Content-Length: 378. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7829 2204 IN IP4 XXX.YYY.ZZZ.10. s=SIP Call. c=IN IP4 XXX.YYY.ZZZ.10. t=0 0. m=audio 16976 RTP/AVP 0. c=IN IP4 XXX.YYY.ZZZ.10. a=rtpmap:0 PCMU/8000. --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . ANM,. PRN,isdn*,,QSIG*,. . --uniqueBoundary--. ==
Any ideas on this issue???
Edson.
Edson - Lists escreveu:
Hi, Guys...
After trying a PSTN call through an AS5300-Cisco GW got this error:
ON-REPLY[1] incoming reply <200> for <INVITE> <8999>/<XXXXXXXXXXX> ERROR:nathelper:check_content_type: invalid type for a message ERROR:nathelper:extract_body: content type mismatching ERROR:nathelper:force_rtp_proxy: can't extract body from the message == Googling around I found an e-mail from Ovidus (23/12/2008) telling that a multi part SDP wasn't integrated on Nathelper. I suppose that I faced such an issue. How to circumvent/workaround this error message? As a side effect call gives no RTP flow, since one direction send it to RTPProxy and the other directly.
Edson.
-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x
Relevant info....
Using:
# kamailio -V version: kamailio 1.5.1-notls (i386/linux) flags: STATISTICS, USE_IPV6, USE_TCP, USE_SCTP, DISABLE_NAGLE, USE_MCAST, 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, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: 2:5868M @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 13:54:27 Jun 4 2009 with gcc 4.3 == The ON-REPLY code is: ==== onreply_route[1] { xlog("L_INFO","ON-REPLY[1] incoming reply <$rs> for <$rm> <$fU>/<$tU>");
if ((isflagset(5) || isbflagset(6)) &&status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset(6)) { fix_nated_contact(); } } == The ofending SDP in case is: ==== Content-Type: multipart/mixed;boundary=uniqueBoundary. Content-Length: 378. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7829 2204 IN IP4 XXX.YYY.ZZZ.10. s=SIP Call. c=IN IP4 XXX.YYY.ZZZ.10. t=0 0. m=audio 16976 RTP/AVP 0. c=IN IP4 XXX.YYY.ZZZ.10. a=rtpmap:0 PCMU/8000. --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . ANM,. PRN,isdn*,,QSIG*,. .
--uniqueBoundary--.
El Miércoles, 10 de Junio de 2009, Edson - Lists escribió:
Any ideas on this issue???
I don't expect there is a workaround for it since it involves dedicated parsing in a multipart body (not an easy task).
Understand...
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
Edson.
Iñaki Baz Castillo escreveu:
El Miércoles, 10 de Junio de 2009, Edson - Lists escribió:
Any ideas on this issue???
I don't expect there is a workaround for it since it involves dedicated parsing in a multipart body (not an easy task).
On 06/10/2009 11:19 PM, Edson - Lists wrote:
Understand...
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
you can try to disable the content type checking in nathelper module. The sdp parser there is not very strict, doing line by line.
You should be sure that other content type is not sdp-like so it could get messy.
See modules/nathelper/nhelpr_funcs.c, extract_body() function.
Cheers, Daniel
Edson.
Iñaki Baz Castillo escreveu:
El Miércoles, 10 de Junio de 2009, Edson - Lists escribió:
Any ideas on this issue???
I don't expect there is a workaround for it since it involves dedicated parsing in a multipart body (not an easy task).
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Miércoles, 10 de Junio de 2009, Daniel-Constantin Mierla escribió:
On 06/10/2009 11:19 PM, Edson - Lists wrote:
Understand...
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
you can try to disable the content type checking in nathelper module. The sdp parser there is not very strict, doing line by line.
You should be sure that other content type is not sdp-like so it could get messy.
A content-Type check could take place before invoking force_rtpproxy():
if ( $ct == "application/sdp" || $ct =~ "^multipart/mixed" ) { force_rtpproxy(); [...]
Also the body could be checked by looking for "application/sdp" string.
Thanks.... both of You... I'll try Your sugestion, Iñaki and report back the results.
Edson.
Iñaki Baz Castillo escreveu:
El Miércoles, 10 de Junio de 2009, Daniel-Constantin Mierla escribió:
On 06/10/2009 11:19 PM, Edson - Lists wrote:
Understand...
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
you can try to disable the content type checking in nathelper module. The sdp parser there is not very strict, doing line by line.
You should be sure that other content type is not sdp-like so it could get messy.
A content-Type check could take place before invoking force_rtpproxy():
if ( $ct == "application/sdp" || $ct =~ "^multipart/mixed" ) { force_rtpproxy(); [...]
Also the body could be checked by looking for "application/sdp" string.
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
1.3.16. filter_body(content_type)
Filters multipart body by leaving out all other body parts except the first body part of given type.
Meaning of the parameters is as follows: * content_type - Content type to be left in the body.
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
Example 1.16. filter_body usage ... if (has_body("multipart/mixed")) { if (filter_body("application/sdp") { remove_hf("Content-Type"); append_hf("Content-Type: application/sdp\r\n"); } else { xlog("Body part application/sdp not found\n"); } } ...
-- juha
El Jueves, 11 de Junio de 2009, Juha Heinanen escribió:
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
1.3.16. filter_body(content_type)
Filters multipart body by leaving out all other body parts except the first body part of given type.
Meaning of the parameters is as follows: * content_type - Content type to be left in the body.
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
Example 1.16. filter_body usage ... if (has_body("multipart/mixed")) { if (filter_body("application/sdp") { remove_hf("Content-Type"); append_hf("Content-Type: application/sdp\r\n"); } else { xlog("Body part application/sdp not found\n"); } }
This is really great! But, could it create issues? For example, when Cisco device sends a request with multipart body, which kinds of body does it include?
El Jueves, 11 de Junio de 2009, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
But, could it create issues? For example, when Cisco device sends a request with multipart body, which kinds of body does it include?
it must include application/sdp for voice calls.
Sure, but what more? (I cannot imagine it).
On Sunday 14 June 2009 23:13:49 Andreas Granig wrote:
Iñaki Baz Castillo wrote:
it must include application/sdp for voice calls.
Sure, but what more? (I cannot imagine it).
Probably application/isup for SIP-T?
Umm, but SIP-T is normal SIP, just with extra headers
Hi, Juha....
Thanks for the tip....
I implemented the suggested logic on the ONREPLY_ROUTE. It is recognizing the multi part SDP, but when "filter_body" is called, it returns the following ERROR on the log:
ERROR:textops:filter_body_f: Boundary not found after content
The processed message (a 183 Session Progress with SDP) is bellow. I looked at the documentation, but didn't realize what to do...
Edson.
==RELEVANT CODE================================================== if (has_body("multipart/mixed")) { xlog("L_INFO"," Multipart SDP founded"); xlog("L_INFO","$rb"); if (filter_body("application/sdp")) { remove_hf("Content-Type"); append_hf("Content-Type: application/sdp\r\n"); xlog("L_INFO"," executing 'force_rtp_proxy'"); force_rtp_proxy(); } else { xlog("L_INFO", " Multipart SDP, but Body part application/sdp not found\n"); } } else { xlog("L_INFO"," executing 'force_rtp_proxy'"); force_rtp_proxy(); }
==LOG SHOWs========================================================= Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: ON-REPLY[1] incoming reply <100> for <INVITE> <8999>/<pstn-number> Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: ON-REPLY[1] incoming reply <183> for <INVITE> <8999>/<pstn-number> Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: Multipart SDP founded Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: --uniqueBoundary Content-Type: application/sdp v=0 o=CiscoSystemsSIP-GW-UserAgent 6554 7546 IN IP4 200.xxx.xx.yy s=SIP Call c=IN IP4 200.xxx.xx.yy t=0 0 m=audio 18250 RTP/AVP 0 c=IN IP4 200.xxx.xx.yy a=rtpmap:0 PCMU/8000 --uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional CPG, PRN,isdn*,,QSIG*, --uniqueBoundary-- Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: ERROR:textops:filter_body_f: Boundary not found after content Jun 11 22:31:39 Kamailio-151 /sbin/kamailio[11690]: Multipart SDP, but Body part application/sdp not found
==MESSAGE========================================================= SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 200.xxx.xx.xx;branch=z9hG4bKe54e.5ef97746.0,SIP/2.0/UDP 192.168.1.139:25862;received=189.WW.WWW.WW;branch=z9hG4bK-d8754z-460ee22e063d0246-1---d8754z-;rport=25862. From: "Edson - Kamailio"sip:8999@kamailio.X.Y.Z;tag=7d791c57. To: "PSTN"sip:pstn-number@kamailio.X.Y.Z;tag=E1444EE0-12C9. Date: Fri, 12 Jun 2009 01:31:39 gmt. Call-ID: M2UzMjVmYjM1Mjg2N2IwMWYyYWIxOGM1NjJmMTg1YWE.. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 2 INVITE. Allow-Events: telephone-event. Contact: sip:pstn-number@200.xxx.xx.yy:5060. Record-Route: sip:200.xxx.xx.xx;lr=on;nat=yes. MIME-Version: 1.0. Content-Type: multipart/mixed;boundary=uniqueBoundary. Content-Length: 378. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=CiscoSystemsSIP-GW-UserAgent 6554 7546 IN IP4 200.xxx.xx.yy. s=SIP Call. c=IN IP4 200.xxx.xx.yy. t=0 0. m=audio 18250 RTP/AVP 0. c=IN IP4 200.xxx.xx.yy. a=rtpmap:0 PCMU/8000. --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . CPG,. PRN,isdn*,,QSIG*,. . --uniqueBoundary--.
Juha Heinanen escreveu:
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
1.3.16. filter_body(content_type)
Filters multipart body by leaving out all other body parts except the first body part of given type.
Meaning of the parameters is as follows: * content_type - Content type to be left in the body.
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.
Example 1.16. filter_body usage ... if (has_body("multipart/mixed")) { if (filter_body("application/sdp") { remove_hf("Content-Type"); append_hf("Content-Type: application/sdp\r\n"); } else { xlog("Body part application/sdp not found\n"); } } ...
-- juha
Edson - Lists writes:
I implemented the suggested logic on the ONREPLY_ROUTE. It is recognizing the multi part SDP, but when "filter_body" is called, it returns the following ERROR on the log:
ERROR:textops:filter_body_f: Boundary not found after content
i don't remember what the function assumes about boundaries and empty lines. check that there is crlf after each line in the sdp. i can read the code in the evening when i'm back at my pc.
-- juha
Hi, Juha...
Juha Heinanen escreveu:
Edson - Lists writes:
I implemented the suggested logic on the ONREPLY_ROUTE. It is recognizing the multi part SDP, but when "filter_body" is called, it returns the following ERROR on the log:
ERROR:textops:filter_body_f: Boundary not found after content
i don't remember what the function assumes about boundaries and empty lines. check that there is crlf after each line in the sdp. i can read the code in the evening when i'm back at my pc.
Just checked and all SDP lines are ended by "0x0d,0x0a". So I went to the code and founded in textops.c that filter_body is looking for the string "--Boundary" while Cisco GW uses "--uniqueBondary" as boundary identifier (see the printed $rb on the logs below).
So I twiked the code to also look for the string "--uniqueBondary", recompile and this ERROR message is gone... Now I got new ones from NATHelper (see the last lines below) ... Will look the code, but sure if I could do a thing...
Edson ============================================================== Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ON-REPLY[1] incoming reply <183> for <INVITE> <8999>/<902121035550> Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: Multipart SDP encontrado Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: --uniqueBoundary Content-Type: application/sdp v=0 o=CiscoSystemsSIP-GW-UserAgent 6889 1029 IN IP4 200.139.77.10 s=SIP Call c=IN IP4 200.139.77.10 t=0 0 m=audio 16964 RTP/AVP 0 c=IN IP4 200.139.77.10 a=rtpmap:0 PCMU/8000 --uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional CPG, PRN,isdn*,,QSIG*, --uniqueBoundary-- Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: executando 'force_rtp_proxy' Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:check_content_type: invalid type for a message Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:extract_body: content type mismatching Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:force_rtp_proxy: can't extract body from the message
Just updating:
1) the "bondary" string used by Cisco is defined on the line: Content-Type: multipart/mixed;boundary=uniqueBoundary Somehow it should be extracted and used by filter_body in place of the hardcoded string used today.
2) the ERROR message gived by NAThelper is produced on file nhelpr_func.c, function check_content_type (line 68-150). That's where I stopped...
Edson.
Edson - Lists escreveu:
Hi, Juha...
Juha Heinanen escreveu:
Edson - Lists writes:
I implemented the suggested logic on the ONREPLY_ROUTE. It is >
recognizing the multi part SDP, but when "filter_body" is called, it
returns the following ERROR on the log:
ERROR:textops:filter_body_f: Boundary not found after content
i don't remember what the function assumes about boundaries and empty lines. check that there is crlf after each line in the sdp. i can read the code in the evening when i'm back at my pc.
Just checked and all SDP lines are ended by "0x0d,0x0a". So I went to the code and founded in textops.c that filter_body is looking for the string "--Boundary" while Cisco GW uses "--uniqueBondary" as boundary identifier (see the printed $rb on the logs below).
So I twiked the code to also look for the string "--uniqueBondary", recompile and this ERROR message is gone... Now I got new ones from NATHelper (see the last lines below) ... Will look the code, but sure if I could do a thing...
Edson
Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ON-REPLY[1] incoming reply <183> for <INVITE> <8999>/<902121035550> Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: Multipart SDP encontrado Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: --uniqueBoundary Content-Type: application/sdp v=0 o=CiscoSystemsSIP-GW-UserAgent 6889 1029 IN IP4 200.139.77.10 s=SIP Call c=IN IP4 200.139.77.10 t=0 0 m=audio 16964 RTP/AVP 0 c=IN IP4 200.139.77.10 a=rtpmap:0 PCMU/8000 --uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional CPG, PRN,isdn*,,QSIG*, --uniqueBoundary-- Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: executando 'force_rtp_proxy' Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:check_content_type: invalid type for a message Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:extract_body: content type mismatching Jun 12 16:07:53 Kamailio-151 /sbin/kamailio[18639]: ERROR:nathelper:force_rtp_proxy: can't extract body from the message
El Viernes, 12 de Junio de 2009, Edson - Lists escribió:
- the ERROR message gived by NAThelper is produced on file
nhelpr_func.c, function check_content_type (line 68-150). That's where I stopped...
Yes, it seems that nathelper module checks by itself that the Content-Type of the message is "application/sdp". Perhaps this check could be dropped so the admin could check it using the Kamailio script.
The proper thing to do here would be to integrate the sdp paser from the core.
Regards, Ovidiu Sas
On Fri, Jun 12, 2009 at 4:11 PM, Iñaki Baz Castilloibc@aliax.net wrote:
El Viernes, 12 de Junio de 2009, Edson - Lists escribió:
- the ERROR message gived by NAThelper is produced on file
nhelpr_func.c, function check_content_type (line 68-150). That's where I stopped...
Yes, it seems that nathelper module checks by itself that the Content-Type of the message is "application/sdp". Perhaps this check could be dropped so the admin could check it using the Kamailio script.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Edson - Lists writes:
- the "bondary" string used by Cisco is defined on the line: Content-Type: multipart/mixed;boundary=uniqueBoundary
Somehow it should be extracted and used by filter_body in place of the hardcoded string used today.
looks like filter_body should be improved to extract boundary string from Content-Type header. currently it just uses Boundary as boundary string.
-- juha
Should I open a bug ticket for this (since is a generalization mechanism), or is this more a feature request (since it's required by this particular GW family)?
And in case of open either ticket, should it be on Kamailio tracker or Sip-Router tracker, since on modules_k/textops/textops.c the same problem is present???
Edson.
Juha Heinanen escreveu:
Edson - Lists writes:
- the "bondary" string used by Cisco is defined on the line: Content-Type: multipart/mixed;boundary=uniqueBoundary
Somehow it should be extracted and used by filter_body in place of the hardcoded string used today.
looks like filter_body should be improved to extract boundary string from Content-Type header. currently it just uses Boundary as boundary string.
-- juha
Edson - Lists writes:
Should I open a bug ticket for this (since is a generalization mechanism), or is this more a feature request (since it's required by this particular GW family)?
you can open a ticket. i have not had time to check a mime rfc if there is a default value for boundary if ;boundary param is missing. if there is no default value and the default value is not Boundary, then it is a bug in the module. if Boundary is default value, then i would consider it a feature request (i.e., add support for ;boundary param).
-- juha
edson,
enclosed find a patch to k 1.5 textops.c that takes boundary string from Content-Type header.
let me know if it works for you (or anyone else) and i'll commit the patch.
-- juha
Hi, Juha....
Sorry for the delay, but only now I got to apply the patch. It worked... at least for the AS5300 GW with "signalling forward unconditional", the same config command that gave the original multipart/SDP error on the filter_body function.
Now the error moved to the NatHelper module: ERROR:nathelper:check_content_type: invalid type for a message ERROR:nathelper:extract_body: content type mismatching ERROR:nathelper:force_rtp_proxy: can't extract body from the message
If I understand correctly the code, "check_content_type" looks for the string "application/SDP". And as the error occurs at the "force_rtp_proxy" call, I'm could make many assumptions, but better would be 'talk' with the module maintainer... ;)
Edson
Juha Heinanen escreveu:
edson,
enclosed find a patch to k 1.5 textops.c that takes boundary string from Content-Type header.
let me know if it works for you (or anyone else) and i'll commit the patch.
-- juha
Edson - Lists writes:
Now the error moved to the NatHelper module: ERROR:nathelper:check_content_type: invalid type for a message ERROR:nathelper:extract_body: content type mismatching ERROR:nathelper:force_rtp_proxy: can't extract body from the message
multipart/mixed body will be changed to application/sdp body only after you send out the request. so the change is not visible yet if you call a nathelper function after filter_body function without looping back the request to your proxy.
i have "fixed" this in mediaproxy module.
-- juha
Juha Heinanen escreveu:
Edson - Lists writes:
Now the error moved to the NatHelper module: ERROR:nathelper:check_content_type: invalid type for a message ERROR:nathelper:extract_body: content type mismatching ERROR:nathelper:force_rtp_proxy: can't extract body from the message
multipart/mixed body will be changed to application/sdp body only after you send out the request. so the change is not visible yet if you call a nathelper function after filter_body function without looping back the request to your proxy.
i have "fixed" this in mediaproxy module.
Any chance to have this "fix" applyed to nathelper? If not, I didn't see many alternatives: 1) change GW configurations so that it didn't send multipart/SDP; or 2) move to mediaproxy.
Looping back looks something strange to me. Never done it before and looks like I'd lost info, since rtp-proxy would be applied to localhost host and not to original one... but I can be wrong.
Edson.
Edson - Lists writes:
i have "fixed" this in mediaproxy module.
Any chance to have this "fix" applyed to nathelper? If not, I didn't see many alternatives:
since i am mediaproxy user, i'm not the right person to apply the multipart hack to nathelper module. i checked mediaproxy code and indeed i wrote a hack for it that finds application/sdp bodypart from multipart/mixed body.
Looping back looks something strange to me. Never done it before and looks like I'd lost info, since rtp-proxy would be applied to localhost host and not to original one... but I can be wrong.
indeed looping back may not work here. i wrote the hack for some devices that don't know what to do if they receive multipart body.
-- juha
On 06/17/2009 07:42 PM, Juha Heinanen wrote:
Edson - Lists writes:
i have "fixed" this in mediaproxy module.
Any chance to have this "fix" applyed to nathelper? If not, I didn't see many alternatives:
since i am mediaproxy user, i'm not the right person to apply the multipart hack to nathelper module. i checked mediaproxy code and indeed i wrote a hack for it that finds application/sdp bodypart from multipart/mixed body.
this should be easy to fix in nathelper as well. Please open a issue on the tracker to not forget it: http://sip-router.org/tracker/
Thanks, Daniel
Looping back looks something strange to me. Never done it before and looks like I'd lost info, since rtp-proxy would be applied to localhost host and not to original one... but I can be wrong.
indeed looping back may not work here. i wrote the hack for some devices that don't know what to do if they receive multipart body.
-- juha
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
done...
Edson
Daniel-Constantin Mierla escreveu:
this should be easy to fix in nathelper as well. Please open a issue on the tracker to not forget it: http://sip-router.org/tracker/
Thanks, Daniel
On Jun 11, 2009, at 8:04 AM, Juha Heinanen wrote:
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
A quick glance at the first post in this thread suggests to me that there's some sort of QSIG payload involved. Does the OP really need that? If not, maybe there's a way to disable that on an AS5300? I only have experience with ASS5350, AS5400 and none whatsoever with QSIG but I'm sure that QSIG passthrough can be disabled on the SIP side.
Hi, Andreas...
Your sugestion is good, it's another path to be explored, even if I prefer to have control on Kamailio side...
But so far I didn't find any command that could allow me to disable QSIG messages to be send through SIP. If You have experience with AS5350 and/or AS5400, could You please share the applicable commands?
Edson.
Andreas Sikkema escreveu:
On Jun 11, 2009, at 8:04 AM, Juha Heinanen wrote:
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
A quick glance at the first post in this thread suggests to me that there's some sort of QSIG payload involved. Does the OP really need that? If not, maybe there's a way to disable that on an AS5300? I only have experience with ASS5350, AS5400 and none whatsoever with QSIG but I'm sure that QSIG passthrough can be disabled on the SIP side.
Hi, Andreas....
I found some interesting informations about encapsulating and/or translating/mapping QSIG into SIP messages.
The mapping can be found in: http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/tunneling_...
While the encapsulation (called tunneling) commands are found in: http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/tunneling_... their You will find how to configure it for a hole GW, or just for an interface.
Using that descriptions and info I could make it work configuring "signaling forward rawmsg" in the "voice service voip".
But even so, I'll keep trying to solve this issue (multipart SDP) on script side... I'll never have access to all GWs connected to my SIP-Proxy... :(
Edson.
Edson - Lists escreveu:
Hi, Andreas...
Your sugestion is good, it's another path to be explored, even if I prefer to have control on Kamailio side...
But so far I didn't find any command that could allow me to disable QSIG messages to be send through SIP. If You have experience with AS5350 and/or AS5400, could You please share the applicable commands?
Edson.
Andreas Sikkema escreveu:
On Jun 11, 2009, at 8:04 AM, Juha Heinanen wrote:
Edson - Lists writes:
Maybe, then, someone could point me to how to disable multipart SDP on Cisco AS5300 GWs.... I already dig it on Cisco and Google sites, but so far nothing founded...
instead of disabling multipart in cisco, may be you could use this textops function hack that i wrote for the purpose:
A quick glance at the first post in this thread suggests to me that there's some sort of QSIG payload involved. Does the OP really need that? If not, maybe there's a way to disable that on an AS5300? I only have experience with ASS5350, AS5400 and none whatsoever with QSIG but I'm sure that QSIG passthrough can be disabled on the SIP side.
-
Andreas Granig -
Andreas Sikkema -
Daniel-Constantin Mierla -
Edson - Lists -
Iñaki Baz Castillo -
jh＠tutpro.com -
Ovidiu Sas -
Raúl Alexis Betancor Santana