[Kamailio-Users] NAThelper and multipart SDP

Pascal Maugeri pascal.maugeri at gmail.com
Tue Jun 23 11:55:38 CEST 2009


Daniel

Are you sure that this source fragment (in nhelpr_funcs.c):

        /* no need for parse_headers(msg, EOH), get_body will
         * parse everything */
        /*is the content type correct?*/
        if((ret = check_content_type(msg))==1)
        {
                LM_ERR("content type mismatching\n");
                goto error;
        }

shouldn't be

        /* no need for parse_headers(msg, EOH), get_body will
         * parse everything */
        /*is the content type correct?*/
        if((ret = check_content_type(msg))== -1)
        {
                LM_ERR("content type mismatching\n");
                goto error;
        }

? ( "==1" --> "==-1")

Because now it gives me errors when processing INVITE with application/sdp
payload.

-pascal


On Tue, Jun 23, 2009 at 10:59 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:

>
>
> On 06/23/2009 10:16 AM, Pascal Maugeri wrote:
>
>> This bug is fixed now with your patch Daniel!
>> Thank you, I go ahead with my testing
>>
> ok, I will backport to kamailio 1.5 in few days if there is no related bug
> reported meanwhile.
>
> Cheers,
> Daniel
>
>
>  Cheers,
>> Pascal
>>
>>
>>
>> On Mon, Jun 22, 2009 at 5:34 PM, Daniel-Constantin Mierla <
>> miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>    Can you check this patch I just committed?
>>
>>
>> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=caef5ace2026fcb2a9dffb471e2cec6d843082f8
>>
>>    Basically, you simply can get the extract_body() function from
>>    nathelper/nhelpr_funcs.c and replace it in kamailio.
>>
>>    Let me know if works ok now.
>>
>>    Thanks,
>>    Daniel
>>
>>
>>    On 06/22/2009 04:22 PM, Daniel-Constantin Mierla wrote:
>>
>>        please send me the original and the new invite so I can see
>>        how the body is changed afterwards.
>>
>>        Cheers,
>>        Daniel
>>
>>        On 06/22/2009 03:23 PM, Pascal Maugeri wrote:
>>
>>            With your patch there is a small bug when re-constructing
>>            the multipart payload:
>>
>>            [...]
>>            --Genaker-boundary
>>            Content-Type: application/sdp
>>
>>            v=0
>>            [...]
>>            a=fmtp:TBCP queuing=0; tb_priority=1; timestamp=0;
>>            tb_granted=0; poc_sess_priority=1; poc_lock=0
>>
>>
>>            *a=nortpproxy:yes--Genaker-boundary*
>>            Content-Type: application/resource-lists+xml
>>
>>            <?xml version="1.0" encoding="UTF-8"?>
>>            <resource-lists
>>            xmlns="urn:ietf:params:xml:ns:resource-lists"
>>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>            [...]
>>
>>            --Genaker-boundary--
>>
>>
>>            Observe the line "a=nortpproxy:yes--Genaker-boundary" :
>>            there are CRLFs missing. And there two CRLF before
>>            "a=nortpproxy:yes". I guess you're adding the CRLF in the
>>            incorrect order.
>>
>>            We're progressing ;-)
>>
>>            -pascal
>>
>>            On Mon, Jun 22, 2009 at 11:36 AM, Daniel-Constantin Mierla
>>            <miconda at gmail.com <mailto:miconda at gmail.com>
>>            <mailto:miconda at gmail.com <mailto:miconda at gmail.com>>> wrote:
>>
>>               Hello Pascal,
>>
>>               I have just committed support for multipart bodies in
>>            sip router,
>>               if works then I will backport to 1.5.
>>
>>
>> http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1f41271e1c1b879217835b8b3fdbdc2680138f25
>>
>>
>>
>>               Can you test it? Unfortunately I cannot do it these
>>            days properly
>>               due to traveling. Patch should work pretty
>>            straightforward with
>>               1.5 though, if you want to test it directly there.
>>
>>               Cheers,
>>               Daniel
>>
>>
>>               On 06/22/2009 11:30 AM, Pascal Maugeri wrote:
>>
>>                   I tried to install mediaproxy but it looks tricky
>>            to install
>>                   (many dependencies, including kernel specific
>>            configurations) :-(
>>                   and I would like to stick to rtpproxy for
>>            performance reason.
>>
>>                   Do you believe the same workaround using
>>            textops/filter_body
>>                   can be used using rtpproxy ? I think yes as these
>>            are two
>>                   different things as said Juha.
>>
>>                   Regards,
>>                   Pascal
>>
>>
>>                   On Fri, Jun 19, 2009 at 9:26 PM, Pascal Maugeri
>>                   <pascal.maugeri at gmail.com
>>            <mailto:pascal.maugeri at gmail.com>
>>            <mailto:pascal.maugeri at gmail.com
>>            <mailto:pascal.maugeri at gmail.com>>
>>                   <mailto:pascal.maugeri at gmail.com
>>            <mailto:pascal.maugeri at gmail.com>
>>                   <mailto:pascal.maugeri at gmail.com
>>            <mailto:pascal.maugeri at gmail.com>>>> wrote:
>>
>>
>>
>>                      On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen
>>                   <jh at tutpro.com <mailto:jh at tutpro.com>
>>            <mailto:jh at tutpro.com <mailto:jh at tutpro.com>>
>>                      <mailto:jh at tutpro.com <mailto:jh at tutpro.com>
>>            <mailto:jh at tutpro.com <mailto:jh at tutpro.com>>>> wrote:
>>
>>                          Pascal Maugeri writes:
>>
>>                           > So if I understand well (please correct
>>            me if I'm wrong)
>>                          the "plan" is:
>>                           >
>>                           > 1º) I install MediaProxy and use Kamailio
>>            MEDIAPROXY
>>                   module
>>                          instead of
>>                           > rtpproxy/NATHelper
>>                           >
>>                           > 2º) filter the app/sdp part with
>>                           >
>>                           > 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");
>>                           >     }
>>                           > }
>>
>>                          you don't need to call filter_body if you
>>            use mediaproxy.
>>
>>                           > 3º) then engage the media proxy with
>>                           >
>>                           > if (method==INVITE && !has_totag()) {
>>                           >
>>                           >     # We can also use a specific media
>>            relay if we
>>                   need to
>>                           >     #$avp(s:media_relay) = "1.2.3.4";
>>                           >     engage_media_proxy();
>>                           > }
>>
>>                          i have never used engage_media_proxy()
>>            functions,
>>                   because it
>>                          makes some
>>                          assumptions that are not generally true.  i use
>>                          use_media_proxy() instead.
>>
>>                           > 4º) finally put the body part(s) that
>>            have been
>>                   removed in
>>                          1º) and relay the
>>                           > INVITE to my next hop.
>>                           >      I believe I can save the body
>>            part(s) in 1º)
>>                   and put
>>                          them back using
>>                           > set_body(txt, content_type).
>>
>>                          you don't need to do anything like that if
>>            you use
>>                          use_media_proxy()
>>                          function, because it does not remove anything.
>>
>>
>>                      Thanks Juha ! I can't wait for monday to test it :-)
>>
>>                      Have a nice week-end
>>                      Pascal
>>
>>                                    -- juha
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>                   _______________________________________________
>>                   Kamailio (OpenSER) - Users mailing list
>>                   Users at lists.kamailio.org
>>            <mailto:Users at lists.kamailio.org>
>>            <mailto:Users at lists.kamailio.org
>>            <mailto:Users at lists.kamailio.org>>
>>
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>>
>>               --     Daniel-Constantin Mierla
>>               http://www.asipto.com/
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>            _______________________________________________
>>            Kamailio (OpenSER) - Users mailing list
>>            Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>>            http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>    --    Daniel-Constantin Mierla
>>    http://www.asipto.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090623/a23d146c/attachment.htm>


More information about the sr-users mailing list