Thanks Alex but I'm not sure if I understood correctly your answer : do you mean that NATHelper only handle INVITE with a unique SDP part (application/sdp) ? If NATHelper processes my INVITE with multipart, does it modify only the SDP part ?

-pascal

On Fri, Jun 19, 2009 at 11:58 AM, Alex Balashov abalashov@evaristesys.comwrote:

Nathelper does not attempt to modify parts of SDP not pertinent to its mission.

Pascal Maugeri wrote:

Hi

...

Does NATHelper support properly multipart SDP (eg. INVITE with application/sdp and application/resource-lists+xml) ?

Regards, Pascal

---

---

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

-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

Here is the errors I get when processing the INVITE:

Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:check_content_type: invalid type for a message Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:extract_body: content type mismatching Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:force_rtp_proxy: can't extract body from the message

is it familiar to you ?

-pascal

On Fri, Jun 19, 2009 at 12:25 PM, Alex Balashov abalashov@evaristesys.comwrote:

As I understand it, yes, only the SDP payload per se is modified.

Pascal Maugeri wrote:

Thanks Alex but I'm not sure if I understood correctly your answer : do

...

you mean that NATHelper only handle INVITE with a unique SDP part (application/sdp) ? If NATHelper processes my INVITE with multipart, does it modify only the SDP part ?

-pascal

On Fri, Jun 19, 2009 at 11:58 AM, Alex Balashov < abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:

Nathelper does not attempt to modify parts of SDP not pertinent to its mission.

Pascal Maugeri wrote:

   Hi

   Does NATHelper support properly multipart SDP (eg. INVITE with
   application/sdp and application/resource-lists+xml)  ?

   Regards,
   Pascal

---

   _______________________________________________
   Kamailio (OpenSER) - Users mailing list
   Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>
   http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
   http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

Sure!

Here it is:

--pascal-boundary Content-Type: application/sdp

v=0 o=- 3376939113 3376939113 IN IP4 10.1.1.248 s=pjmedia c=IN IP4 10.1.1.248 t=0 0 a=X-nat:0 m=audio 4000 RTP/AVP 115 a=rtcp:4001 IN IP4 10.1.1.248 a=rtpmap:115 AMR/8000 a=fmtp:115 octet-align=1 a=ptime:20 a=maxptime:400 a=sendrecv m=application 4001 udp TBCP a=fmtp:TBCP queuing=0; tb_priority=1; timestamp=0; tb_granted=0; poc_sess_priority=1; poc_lock=0

--pascal-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"> <list> <entry uri="sip:blue@pascal.net <sip%3Ablue@pascal.net>" /> </list> </resource-lists>

--pascal-boundary--

I was checking the nathelper source code (nhelpr_func.c) and it looks that only a content-type of application/sdp is accepted.

-pascal

2009/6/19 Victor Pascual Ávila victor.pascual.avila@gmail.com

Hi Pascal,

could you please attach the INVITE body?

Thanks, -Victor

On Fri, Jun 19, 2009 at 12:54 PM, Pascal Maugeripascal.maugeri@gmail.com wrote:

...

Here is the errors I get when processing the INVITE:

Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:check_content_type: invalid type for a message Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:extract_body: content type mismatching Jun 19 14:51:58 sandbox /usr/sbin/kamailio[15560]: ERROR:nathelper:force_rtp_proxy: can't extract body from the message

is it familiar to you ?

-pascal

On Fri, Jun 19, 2009 at 12:25 PM, Alex Balashov <

abalashov@evaristesys.com>

...

wrote:

...

As I understand it, yes, only the SDP payload per se is modified.

Pascal Maugeri wrote:

...

Thanks Alex but I'm not sure if I understood correctly your answer : do you mean that NATHelper only handle INVITE with a unique SDP part (application/sdp) ? If NATHelper processes my INVITE with multipart,

does it

...

...

...

modify only the SDP part ?

-pascal

On Fri, Jun 19, 2009 at 11:58 AM, Alex Balashov <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:

Nathelper does not attempt to modify parts of SDP not pertinent to its mission.

Pascal Maugeri wrote:

   Hi

   Does NATHelper support properly multipart SDP (eg. INVITE with
   application/sdp and application/resource-lists+xml)  ?

   Regards,
   Pascal

---

...

...

...

   _______________________________________________
   Kamailio (OpenSER) - Users mailing list
   Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>
   http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
   http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

---

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

-- Victor Pascual Ávila

I found the tracker in sip-router but nothing in Kamailio. Does it mean that this is a fix that will be applied only to sip-router module ? -pascal

On Fri, Jun 19, 2009 at 1:35 PM, Juha Heinanen jh@tutpro.com wrote:

Pascal Maugeri writes:

...

I was checking the nathelper source code (nhelpr_func.c) and it looks

that

...

only a content-type of application/sdp is accepted.

this was discussed a couple of days ago and there is already a tracker item opened for it.

-- juha

Hi, Pascal...

I opened the tracker... I also would like to have the fix applied to Kamailio, but as Daniel asked to open it on SR (http://lists.kamailio.org/pipermail/users/2009-June/023707.html), I opened there.

It seems that most/all programming force is concentrated on SR development.

As a workaround that I personally didn't try, is to use Mediaproxy, as suggested by Juha at the end of the mentioned thread (http://lists.kamailio.org/pipermail/users/2009-June/023706.html).

Edson.

Pascal Maugeri escreveu:

I found the tracker in sip-router but nothing in Kamailio. Does it mean that this is a fix that will be applied only to sip-router module ? -pascal

On Fri, Jun 19, 2009 at 1:35 PM, Juha Heinanen <jh@tutpro.com mailto:jh@tutpro.com> wrote:

Pascal Maugeri writes:

 > I was checking the nathelper source code (nhelpr_func.c) and it
looks that
 > only a content-type of application/sdp is accepted.

this was discussed a couple of days ago and there is already a tracker
item opened for it.

-- 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

2009/6/19 Pascal Maugeri pascal.maugeri@gmail.com:

I think it is useless I try mediaproxy (instead of rtpproxy) because the error comes from NATHelper module.

I don't understand why you say that. Media proxy doesn't use nathelper module, but Kamailio "mediaproxy" module.

On Freitag, 19. Juni 2009, Pascal Maugeri wrote:

...

I opened the tracker... I also would like to have the fix applied to Kamailio, but as Daniel asked to open it on SR ( http://lists.kamailio.org/pipermail/users/2009-June/023707.html), I opened there.

It seems that most/all programming force is concentrated on SR development.

This is pretty bad news!

Hi Pascal,

of course bugs are still back-ported, as you can see in the repository, also for older branches like 1.3 and 1.4. It would be more correct to say that _new_ programming happens now in the sr repository. And then of course all functionality (like modules and such) of kamailio will be available in the next sip-router release.

Henning

Edson - Lists writes:

About the workaround suggested by Juha, maybe I misunderstand his e-mail and he twicked a local copy and didn't post the changes on SVN...

there are two separate issues here related to multipart/mixed.

one is nathelper/mediaproxy module related and the other relates to textops/filter_body function.

mediaproxy module's use_mediaproxy() function can extract application/sdp bodypart both in k 1.5 and sr.

textops/filter_body function is able to leave out all other bodyparts except the one given as argument, but boundary string is properly extracted from Content-type param only in sr.

-- juha

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.

-- juha

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@gmail.comwrote:

On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen jh@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

If I understood correctly you want me to test the patch nhelpr_func.c you've done in sr in kamailio ? This is what I've done and at least it compiles :-)

(I also tried to compile sr, but I need to sudy it a bit more as I've never installed sr so far)

Nevertheless, the ouput payload is wrong:

Content-Type: application/sdp

v=0 o=- 3454665275 3454665275 IN IP4 10.1.1.248 s=pjmedia c=IN IP4 88.29.163.14288.29.163.142 t=0 0 a=X-nat:0 m=audio 5191251912 RTP/AVP 115 [...] m=application 4198041980 udp TBCP

The RTP and RTCP ports are wrong: 5191251912 and 4198041980 ?!

Where could I have a look in nathelper source to see what is wrong ?

-pascal

On Mon, Jun 22, 2009 at 11:36 AM, Daniel-Constantin Mierla < miconda@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=1f41271e...

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@gmail.commailto: pascal.maugeri@gmail.com> wrote:

On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen <jh@tutpro.com mailto:jh@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@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/

Yes, you're right. Sorry for that. -pascal

On Mon, Jun 22, 2009 at 1:52 PM, Daniel-Constantin Mierla <miconda@gmail.com

wrote:

On 06/22/2009 01:46 PM, Pascal Maugeri wrote:

...

If I understood correctly you want me to test the patch nhelpr_func.c you've done in sr in kamailio ? This is what I've done and at least it compiles :-)

(I also tried to compile sr, but I need to sudy it a bit more as I've never installed sr so far)

Nevertheless, the ouput payload is wrong:

Content-Type: application/sdp

v=0 o=- 3454665275 3454665275 IN IP4 10.1.1.248 s=pjmedia c=IN IP4 88.29.163.14288.29.163.142 t=0 0 a=X-nat:0 m=audio 5191251912 RTP/AVP 115 [...] m=application 4198041980 udp TBCP

The RTP and RTCP ports are wrong: 5191251912 and 4198041980 ?!

Where could I have a look in nathelper source to see what is wrong ?

it seems you call force_rtp_rpoxy() twice, as you get the port two times as well as the ip address. Check your config.

Cheers, Daniel

...

-pascal

On Mon, Jun 22, 2009 at 11:36 AM, Daniel-Constantin Mierla < miconda@gmail.com mailto:miconda@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=1f41271e...

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@gmail.com <mailto:pascal.maugeri@gmail.com>
   <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>> wrote:



      On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen
   <jh@tutpro.com <mailto:jh@tutpro.com>
      <mailto:jh@tutpro.com <mailto:jh@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@lists.kamailio.org <mailto:Users@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/

-- Daniel-Constantin Mierla http://www.asipto.com/

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@gmail.com mailto:miconda@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@gmail.com <mailto:pascal.maugeri@gmail.com>
    <mailto:pascal.maugeri@gmail.com
    <mailto:pascal.maugeri@gmail.com>>> wrote:



       On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen
    <jh@tutpro.com <mailto:jh@tutpro.com>
       <mailto:jh@tutpro.com <mailto:jh@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@lists.kamailio.org <mailto:Users@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

This bug is fixed now with your patch Daniel! Thank you, I go ahead with my testing Cheers, Pascal

On Mon, Jun 22, 2009 at 5:34 PM, Daniel-Constantin Mierla <miconda@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=caef5ace...

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@gmail.com mailto:miconda@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=1f41271e...

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@gmail.com <mailto:pascal.maugeri@gmail.com>
   <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>> wrote:



      On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen
   <jh@tutpro.com <mailto:jh@tutpro.com>
      <mailto:jh@tutpro.com <mailto:jh@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@lists.kamailio.org <mailto:Users@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@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/

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@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@gmail.com mailto:miconda@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=caef5ace...

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@gmail.com <mailto:miconda@gmail.com>
       <mailto:miconda@gmail.com <mailto:miconda@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=1f41271e...

          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@gmail.com
       <mailto:pascal.maugeri@gmail.com>
       <mailto:pascal.maugeri@gmail.com
       <mailto:pascal.maugeri@gmail.com>>
              <mailto:pascal.maugeri@gmail.com
       <mailto:pascal.maugeri@gmail.com>
              <mailto:pascal.maugeri@gmail.com
       <mailto:pascal.maugeri@gmail.com>>>> wrote:



                 On Fri, Jun 19, 2009 at 9:13 PM, Juha Heinanen
              <jh@tutpro.com <mailto:jh@tutpro.com>
       <mailto:jh@tutpro.com <mailto:jh@tutpro.com>>
                 <mailto:jh@tutpro.com <mailto:jh@tutpro.com>
       <mailto:jh@tutpro.com <mailto:jh@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@lists.kamailio.org
       <mailto:Users@lists.kamailio.org>
       <mailto:Users@lists.kamailio.org
       <mailto:Users@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@lists.kamailio.org <mailto:Users@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@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/

Hi

We managed to have our solution to work perfectly behind NAT. And I thank you all for your help and *very* insteresting emails.

Daniel: So far I haven't found any other bug in NATHelper module on supporting multpart payloads. Could you please backport NATHelper from sip-router to kamailio ?

Cheers Pascal

On Tue, Jun 23, 2009 at 12:01 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:

Hi Pascal,

you are right, a stupid bug introduced with the support for the multipart. I committed to the git repo.

Thanks, Daniel

On 06/23/2009 11:55 AM, Pascal Maugeri wrote:

...

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@gmail.com mailto:miconda@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@gmail.com <mailto:miconda@gmail.com>
   <mailto:miconda@gmail.com <mailto:miconda@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=caef5ace...

      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@gmail.com <mailto:miconda@gmail.com>
   <mailto:miconda@gmail.com <mailto:miconda@gmail.com>>
              <mailto:miconda@gmail.com
   <mailto:miconda@gmail.com> <mailto:miconda@gmail.com
   <mailto:miconda@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=1f41271e...

                 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@gmail.com
   <mailto:pascal.maugeri@gmail.com>
              <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>
              <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>
              <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>>
                     <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>
              <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>
                     <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>
              <mailto:pascal.maugeri@gmail.com
   <mailto:pascal.maugeri@gmail.com>>>>> wrote:



                        On Fri, Jun 19, 2009 at 9:13 PM, Juha
   Heinanen
                     <jh@tutpro.com <mailto:jh@tutpro.com>
   <mailto:jh@tutpro.com <mailto:jh@tutpro.com>>
              <mailto:jh@tutpro.com <mailto:jh@tutpro.com>
   <mailto:jh@tutpro.com <mailto:jh@tutpro.com>>>
                        <mailto:jh@tutpro.com
   <mailto:jh@tutpro.com> <mailto:jh@tutpro.com
   <mailto:jh@tutpro.com>>
              <mailto:jh@tutpro.com <mailto:jh@tutpro.com>
   <mailto:jh@tutpro.com <mailto:jh@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@lists.kamailio.org
   <mailto:Users@lists.kamailio.org>
              <mailto:Users@lists.kamailio.org
   <mailto:Users@lists.kamailio.org>>
              <mailto:Users@lists.kamailio.org
   <mailto:Users@lists.kamailio.org>
              <mailto:Users@lists.kamailio.org
   <mailto:Users@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@lists.kamailio.org
   <mailto:Users@lists.kamailio.org>
   <mailto:Users@lists.kamailio.org
   <mailto:Users@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@lists.kamailio.org <mailto:Users@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/

-- Daniel-Constantin Mierla http://www.asipto.com/

On Mon, Jun 22, 2009 at 11:36 AM, Juha Heinanen jh@tutpro.com wrote:

Pascal Maugeri writes:

...

I tried to install mediaproxy but it looks tricky to install (many dependencies, including kernel specific configurations) :-(

i don't know about those. i just use mediaproxy debian package.

right I see that debian is the "standard" way to run mediaproxy. It might be possible to install it on FC but you have make sure kernel has the correct config, install/compile dependencies, etc.

...

and I would like to stick to rtpproxy for performance reason.

this is not a valid reason, because current mediaproxy uses linux kernel to forward the packages and it is hard to do more efficiently.

Good point.

-pascal

-- juha

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.

There is also the often unacknowledged but nevertheless significant fact that AG Projects' political alignment is much closer with the OpenSIPS camp and that support for mediaproxy <-> Kamailio is, as far as I can tell, a secondary concern at best for AG. At the same time, the Kamailio leadership appears to have much more perspective and standardisation on rtpproxy, as well as whatever RTP forwarding module is being lifted from IPTel.org for SIP-Router.

At the same time, it is not entirely clear to me that rtpproxy offers a performance benefit. Although it is small, lightweight and written in C, it is subject to the constraints of userspace scheduling. MediaProxy 2.0 uses API hooks into the kernel's IP forwarding subsystem, which could potentially yield a performance benefit. I don't know that any attempts have been made to undertake a comparative study to determine this.

Daniel-Constantin Mierla wrote:

Hello,

On 06/22/2009 11:37 AM, Alex Balashov wrote:

...

[...]At the same time, the Kamailio leadership appears to have much more perspective and standardisation on rtpproxy, as well as whatever RTP forwarding module is being lifted from IPTel.org for SIP-Router.

rtpproxy does more now than packet forwarding (e.g., playing audio, moh, repacketization ...), therefore needs to stay in user space, see: http://www.rtpproxy.org.

I did not mean to suggest that it is a liability of rtpproxy that it is implemented in userspace.

Someone does need to do a study to see if kernel vs. userspace forwarding really makes that much of a difference, though. I suspect that although it does make a difference, it is not nearly as much of a difference as is commonly thought.

Perhaps I will do this study at Evariste and publish the results. The problem is I do not know of a good load-testing tool that generates bidirectional media. There is SIPP, but it is good for signaling and, at best, instantiating one-way media flows only, and also has the problem of making the far-end endpoint the limiting factor. Is it possible to set up SIPP or something like it (open source?) on two endpoints and make them set up calls between themselves with media in both directions?

On 06/22/2009 01:25 PM, Alex Balashov wrote:

Daniel-Constantin Mierla wrote:

...

Hello,

On 06/22/2009 11:37 AM, Alex Balashov wrote:

...

[...]At the same time, the Kamailio leadership appears to have much more perspective and standardisation on rtpproxy, as well as whatever RTP forwarding module is being lifted from IPTel.org for SIP-Router.

rtpproxy does more now than packet forwarding (e.g., playing audio, moh, repacketization ...), therefore needs to stay in user space, see: http://www.rtpproxy.org.

I did not mean to suggest that it is a liability of rtpproxy that it is implemented in userspace.

Someone does need to do a study to see if kernel vs. userspace forwarding really makes that much of a difference, though. I suspect that although it does make a difference, it is not nearly as much of a difference as is commonly thought.

i think the same, although I haven't tested, rtpproxy is enough so far and can have many instances load balanced from kamailio nathelper module.

What I wanted to point out, is that nathelper is now more than rtp packages relayer and for that being in user space is necessary. When someone is looking at performances, iptrtpproxy module is another option using kernel space (whatever that makes any difference or not).

Cheers, Daniel

Perhaps I will do this study at Evariste and publish the results. The problem is I do not know of a good load-testing tool that generates bidirectional media. There is SIPP, but it is good for signaling and, at best, instantiating one-way media flows only, and also has the problem of making the far-end endpoint the limiting factor. Is it possible to set up SIPP or something like it (open source?) on two endpoints and make them set up calls between themselves with media in both directions?

Hello,

On 06/24/2009 10:09 PM, Andreas Granig wrote:

Hi,

...

Someone does need to do a study to see if kernel vs. userspace forwarding really makes that much of a difference, though. I suspect that although it does make a difference, it is not nearly as much of a difference as is commonly thought.

We did a benchmark (only cpu usage for now) comparing the standard rtpproxy with mediaproxy-ng, a proprietary implementation of Sipwise (implemented as iptables module based on the mediaproxy dispatcher protocol). The results should be pretty equal for mediaproxy2 and iptrtpproxy as well, although I don't know anything about their design.

http://pub.sipwise.com/OpenSER.rtpproxy.benchmark.2009.06.24.pdf

The machine is a Dual-CPU Intel(R) Xeon(TM) CPU 2.80GHz with 2GB of RAM. Test-Setup is done with sipp (rtp is sent via pre-recorded pcap and echoed via "-rtp-echo" option on UAS).

Some observations we found:

• rtpproxy seems to not take advantage of SMP

it is well known, but you can run one or two instances per core and load balance from the nathelper module. I usually start 2 per cpu core.

Cheers, Daniel

• jitter is reduced in mediaproxy-ng compared to rtpproxy because

socket polling is eliminated in kernel

• delay is reduced in kernel-space due to elimination of context

switching

• the peaks in mediaproxy-ng are a result of the mediaproxy-ng design

(relaying is done in user-space until all ip/port information is available by receiving rtp packets from both sides, besides some other processing like packet inspection etc. [although cpu usage can be lowered even more by further optimizing the userspace part])

Andreas

---

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

Hi Daniel,

...

Some observations we found:

• rtpproxy seems to not take advantage of SMP

it is well known, but you can run one or two instances per core and load balance from the nathelper module. I usually start 2 per cpu core.

I agree, but IMHO it's not that well known that you should do that.

However it was all about the question, if a kernel-based module would perform better than a user-based daemon (in a "standard" setup).

There are performance metrics that speak for kernel-based media relays (e.g. delay and jitter). It is a matter of what you expect from your media relay to do beside rtp relay (like media forking [LI?], call recording etc.).

Btw, we are preparing an OpenSource-Version of the mediaproxy-ng (taking into account that LI is going to be a "must-have" requirement in SIP deployments), but mediaproxy dispatcher changed its interface towards mediaproxy2, so we're currently evaluating different approaches (going with mediaproxy/dispatcher or rtpproxy protocol)... we'll keep you updated...

Andreas

On Wednesday 24 June 2009 22:23:27 Iñaki Baz Castillo wrote:

El Miércoles, 24 de Junio de 2009, Andreas Granig escribió:

...

There are performance metrics that speak for kernel-based media relays (e.g. delay and jitter). It is a matter of what you expect from your media relay to do beside rtp relay (like media forking [LI?], call recording etc.).

"Media forking"? what is it?

I think he is speaking about LAW requirements about call-recording/call-interception

On Jun 25, 2009, at 12:24 AM, Iñaki Baz Castillo wrote:

El Jueves, 25 de Junio de 2009, Raúl Alexis Betancor Santana escribió:

...

I think he is speaking about LAW requirements about call-recording/call-interception

And why is forking required for that? if the audio goes through a rtpproxy, why is it required to fork it? why doesn't the recording take place in the same host?

Because not every country allows telecom operators to record to WAV files on a generic machine and email/ftp/whatever every single file once a day to the authorities. Usually they want "realtime" access and in those cases you want to fork the media (and the signalling probably, I don't know for sure).

Andreas Sikkema wrote:

On Jun 25, 2009, at 12:24 AM, Iñaki Baz Castillo wrote:

...

El Jueves, 25 de Junio de 2009, Raúl Alexis Betancor Santana escribió:

...

I think he is speaking about LAW requirements about call-recording/call-interception

And why is forking required for that? if the audio goes through a rtpproxy, why is it required to fork it? why doesn't the recording take place in the same host?

Because not every country allows telecom operators to record to WAV files on a generic machine and email/ftp/whatever every single file once a day to the authorities. Usually they want "realtime" access and in those cases you want to fork the media (and the signalling probably, I don't know for sure).

Exactly. There are countries requiring for example "PacketCable Event Messages" compliant messages sent to LEA. Beside that, also corresponding media has to be handed over. Just as an example.

This is a fact we unfortunately have to live with, no matter if OpenSER, Kamailio, or Nortel CS2k or whatever is deployed...

Andreas

Alex Balashov wrote:

Daniel-Constantin Mierla wrote:

...

Hello,

On 06/22/2009 11:37 AM, Alex Balashov wrote:

...

[...]At the same time, the Kamailio leadership appears to have much more perspective and standardisation on rtpproxy, as well as whatever RTP forwarding module is being lifted from IPTel.org for SIP-Router.

rtpproxy does more now than packet forwarding (e.g., playing audio, moh, repacketization ...), therefore needs to stay in user space, see: http://www.rtpproxy.org.

I did not mean to suggest that it is a liability of rtpproxy that it is implemented in userspace.

Someone does need to do a study to see if kernel vs. userspace forwarding really makes that much of a difference, though. I suspect that although it does make a difference, it is not nearly as much of a difference as is commonly thought.

Perhaps I will do this study at Evariste and publish the results. The problem is I do not know of a good load-testing tool that generates bidirectional media. There is SIPP, but it is good for signaling and, at best, instantiating one-way media flows only, and also has the problem of making the far-end endpoint the limiting factor. Is it possible to set up SIPP or something like it (open source?) on two endpoints and make them set up calls between themselves with media in both directions?

There is pjsip-perf, but I do not know if it supports RTP too.

klaus