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
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
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
textops.c-diff
Description: textopts.c-diff
___
Kamailio
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
Hi, Andreas
I found some interesting informations about encapsulating and/or
translating/mapping QSIG into SIP messages.
The mapping can be found in:
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
--
Raúl Alexis
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
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
El Viernes, 12 de Junio de 2009, Edson - Lists escribió:
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...
Yes, it seems that nathelper module checks by itself that the Content-Type of
the
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
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,
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.
-- juha
___
Kamailio (OpenSER) -
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ñaki Baz Castillo writes:
Sure, but what more? (I cannot imagine it).
the idea behind the textops function you don't need to know. only
app/sdp will be remain.
-- juha
___
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
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
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/XXX
ERROR:nathelper:check_content_type: invalid type for a message
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).
--
Iñaki Baz Castillo i...@aliax.net
___
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
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
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
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
Hi, Guys...
After trying a PSTN call through an AS5300-Cisco GW got this error:
ON-REPLY[1] incoming reply 200 for INVITE 8999/XXX
ERROR:nathelper:check_content_type: invalid type for a message
ERROR:nathelper:extract_body: content type mismatching
ERROR:nathelper:force_rtp_proxy:
22 matches
Mail list logo
