[asterisk-bugs] [JIRA] (ASTERISK-28057) SipNotify on Chan_Sip vi AMI behave different to CLI

[Peter Katzmann (JIRA)]

Peter Katzmann created ASTERISK-28057:
-----------------------------------------

             Summary: SipNotify on Chan_Sip vi AMI behave different to CLI
                 Key: ASTERISK-28057
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28057
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/Messaging, Channels/chan_sip/TCP-TLS
    Affects Versions: 13.22.0
         Environment: ubuntu xenial
            Reporter: Peter Katzmann
            Severity: Minor


During test with secure connections with Mitel deskphones we examined a problem with notify action via ami. 
Asterisk generates a message like :
*chan_sip.c: peer '3001' HAS NOT USED (OR SWITCHED TO) TLS in favor of 'UDP' (but this was allowed in sip.conf)!*
and the Mitel phones odes not react to the message.
On the other side when i initiate the notify message vi cli command *sip notify* the phones reacts and the message does not appear.

Now we compared the notfiy code via ami and cli and saw that there is plenty of duplicated code in the network setup with one small difference:

creat_addr differes, cli uses "create_addr(p, channame, NULL, 1)" and ami uses "create_addr(p, channame, NULL, 0)" instead.

After we made a small patch 
{color:blue}
--- a/channels/chan_sip.c       2018-09-05 19:12:27.000000000 +0200
+++ b/channels/chan_sip.c       2018-09-14 16:13:33.903984495 +0200
@@ -15572,7 +15572,7 @@
                        return 0;
                }
 
-               if (create_addr(p, channame, NULL, 0)) {
+               if (create_addr(p, channame, NULL, 1)) {
                        /* Maybe they're not registered, etc. */
                        dialog_unlink_all(p);
                        dialog_unref(p, "unref dialog inside for loop" );
{color}

against asterisk 13.23 the message vanished and the notify via ami worked.
Due the lack of documentation of the parameter we are not sure if this is a valid fix for the problem or a cause of new problems.




--
This message was sent by Atlassian JIRA
(v6.2#6252)