Recent changes to bugs

#127 Sofia Resolver is unable to handle the response from secondary DNS server when Primary is unreachable

Andrey Volk — Wed, 15 Dec 2021 09:20:52 -0000

Sofia-sip migrated to GitHub. Use https://github.com/freeswitch/sofia-sip/issues/new

Sofia Resolver is unable to handle the response from secondary DNS server when Primary is unreachable

SAURABHA KUMAR BADHAI — Wed, 15 Dec 2021 08:11:44 -0000

I am using Sofia resolver libsofia-sip-ua to resolve FQDNs, currently I configured /etc/resolv.conf as

nameserver 2.2.2.2 (Unreachable)
nameserver 10.74.137.221 (Reachable)
I am using sofia synchrnous query with sres_blocking_query API. I see request is going to primary DNS and then secondary DNS, and seeing a response from secondary DNS but sofia lib is unable to handle the response
Its showing POLLERR.
TCPDUMP OUTPUTs :
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:54:10.200277 IP 10.174.75.65.59263 > 2.2.2.2.domain: 62235+ A? radius1.example.com. (37)
11:54:10.200288 IP 10.174.75.65.59263 > 2.2.2.2.domain: 62235+ A? radius1.example.com. (37)
11:54:10.200291 IP 10.174.75.65.59263 > 2.2.2.2.domain: 62235+ A? radius1.example.com. (37)
11:54:10.201063 IP 10.174.75.65.21250 > 2.2.2.2.domain: 5568+ PTR? 2.2.2.2.in-addr.arpa. (38)
11:54:10.201067 IP 10.174.75.65.21250 > 2.2.2.2.domain: 5568+ PTR? 2.2.2.2.in-addr.arpa. (38)
11:54:10.201070 IP 10.174.75.65.21250 > 2.2.2.2.domain: 5568+ PTR? 2.2.2.2.in-addr.arpa. (38)
11:54:11.201309 IP 10.174.75.65.19237 > 10.74.137.221.domain: 62235+ A? radius1.example.com. (37)
11:54:11.201318 IP 10.174.75.65.19237 > 10.74.137.221.domain: 62235+ A? radius1.example.com. (37)
11:54:11.201322 IP 10.174.75.65.19237 > 10.74.137.221.domain: 62235+ A? radius1.example.com. (37)
11:54:11.201766 IP 10.74.137.221.domain > 10.174.75.65.19237: 62235- 1/1/1 A 10.174.75.160 (88)
11:54:11.201766 IP 10.74.137.221.domain > 10.174.75.65.19237: 62235- 1/1/1 A 10.174.75.160 (88)
11:54:11.201766 IP 10.74.137.221.domain > 10.174.75.65.19237: 62235*- 1/1/1 A 10.174.75.160 (88)

Is this bug in sofia resolver code ? Can anyone help on this ?

Thanks.
Saurabha Badhai

Memory leak in Sofia-sip

HarishKumar Dubakula — Fri, 05 Oct 2018 10:33:34 -0000

Hello,
Recently I am using sofia sip library for handling subscribe messages.I found a memory leak regarding this.Below is the simple code snippet of mine.We receive every Event from this call back function.

static void EventCallBack(nua_event_t   event  ,
                int           status ,
                char const   * phrase ,
                nua_t        * nua ,
                void * Object,
                nua_handle_t * nh ,
                nua_hmagic_t * hmagic ,
                sip_t const  *sip ,
                tagi_t        tags[]) {

    switch(event) {

        case nua_i_subscribe:

                       sofia_dispatch_event_t *de = (sofia_dispatch_event_t *)malloc(sizeof(sofia_dispatch_event_t));

                        memset(de, 0, sizeof(*de));
                        nua_save_event(nua, de->event);
                        de->nh = nua_handle_ref(nh);
                        de->data = nua_event_data(de->event);

                       nua_respond((nua_handle_t *)nh, SIP_200_OK , NUTAG_WITH_THIS_MSG(de->data->e_msg), SIPTAG_CONTACT_STR(cContact.c_str()), TAG_END());

                       free(de);
                        nua_handle_destroy((nua_handle_t *)nh);
    }
}

this simple code snippet making memory leak...I think i am destroying the event perfectly.

Thank you

Can not add headers

Bidyut — Wed, 11 Apr 2018 07:47:16 -0000

I am getting following errors when I am trying to add header

nta_msg_tsend(request): cannot add headers

Here is my Node JS code:

var acceptcontact = req.getParsedHeader('Accept-Contact');

srf.proxyRequest(req, dest, {
    headers: {
        'Accept-Contact': acceptcontact
      }
    }

Can you please point me, why I am getting error ?

Regards
Bidyut

Unittest failure in test_msg

Gilles Dartiguelongue — Sat, 19 Aug 2017 12:35:07 -0000

I was trying to fix various test failures for Gentoo and some tests in test_msg unittests are failing.

msg_hclass_offset() does not work correctly when sofia-sip has been built with gcc 4.9.x

François Grisez — Fri, 09 Jan 2015 14:45:32 -0000

Hello sofia-sip team.

I am working on a SIP server which use sofia-sip as SIP stack. I found that msg_dup does not completly copy SIP messages when sofia-sip has been built with gcc 4.9.2. After more investigations, I found that gcc's optimizations alterate the working of the msg_hclass_offset() function. More sepcificaly, gcc destroies the loop situated at line 2551.

The issue occures with version 4.9.x of gcc and the last release of sofia-sip (1.12.11).

I give you in attachement a programm that highlight the issue. It parse a SIP message located in a file, copy it with msg_dup() and print the source message and copied message by using msg_as_string().

Thank you in advance

François Grisez

sres_sip.c:907: possible cut'n'paste error ?

dcb — Mon, 28 Apr 2014 09:22:02 -0000

sres_sip.c:907]: (style) Expression is always false because 'else if' condition matches previous condition at line 902.

Source code is

else if (type == sres_type_cname) {
  char const *cname = sr->sr_cname->cn_cname;
  SU_DEBUG_5(("srs(%p): %s IN CNAME %s\n", (void *)srs, domain, cname));
}

if SU_HAVE_IN6

else if (type == sres_type_cname) {
  sres_aaaa_record_t const *aaaa = sr->sr_aaaa;
  su_inet_ntop(AF_INET6, &aaaa->aaaa_addr, addr, sizeof(addr));
  SU_DEBUG_5(("srs(%p): %s IN AAAA %s\n", (void *)srs, domain, addr));
}

#121 Undefined C language feature triggered

Simon McVittie — Thu, 05 Dec 2013 20:22:40 -0000

Steps to reproduce:

compile with gcc 4.8
various uses of SIP, including running the telepathy-rakia regression tests as described on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729301

Expected result:

tests pass, SIP calls work, etc.

Actual result:

the symptom I saw in the failing regression tests was that the body of a MESSAGE was 0 bytes long, rather than the expected 5 ("hello")

Workaround:

gcc -fno-aggressive-loop-optimizations

#121 Undefined C language feature triggered

Simon McVittie — Thu, 05 Dec 2013 20:18:16 -0000

Here is a version of the patch without whitespace damage so git/patch can apply it.

Other downstream references to this bug include:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729301
https://bugs.launchpad.net/ubuntu/+source/sofia-sip/+bug/1246171
http://lists.freedesktop.org/archives/telepathy/2013-November/006536.html
http://lists.freedesktop.org/archives/telepathy/2013-December/006542.html

Undefined C language feature triggered

Olivier Crête — Thu, 14 Nov 2013 21:03:17 -0000

There is a patch at
https://bugzilla.redhat.com/show_bug.cgi?id=981056