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@gmail.com mailto:govoiper@gmail.com> 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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

...

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@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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

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@gmail.com mailto:govoiper@gmail.com> 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@gmail.com <mailto:miconda@gmail.com>> 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@gmail.com <mailto:govoiper@gmail.com>> 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@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@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@lists.sip-router.org  <mailto:sr-users@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello again,

You were right, as soon as I made changes in asterisk SIP profile for the Kamailio proxy server and stopped the 401 Auth from Asterisk to Kamailio the CANCELS started to work fine.

So the SIP flow now is:

- invite from phone to kamailio - kamailio asks for authentication - 407 - ack - invite with credentials, kamailio forwards to asterisk - asterisk starts processing the invite and call can be cancelled now.

Thanks alot

--

Best Regards, Sammy.

On Thu, Dec 1, 2011 at 12:01 PM, Sammy Govind govoiper@gmail.com wrote:

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

...

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

...

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@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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

Hi,

I wouldn't say it a bug then, since its ok from specs poiint of view. The real issue was that we had Asterisk realtime previously which had the same extension set enabled in DB.

So the users with same extensions registering on Kamailio making calls via asterisk had trouble because asterisk started matching the incoming callerid-name with the ones in its realtime DB. So obviously Asterisk had to ask for AUTH since the phone is not actually registered but still sending INVITES.

So I had to disable the asterisk realtime and asterisk stopped asking for the extension specific password from kamailio and kamailio just relays the Auth request to x-lite/eyebeam.

The phones since already have gone through the authentication process maybe failing to understand why is this Authentication request required and drop it or something. This was observed in multiple vendor IP-Phones and softphones.

But at the end, I really thank you for pointing out the issue cause and it really resolved it, else I was totally lost in TM module pages to find any function which I missed to match these CANCELs.

Best Regards, Sammy

On Fri, Dec 2, 2011 at 10:55 PM, Daniel-Constantin Mierla <miconda@gmail.com

wrote:

Hello,

On 12/2/11 5:24 AM, Sammy Govind wrote:

Hello again,

You were right, as soon as I made changes in asterisk SIP profile for the Kamailio proxy server and stopped the 401 Auth from Asterisk to Kamailio the CANCELS started to work fine.

well, the 401 from asterisk is ok from specs point of view (although many phones don't work with many challenges), but this case revealed some bugs in asterisk as well as in xlite, both of them had misbehavior.

Cheers, Daniel

So the SIP flow now is:

• invite from phone to kamailio
• kamailio asks for authentication - 407
• ack
• invite with credentials, kamailio forwards to asterisk
• asterisk starts processing the invite and call can be cancelled now.

Thanks alot

--

Best Regards, Sammy.

On Thu, Dec 1, 2011 at 12:01 PM, Sammy Govind govoiper@gmail.com wrote:

...

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

...

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

...

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@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@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 listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda