headers
Sammy Govind | 1 Dec 2011 08:01
Picon

Re: [SR-Users] CANCEL not matching INVITES !

Hey Daniel, 


I've exactly followed your point, I'll try some stuff on asterisk server to stop asking for 401 Auth to Kamailio., maybe this will eliminate the need for another INVITE with authentication params.

But one thing which just makes me curious is that a soft phone directly coming from a Public IP is always able to successfully CANCEL the call.

Anyway I'll use some brain of mine on this and let you know what resolved it, or what I'm missing.

Thanks,
Sammy

On Wed, Nov 30, 2011 at 5:47 PM, Daniel-Constantin Mierla <miconda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hello,

is the SIP trace complete?

What I could find inside is:
- invite from phone to kamailio
- kamailio asks for authentication - 407
- ack
- invite with credentials, kamailio forwards to asterisk
- asterisk asks for authentication - 401
- ack
- there is no new INVITE with credentials for kamailio and asterisk
- but the phone starts sending CANCELs -- since there is no active INVITE transaction, kamailio just drops it due to config rules
- after a while asterisk starts sending like 180 ringing, then 200ok ... really strange

Maybe you haven't captured all the sip traffic. If you want to use ngrep, do on kamailio server:


ngrep -d any -qt -W byline port 5060

If that's all the traffic, then xlite and asterisk seems to have some bugs - both were aware of 401 reply (asterisk generated it, xlite sent the ACK for it) -- so no ongoing call to CANCEL by xlite, or to answer by Asterisk (the 180, 200 replies).

From kamailio point of view, if there is no INVITE following the 401 reply to xlite, there is no active invite transaction to cancel.

Cheers,
Daniel


On 11/30/11 12:02 AM, Daniel-Constantin Mierla wrote:
Hello,

I will look over it soon - since you sent pcap I couldn't look at it directly from the email. ngrep outputs plain text which is easy to read from email, the reason I am asking mainly for ngrep traces since many times I am not around a computer where is convenient to open pcap file. On the other hand, if it is a transmission problem (at transport layer), pcap file is better.

Cheers,
Daniel

On 11/29/11 5:07 AM, Sammy Govind wrote:
Hello again,

Please see the attached wireshark trace, I tried for a sipgrep trace but couldn't somehow. I hope this will get me some clue on what I'm doing wrong.

This is a setup with Kamailio in front of Asterisk Servers. Kamailio is multihomed and MS are on private IPs, all the calls are routed to MSs and then comeback for further dial-outs.

Please see the Continuous CANCEL requests which aren't terminating the call.

Thanks,
Sammy.

On Mon, Nov 28, 2011 at 4:41 PM, Sammy Govind <govoiper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Thanks for your reply I will attach the wireshark traces as soon as I get to my workstation.

BR,
Sammy.


On Mon, Nov 28, 2011 at 3:33 PM, Daniel-Constantin Mierla <miconda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hello,

send the ngrep trace of such call, from the initial INVITE, you can use:

ngrep -d any -qt -W byline port 5060

The sip trace will help to see what is wrong with that CANCEL.

Cheers,
Daniel


On 11/28/11 7:19 AM, Sammy Govind wrote:
Anyone please help.

On Sat, Nov 26, 2011 at 10:39 PM, Sammy Govind <govoiper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hello list,

I'm using Kamailio 3.1.5 in front of asterisk servers. Kamailio handles all the SIP registrations. Calls from SIP phones are forwarded to asterisks and then dialled out to Kamailio.

root <at> SBCserver:~# kamailio -V
version: kamailio 3.1.5 (x86_64/linux) 76fff5
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 76fff5
compiled on 08:21:33 Oct 27 2011 with gcc 4.6.1
root <at> SBCserver:~#


Problem: 
When call is initiated from a softphone and is in ringing phase, CANCEL just don't work. I've done some initial debugging and the following piece of code in main route is failing.

# CANCEL processing
if (is_method("CANCEL"))
{
     xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) ---CAPTURED IN MAIN---\n");
     if (t_check_trans()){
        t_relay();
        xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) ---CHECK TRANS TRUE---\n");
     }
     xlog("L_NOTICE","$rm from $fu (IP:$si:$sp) ---CHECK TRANS FALSE---\n");
     exit;
}

Also the CANCEL fails the has_totag() condition !

The same Call CANCEL scenario works fine for any client on Public IP !

Hope to get some pointers for the solution.

Regards,
Sammy.



_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users <at> lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda




_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users <at> lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users <at> lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda 

<div>
<p>Hey Daniel,&nbsp;</p>
<div><br></div>
<div>I've exactly followed your point, I'll try some stuff on asterisk server to stop asking for 401 Auth to Kamailio., maybe this will eliminate the need for another INVITE with authentication params.</div>
<div>
<br><div>But one thing which just makes me curious is that a soft phone directly coming from a Public IP is always able to successfully CANCEL the call.</div>
<div><br></div>
<div>Anyway&nbsp;I'll use some brain of mine on this and let you know what resolved it, or what I'm missing.</div>
<div><br></div>
<div>Thanks,</div>
<div>Sammy<br><br><div class="gmail_quote">On Wed, Nov 30, 2011 at 5:47 PM, Daniel-Constantin Mierla <span dir="ltr">&lt;<a href="mailto:miconda@...">miconda@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

    

  <div bgcolor="#FFFFFF" text="#000000">
    Hello,<br><br>
    is the SIP trace complete?<br><br>
    What I could find inside is:<br>
    - invite from phone to kamailio<br>
    - kamailio asks for authentication - 407<br>
    - ack<br>
    - invite with credentials, kamailio forwards to asterisk<br>
    - asterisk asks for authentication - 401<br>
    - ack<br>
    - there is no new INVITE with credentials for kamailio and asterisk<br>
    - but the phone starts sending CANCELs -- since there is no active
    INVITE transaction, kamailio just drops it due to config rules<br>
    - after a while asterisk starts sending like 180 ringing, then 200ok
    ... really strange<br><br>
    Maybe you haven't captured all the sip traffic. If you want to use
    ngrep, do on kamailio server:<div class="im">
<br><br>
    ngrep -d any -qt -W byline port 5060<br><br>
</div>
    If that's all the traffic, then xlite and asterisk seems to have
    some bugs - both were aware of 401 reply (asterisk generated it,
    xlite sent the ACK for it) -- so no ongoing call to CANCEL by xlite,
    or to answer by Asterisk (the 180, 200 replies).<br><br>
    From kamailio point of view, if there is no INVITE following the 401
    reply to xlite, there is no active invite transaction to cancel.<br><br>
    Cheers,<br>
    Daniel<div><div class="h5">
<br><br>
    On 11/30/11 12:02 AM, Daniel-Constantin Mierla wrote:
    <blockquote type="cite">

      Hello,<br><br>
      I will look over it soon - since you sent pcap I couldn't look at
      it directly from the email. ngrep outputs plain text which is easy
      to read from email, the reason I am asking mainly for ngrep traces
      since many times I am not around a computer where is convenient to
      open pcap file. On the other hand, if it is a transmission problem
      (at transport layer), pcap file is better.<br><br>
      Cheers,<br>
      Daniel<br><br>
      On 11/29/11 5:07 AM, Sammy Govind wrote:
      <blockquote type="cite">Hello again,
        <div><br></div>
        <div>Please see the attached wireshark trace, I tried for a
          sipgrep trace but couldn't somehow. I hope this will get me
          some clue on what I'm doing wrong.</div>
        <div><br></div>
        <div>This is a setup with Kamailio in front of Asterisk Servers.
          Kamailio is multihomed and MS are on private IPs, all the
          calls are routed to MSs and then comeback for further
          dial-outs.</div>
        <div><br></div>
        <div>Please see the Continuous CANCEL requests which aren't
          terminating the call.</div>
        <div><br></div>
        <div>Thanks,</div>
        <div>Sammy.</div>
        <div><br></div>
        <div>
          <div class="gmail_quote">On Mon, Nov 28, 2011 at 4:41 PM,
            Sammy Govind <span dir="ltr">&lt;<a href="mailto:govoiper <at> gmail.com" target="_blank">govoiper@...</a>&gt;</span>
            wrote:<br><blockquote class="gmail_quote">Thanks
              for your reply I will attach the wireshark traces as soon
              as I get to my workstation.
              <div><br></div>
              <div>BR,</div>
              <div>Sammy.
                <div>
                  <div>
<br><br><div class="gmail_quote">On Mon, Nov 28, 2011 at
                      3:33 PM, Daniel-Constantin Mierla <span dir="ltr">&lt;<a href="mailto:miconda@..." target="_blank">miconda@...</a>&gt;</span>
                      wrote:<br><blockquote class="gmail_quote">
                        <div bgcolor="#FFFFFF" text="#000000"> Hello,<br><br>
                          send the ngrep trace of such call, from the
                          initial INVITE, you can use:<br><br>
                          ngrep -d any -qt -W byline port 5060<br><br>
                          The sip trace will help to see what is wrong
                          with that CANCEL.<br><br>
                          Cheers,<br>
                          Daniel
                          <div>
                            <div>
<br><br>
                              On 11/28/11 7:19 AM, Sammy Govind wrote: </div>
                          </div>
                          <blockquote type="cite">
                            <div>
                              <div>Anyone please help.<br><br><div class="gmail_quote">On Sat, Nov 26,
                                  2011 at 10:39 PM, Sammy Govind <span dir="ltr">&lt;<a href="mailto:govoiper@..." target="_blank">govoiper@...</a>&gt;</span>
                                  wrote:<br><blockquote class="gmail_quote"> Hello list,
                                    <div><br></div>
                                    <div>I'm using Kamailio 3.1.5 in
                                      front of asterisk servers.
                                      Kamailio handles all the SIP
                                      registrations. Calls from SIP
                                      phones are forwarded to asterisks
                                      and then dialled out to Kamailio.</div>
                                    <div><br></div>
                                    <div>
                                      <div>root <at> SBCserver:~#
                                          kamailio -V</div>
                                      <div>version: kamailio
                                          3.1.5 (x86_64/linux) 76fff5</div>
                                      <div>flags: STATS: Off,
                                          USE_IPV6, USE_TCP, USE_TLS,
                                          TLS_HOOKS, USE_RAW_SOCKS,
                                          DISABLE_NAGLE, USE_MCAST,
                                          DNS_IP_HACK, SHM_MEM,
                                          SHM_MMAP, PKG_MALLOC,
                                          DBG_QM_MALLOC, USE_FUTEX,
                                          FAST_LOCK-ADAPTIVE_WAIT,
                                          USE_DNS_CACHE,
                                          USE_DNS_FAILOVER, USE_NAPTR,
                                          USE_DST_BLACKLIST,
                                          HAVE_RESOLV_RES</div>
                                      <div>ADAPTIVE_WAIT_LOOPS=1024,

                                          MAX_RECV_BUFFER_SIZE 262144,
                                          MAX_LISTEN 16, MAX_URI_SIZE
                                          1024, BUF_SIZE 65535, PKG_SIZE
                                          4MB</div>
                                      <div>poll method
                                          support: poll, epoll_lt,
                                          epoll_et, sigio_rt, select.</div>
                                      <div>id: 76fff5</div>
                                      <div>compiled on
                                          08:21:33 Oct 27 2011 with gcc
                                          4.6.1</div>
                                      <div>root <at> SBCserver:~#</div>
                                      <div><br></div>
                                      <div><br></div>
                                    </div>
                                    <div>Problem:&nbsp;</div>
                                    <div>When call is initiated from a
                                      softphone and is in ringing phase,
                                      CANCEL just don't work. I've done
                                      some initial debugging and
                                      the&nbsp;following&nbsp;piece of code in
                                      main route is failing.</div>
                                    <div><br></div>
                                    <div>
                                      <div># CANCEL processing</div>
                                      <div>if
                                          (is_method("CANCEL"))</div>
                                      <div>{</div>
                                      <div>&nbsp; &nbsp;
                                          &nbsp;xlog("L_NOTICE","$rm from $fu
                                          (IP:$si:$sp) ---CAPTURED IN
                                          MAIN---\n");</div>
                                      <div>&nbsp; &nbsp; &nbsp;if
                                          (t_check_trans()){</div>
                                      <div>&nbsp; &nbsp; &nbsp; &nbsp; t_relay();</div>
                                      <div>&nbsp; &nbsp; &nbsp; &nbsp;
                                          xlog("L_NOTICE","$rm from $fu
                                          (IP:$si:$sp) ---CHECK TRANS
                                          TRUE---\n");</div>
                                      <div>&nbsp; &nbsp; &nbsp;}</div>
                                      <div>&nbsp; &nbsp;
                                          &nbsp;xlog("L_NOTICE","$rm from $fu
                                          (IP:$si:$sp) ---CHECK TRANS
                                          FALSE---\n");</div>
                                      <div><span>&nbsp; &nbsp; &nbsp;exit;</span></div>
                                      <div>}</div>
                                    </div>
                                    <div><br></div>
                                    <div>Also the CANCEL fails the
                                      has_totag() condition !</div>
                                    <div><br></div>
                                    <div>The same Call CANCEL scenario
                                      works fine for any client on
                                      Public IP !</div>
                                    <div><br></div>
                                    <div>Hope to get some pointers for
                                      the solution.</div>
                                    <div><br></div>
                                    <div>Regards,</div>
                                    <div>Sammy.</div>
                                  </blockquote>
                                </div>
                                <br><br><br>
</div>
                            </div>
                            _______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@..." target="_blank">sr-users <at> lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><span>
</span>
                            <span> </span>
</blockquote>
                          <span> <br>-- 
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a>
                            </span>
</div>
                      </blockquote>
                    </div>
                    <br>
</div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
</div>
        <br><br>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@..." target="_blank">sr-users <at> lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
      </blockquote>
      <br>-- 
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a>
      <br><br>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@..." target="_blank">sr-users <at> lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>

    </blockquote>
    <br>-- 
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a>
  </div></div>
</div>

</blockquote>
</div>
<br>
</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 09:28
Picon

[SR-Users] preparing to release v3.2.1

Hello,

the plan is to start packaging of v3.2.1 after 14:00GMT. If anyone has 
anything elst to commit to branch 3.2 to be in v3.2.1, please do it 
before, afterwards write me an email first to synchronize and avoid git 
conflicts.

Cheers,
Daniel

--

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Permalink | Reply | 0 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 13:07
Picon

Re: [SR-Users] Monitoring inquiry

Hello,

On 11/30/11 9:16 PM, Jenkins, Rachel wrote:

I have a couple questions as it relates to monitoring a Kamailio SIP Server.

 

1.       Do you have an OID that we can poll via SNMP-GETs to show call completion statistics? Either the % of completion or the accepting/connecting statistics. If you do not have an OID, do you have a syslog or trap message that can be generated?

the snmpstats module exports the statistics of the dialog module, which counts completed calls, failed calls, a.s.o.

You can get the statistics also via MI or RPC control interface, for example with kamctl:

kamctl fifo get_statistics all


2.       Do you have an OID that we can poll to get a list errors that were generated? Ex-OID for a 408 or 503. If not, is there a syslog or trap?


There are internal statistics for classes of reply codes and also to some very common ones -- you can get them in the same way, via mi/rpc or snmpstats.

3.       Can you recommend a way to view the MOS score – possible hardware tap on network to get MOS?


Never worked with such thing, maybe someone else can help.

Cheers,
Daniel

 

Thanks in advance

 



This email may contain proprietary and confidential information for the sole use of the intended recipient.
Any review, retransmission, dissemination, or other use of this information by persons or entities other than
the intended recipient is prohibited. If you are not the intended recipient, please contact the sender and
delete all copies. To the extent that opinions are expressed in this message, they are not necessarily the
opinions of Sentinel Technologies or any of its affiliates, employees, directors, officers or shareholders.

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+b@public.gmane.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda 
<div>
    Hello,<br><br>
    On 11/30/11 9:16 PM, Jenkins, Rachel wrote:
    <blockquote cite="mid:42641777B1E0DC459BD2C6C218CCBEC891AF@..." type="cite">
      <div class="WordSection1">
        <p class="MsoNormal">I have a couple questions as it relates to
          monitoring a Kamailio SIP Server.
          <p></p></p>
        <p class="MsoNormal"><p>&nbsp;</p></p>
        <p class="MsoListParagraph"><span>1.<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            </span></span><span>Do
            you have an OID that we can poll via SNMP-GETs to show call
            completion statistics? Either the % of completion or the
            accepting/connecting statistics. If you do not have an OID,
            do you have a syslog or trap message that can be generated?</span></p>
      </div>
    </blockquote>
    the snmpstats module exports the statistics of the dialog module,
    which counts completed calls, failed calls, a.s.o.<br><br>
    You can get the statistics also via MI or RPC control interface, for
    example with kamctl:<br><br>
    kamctl fifo get_statistics all<br><br><br><blockquote cite="mid:42641777B1E0DC459BD2C6C218CCBEC891AF@..." type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"><span><p></p></span></p>
        <p class="MsoListParagraph"><span>2.<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            </span></span><span>Do
            you have an OID that we can poll to get a list errors that
            were generated? Ex-OID for a 408 or 503. If not, is there a
            syslog or trap?
          </span></p>
      </div>
    </blockquote>
    <br>
    There are internal statistics for classes of reply codes and also to
    some very common ones -- you can get them in the same way, via
    mi/rpc or snmpstats.<br><br><blockquote cite="mid:42641777B1E0DC459BD2C6C218CCBEC891AF@..." type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"><span><p></p></span></p>
        <p class="MsoListParagraph"><span>3.<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            </span></span><span>Can
            you recommend a way to view the MOS score &ndash; possible
            hardware tap on network to get MOS?
          </span></p>
      </div>
    </blockquote>
    <br>
    Never worked with such thing, maybe someone else can help.<br><br>
    Cheers,<br>
    Daniel<br><br><blockquote cite="mid:42641777B1E0DC459BD2C6C218CCBEC891AF@..." type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"><span><p></p></span></p>
        <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
        <p class="MsoNormal"><span>Thanks in advance<p></p></span></p>
        <p class="MsoNormal"><p>&nbsp;</p></p>
      </div>
      <br><br>
        This email may contain proprietary and confidential information
        for the sole use of the intended recipient. <br>
        Any review, retransmission, dissemination, or other use of this
        information by persons or entities other than <br>
        the intended recipient is prohibited. If you are not the
        intended recipient, please contact the sender and <br>
        delete all copies. To the extent that opinions are expressed in
        this message, they are not necessarily the <br>
        opinions of Sentinel Technologies or any of its affiliates,
        employees, directors, officers or shareholders.
      <br><br>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@...">sr-users@...</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>

    </blockquote>
    <br>-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a>
  </div>
Permalink | Reply | 4 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 13:12
Picon

Re: [SR-Users] dialog table entry not deleted after call if in-dialog requests are challenged

Hello,

I could not spot how dialog traffic is handled, via flag or 
dlg_manage()? The dialog entry should be deleted after the BYE is 
processed. Can you dump the dialog attributes via mi (with kamctl) and 
see what is the state of the dialog after processing the BYE? Also, you 
can try to do dlg_manage() when BYE is received.

Cheers,
Daniel

On 11/30/11 3:36 PM, Yufei Tao wrote:
> Hi
>
> I am using dialog module in Kamailio 3.1.5, and find that the dialog
> table entry does not get deleted after call if in-dialog requests (e.g.
> session timer refresh re-INVITEs in my case) are challenged. The entry
> will stay there and get deleted after a long time (some time out? I
> didn't set any dialog timeouts myself). If I remove the challenge for
> in-dialog requests, then the dialog entry is deleted right after the call.
>
> I use the example config script with a bit of modification for my
> in-dialog route:
>
> route[WITHINDLG] {
>    xlog("L_DBG","WITHINDLG: method=$rm, callid=$ci, cseq=$cs\n");
>
>    if (has_totag() ) {
>      # sequential request withing a dialog should
>      # take the path determined by record-routing
>      if (loose_route()) {
>        # Filter out bad/faked up in-dialog requests.
>        if ( !is_known_dlg() )
>        {
>          xlog("L_WARN","WITHINDLG: NOT known dlg!! method=$rm,
> callid=$ci, cseq=$cs, $fu->$tu\n");
>          exit;
>        }
>
>        if (is_method("BYE")) {
>          xlog("L_DBG","WITHINDLG: BYE found within Dialog \n");
>
>          setflag(FLT_ACC); # do accounting ...
>          setflag(FLT_ACCFAILED); # ... even if the transaction fails
>        }
> ##########################################################
>        # challenge: if not CANCEL/ACK
>        else if ( !is_method("CANCEL")&&  !is_method("ACK") )
>        {
>          route(AUTH);
>        }
> ##########################################################
>        xlog("L_DBG","WITHINDLG: Entering RELAY route from WITHINDLG
> route. \n");
>
>          route(RELAY);
>      } else {
>        if (is_method("SUBSCRIBE")&&  uri == myself) {
>          # in-dialog subscribe requests
>          route(PRESENCE);
>          exit;
>          }
>          if ( is_method("ACK") ) {
>          xlog("L_DBG","WITHINDLG: ACK callid=$ci, cseq=$cs\n");
>
>          if ( t_check_trans() ) {
>            # no loose-route, but stateful ACK;
>            # must be an ACK after a 487
>            # or e.g. 404 from upstream server
>
>            xlog("L_DBG","ACK being relayed\n");
>
>            t_relay();
>            exit;
>          } else {
>            # ACK without matching transaction ... ignore and discard
>            xlog("L_DBG","ACK without matching transaction-ignore and
> discard\n");
>            exit;
>          }
>        }
>        sl_send_reply("404","Not here");
>      }
>      exit;
>    }
> }
>
> The part that calls route(AUTH) that I added was the cause for the
> dialog entry not being deleted after call.
>
> Here are my dialog related settings:
>
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "dlg_flag", 4)
> modparam("dialog", "db_url", DBURL)
> modparam("dialog", "db_update_period", 20) # use short one to catch
> short dlgs (default:60)
> modparam("dialog", "db_mode", 1)
> # don't use did, so to cope with clients that don't preserve parameters
> # and mode 1 (fallback to 3261 matching) didn't work??
> modparam("dialog", "dlg_match_mode", 2)
>
> modparam("dialog", "profiles_no_value", "inbound ; outbound")
> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
>
> # default timeout set to max int 0x07FFFF FFFF
> modparam("dialog", "default_timeout", 2147483647)
>
>
>
> And I set the dialog flag (4) when receiving the initial INVITE.
>
> Any idea why? Am I using the dialog module correctly?
>
> Thanks very much!
>
> Yufei
>
> --
> Yufei Tao
> Red Embedded
>
> This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee.
If you are not the intended addressee please notify the sender by return and delete the message.
>
> You must not disclose, forward or copy this E-mail or attachments to any third party without the prior
consent of the sender.
>
> Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd,
Saltaire, BD17 7EZ
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@...
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Permalink | Reply | 0 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 13:14
Picon

Re: [SR-Users] transport=TLS

Hello,

On 11/30/11 11:59 AM, Bruno Bresciani wrote:
Now I understood why the messagem is forward with UDP protocol... This problem occurs with bria on android plataform, this softphone send the INVITE request with tls protocol specified only on the contact header.

Contact: "XXX" <sip:XXX-TiGPExJhJx2h5xC8fTo+OA@public.gmane.org:YYY;transport=TLS>.

as Daniel pointed out, "The contact header address is not used for routing SIP requests, only Route headers and R-URI addresses"

In this case, I should add the transport protocol TLS on R-URI before to forward message with t_relay function... Correct?
it is not clear for me why you need to forward on TLS if the destination address is not requiring that. Maybe you can draw a diagram showing the call flow, who is on TLS and how is happening at this moment and what you would like to happen.

Cheers,
Daniel


Cheers


2011/11/29 Daniel-Constantin Mierla <miconda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


On 11/29/11 6:24 PM, Bruno Bresciani wrote:
Thank's for attention Andrew

I'm reading the source code of tm module to try understand better this behavior...
I can't understand what meaning that "the outbound proxy address is set"... where I define this address?

Outbound proxy address is stored in an internal structure, it is not part of a SIP request. It represents the address where to send the request, regardless of request URI (r-uri) address. One common use case is when dealing with NAT routers, the r-uri is set to the contact address of the destination phone and the outbound proxy address is set to the NAT router.

From configuration file, you can access it via $du (read and write via assignment operation). There are couple of modules that may set the outbound proxy address, like registrar/usrloc, rr, lcr...

Maybe the best is to post here an ngrep with the SIP trace of such case, that we can see if something is wrong.

Cheers,
Daniel



2011/11/29 Andrew Pogrebennyk <apogrebennyk-is+3NXn99l1BDgjK7y7TUQ@public.gmane.org>
Bruno,
the address from contact header is put into R-URI on outgoing request to
that user. This is where I catch that parameter. I think we should debug
why kamailio sends the request using UDP, it is not clear, as Daniel
pointed out it should work automatically. I think I had to do these
manipulations because in my case the outbound proxy address is set

On 11/29/2011 05:38 PM, Bruno Bresciani wrote:
> In my case the transport=TLS is present in contact header, has the same
> treatment of R-URI?
>
> Cheers


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+b@public.gmane.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+b@public.gmane.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda



_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+b@public.gmane.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda 
<div>
    Hello,<br><br>
    On 11/30/11 11:59 AM, Bruno Bresciani wrote:
    <blockquote cite="mid:CAKv6MrbUKdA5Fx=jxEp=fZ4mZ72TZBfPnBWYYKXnc6Jpaqydbw@..." type="cite">Now I understood why the messagem is forward with UDP
      protocol... This problem occurs with bria on android plataform,
      this softphone send the INVITE request with tls protocol specified
      only on the contact header.<br><br>
      Contact: "XXX" <a class="moz-txt-link-rfc2396E" href="sip:XXX@...:YYY;transport=TLS">&lt;sip:XXX@...:YYY;transport=TLS&gt;</a>.<br><br>
      as Daniel pointed out, "The contact header address is not used for
      routing SIP requests, only Route headers and R-URI addresses"<br><br>
      In this case, I should add the transport protocol TLS on R-URI
      before to forward message with t_relay function... Correct?<br>
</blockquote>
    it is not clear for me why you need to forward on TLS if the
    destination address is not requiring that. Maybe you can draw a
    diagram showing the call flow, who is on TLS and how is happening at
    this moment and what you would like to happen.<br><br>
    Cheers,<br>
    Daniel<br><br><blockquote cite="mid:CAKv6MrbUKdA5Fx=jxEp=fZ4mZ72TZBfPnBWYYKXnc6Jpaqydbw@..." type="cite">
      <br>
      Cheers<br><br><br><div class="gmail_quote">2011/11/29 Daniel-Constantin Mierla <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:miconda@...">miconda@...</a>&gt;</span><br><blockquote class="gmail_quote">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="im"> <br><br>
              On 11/29/11 6:24 PM, Bruno Bresciani wrote:
              <blockquote type="cite">Thank's for attention Andrew<br><br>
                I'm reading the source code of tm module to try
                understand better this behavior... <br>
                I can't understand what meaning that "the outbound proxy
                address is set"... where I define this address? <br>
</blockquote>
              <br>
</div>
            Outbound proxy address is stored in an internal structure,
            it is not part of a SIP request. It represents the address
            where to send the request, regardless of request URI (r-uri)
            address. One common use case is when dealing with NAT
            routers, the r-uri is set to the contact address of the
            destination phone and the outbound proxy address is set to
            the NAT router.<br><br>
            From configuration file, you can access it via $du (read and
            write via assignment operation). There are couple of modules
            that may set the outbound proxy address, like
            registrar/usrloc, rr, lcr...<br><br>
            Maybe the best is to post here an ngrep with the SIP trace
            of such case, that we can see if something is wrong.<br><br>
            Cheers,<br> Daniel
            <div class="im">
<br><blockquote type="cite"> <br><br><div class="gmail_quote">2011/11/29 Andrew Pogrebennyk <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:apogrebennyk@..." target="_blank">apogrebennyk@...</a>&gt;</span><br><blockquote class="gmail_quote"> Bruno,<br>
                    the address from contact header is put into R-URI on
                    outgoing request to<br>
                    that user. This is where I catch that parameter. I
                    think we should debug<br>
                    why kamailio sends the request using UDP, it is not
                    clear, as Daniel<br>
                    pointed out it should work automatically. I think I
                    had to do these<br>
                    manipulations because in my case the outbound proxy
                    address is set<br><div>
<br>
                      On 11/29/2011 05:38 PM, Bruno Bresciani wrote:<br>
                      &gt; In my case the transport=TLS is present in
                      contact header, has the same<br>
                      &gt; treatment of R-URI?<br>
                      &gt;<br>
                      &gt; Cheers<br><br><br>
</div>
                    <div>
                      <div>_______________________________________________<br>
                        SIP Express Router (SER) and Kamailio (OpenSER)
                        - sr-users mailing list<br><a moz-do-not-send="true" href="mailto:sr-users@..." target="_blank">sr-users@...</a><br><a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div>
                    </div>
                  </blockquote>
                </div>
                <br><br><br>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" href="mailto:sr-users@..." target="_blank">sr-users@...</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>

              </blockquote>
              <br>
</div>
            <div class="im">
              -- 
Daniel-Constantin Mierla -- <a moz-do-not-send="true" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a moz-do-not-send="true" href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a moz-do-not-send="true" href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a moz-do-not-send="true" href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a>
            </div>
          </div>
        </blockquote>
      </div>
      <br><br><br>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@...">sr-users@...</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>

    </blockquote>
    <br>-- 
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a>
  </div>
Permalink | Reply | 6 comments |
headers
Olle E. Johansson | 1 Dec 2011 13:19
Gravatar

Re: [SR-Users] Monitoring inquiry


1 dec 2011 kl. 13:07 skrev Daniel-Constantin Mierla:

>> 3.       Can you recommend a way to view the MOS score – possible hardware tap on network to get MOS?
> 
> Never worked with such thing, maybe someone else can help.

As Kamailio doesn't handle media by default, we can not get a MOS.

There are multiple ways, most commercial software duplicate a port in a switch and process a copy of all the
RTP data (provided there's a central point where you can get this).

/O
Permalink | Reply | 0 comments |
headers
Albert Petit | 1 Dec 2011 13:43
Picon

[SR-Users] how approach nathelper when using usrloc db_mode 3?

Hello,


We found an issue when using nat pinger 

Previously our system had 1 Kamailio as entry point and we were using usrloc in mode  2 so:
modparam("usrloc", "db_mode",2)
modparam("usrloc", "db_url",
        "mysql://openser:openserrw <at> <DB_IP>/openser")

On our system we like to use the pinger NAT_HELPER module to keep the connections alive for the users of our system.

 Now we're trying to configure two Kamailio K1 and K2 as entry point of the system and having both of them active at the same time with a virtual IP as common entry point for both. 
I believe this approach requires to flush information on the usrloc immediately because following use case can happen and needs to work:
- A registers on K1 server
- B registers on K2 server
-After 5 seg  B makes an INVITE to A through K2=>  we need K2 kamailio instance to be able to locate A immediately and not wait until the first Kamailio flushes the info to the db. (it looks to be around 20/30 seg by default  on mode 2 I think , correct so this looks to be  too much time)

So to improve this we tried to change to use usrloc in mode 3 instead of mode 2. But then we've a big issue: when enabling the pinger module for NATted users we see  it opens a new connection to the db for each OPTIONS ping we want to send.  That looks too many connections for our MySQL server because for eg if I leave two users registered for 1 hour after some time I start to see errors like:
13(5292) ERROR: <core> [db_query.c:130]: error while submitting query
13(5292) ERROR: usrloc [dlist.c:151]: raw_query failed
13(5292) ERROR: nathelper [nathelper.c:3459]: failed to fetch contacts
13(5292) ERROR: db_mysql [km_dbase.c:117]: driver error on query: Too many conne                                                                                                                       

How should this problem be approached? Could this be due to wrong mysql configuration? But anyway if for each ping done by NAT_PINGER we make a query to the db I think this is a lot of "noise" for the db as pings happen often!
Thanks

BR
Albert
<div>
<p>Hello,</p>
<div><br></div>
<div>We found an issue when using nat pinger&nbsp;<br><br>
</div>
<div>Previously our system had 1 Kamailio as entry point and we were using usrloc in mode &nbsp;2 so:</div>
<div>
<div>modparam("usrloc", "db_mode",2)</div>

<div>modparam("usrloc", "db_url",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; "mysql://openser:openserrw <at> &lt;DB_IP&gt;/openser")</div>
</div>
<div><br></div>
<div>On our system&nbsp;we like to use the pinger NAT_HELPER module to keep the connections alive for the users of our system.<div>

<div><br></div>&nbsp;Now we're trying to configure two Kamailio K1 and K2 as entry point of the system and having both of them active at the same time with a virtual IP as common entry point for both.&nbsp;</div>
<div>I believe this approach requires to flush information on the usrloc immediately because following use case can happen and needs to work:</div>

<div>- A registers on K1 server</div>
<div>- B registers on K2 server</div>
<div>-After 5 seg &nbsp;B makes an INVITE to A through K2=&gt; &nbsp;we need K2 kamailio instance to be able to locate A immediately and not wait until the first Kamailio flushes the info to the db. (it looks to be around 20/30 seg by default &nbsp;on mode 2 I think , correct so this looks to be &nbsp;too much time)</div>

<div><br></div>
<div>So to improve this we tried to change to use usrloc in mode 3 instead of mode 2.&nbsp;But then we've a big issue: when enabling the pinger module for NATted users we see &nbsp;it opens a new connection to the db for each OPTIONS ping we want to send. &nbsp;That looks too many connections for our MySQL server because for eg&nbsp;if I leave two users registered for 1 hour after some time I start to see errors like:</div>

<div>13(5292) ERROR: &lt;core&gt; [db_query.c:130]: error while submitting query</div>
<div>
<div>13(5292) ERROR: usrloc [dlist.c:151]: raw_query failed</div>
<div>13(5292) ERROR: nathelper [nathelper.c:3459]: failed to fetch contacts</div>

<div>13(5292) ERROR: db_mysql [km_dbase.c:117]: driver error on query: Too many conne &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div>
</div>
<div>

<br>
</div>
<div>How should this problem be approached? Could this be due to wrong mysql configuration? But anyway if for each ping done by NAT_PINGER we make a query to the db I think this is a lot of "noise" for the db as pings happen often!</div>

<div>Thanks</div>
<div><br></div>
<div>BR</div>
<div>Albert</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
laura testi | 1 Dec 2011 14:01
Picon

Re: [SR-Users] kamailio fail to start when there are many records in DB in location or in pua table

Thank you very much Daniel!

I will try the patch.

Best Regards,
Laura

On Wed, Nov 30, 2011 at 11:38 AM, Daniel-Constantin Mierla
<miconda@...> wrote:
> Hello,
>
> many modules have a parameter named fetch_rows that is doing pretty much
> what you are looking for. pua seems not to have it, considering the amount
> of records that can be there, it is indeed a limitation. I will add the
> functionality in the near future.
>
> Cheers,
> Daniel
>
>
> On 11/30/11 10:01 AM, laura testi wrote:
>>
>> Hi all,
>>    when there many records in DB tables like location(usrloc use write
>> back mode), pua etc, kamailio fail to start by complaining "no pkg
>> memory left" when try to load (restore) all records from DB to
>> hashtable of location/pua. The share momory are allocated enough for
>> the hashtable, but the default compilation of the PKG_MEMORY_SIZE is
>> 4MB, which allow only restore several thousands records. I know I can
>> increase the PKG_MEMORY_SIZE, but anyway there is a limitation which
>> may fail to restore all records from DB during the startup of kamailio
>> if it reach the limit of the number of records in DB.
>>
>> Is there anyway to reload the hashtable from table by doing query n
>> rows a time and loop until non more result from DB? this will avoid
>> the kamailio startup problem when there are many records in hashtable
>> which are save also in DB.
>>
>>
>> Thank you very much in advanced!
>>
>> Laura
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@...
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.com
> Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>
Permalink | Reply | 0 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 15:18
Picon

Re: [SR-Users] preparing to release v3.2.1

Quick note so that everyone knows that I am starting the process to 
release v3.2.1. Please sync with me via email/irc if you have to commit 
something on git branch 3.2 before the announcement with the release is 
done.

Thanks,
Daniel

On 12/1/11 9:28 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> the plan is to start packaging of v3.2.1 after 14:00GMT. If anyone has 
> anything elst to commit to branch 3.2 to be in v3.2.1, please do it 
> before, afterwards write me an email first to synchronize and avoid 
> git conflicts.
>
> Cheers,
> Daniel
>

--

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Permalink | Reply | 0 comments |
headers
Daniel-Constantin Mierla | 1 Dec 2011 16:44
Picon

[SR-Users] Kamailio v3.2.1 Released

Hello,

Kamailio SIP Server v3.2.1 stable release is out.

This is a maintenance release of latest stable branch, 3.2, that 
includes fixes since release of v3.2.0. There is no change to database 
schema or configuration language structure that you have to do on 
installations of v3.2.0. Deployments running previous v3.2.0 versions 
are strongly recommended to be upgraded to v3.2.1.

For more details about version 3.2.1 (including links and hints to 
download the tarball or from GIT repository), visit:

http://www.kamailio.org/w/2011/12/kamailio-v3-2-1-released/

RPM packages are currently on the build, Debian/Ubuntu packages will be 
available soon as well.

Cheers,
Daniel

--

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Permalink | Reply | 0 comments |

Gmane