Hi, I checked with pjsua-app. I tried to connect the recorder to the sound device with "cc 0 0" command. But it doesn't work! No sound from the sound device. I am sure that the mic volume is good because the "recfile" sample works. Regards, R?my. pjsip-request at lists.pjsip.org a ?crit?: > Send pjsip mailing list submissions to > pjsip at lists.pjsip.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > or, via email, send a message with subject or body 'help' to > pjsip-request at lists.pjsip.org > > You can reach the person managing the list at > pjsip-owner at lists.pjsip.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pjsip digest..." > > > Today's Topics: > > 1. Re: pjsip1.0 rc3: compilation problem with visual studio 6.0 > (Benny Prijono) > 2. Re: Default candidate selection in ice_strans.c > (Stephen D. Strowes) > 3. Re: problem of micro (Nanang Izzuddin) > 4. Re: Default candidate selection in ice_strans.c (Benny Prijono) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Sep 2008 12:45:28 +0100 > From: "Benny Prijono" <bennylp@xxxxxxxxx> > Subject: Re: pjsip1.0 rc3: compilation problem with visual > studio 6.0 > To: "pjsip list" <pjsip at lists.pjsip.org> > Message-ID: > <1879720d0809260445s482cc9bp2ec69df557d2c288 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Sep 26, 2008 at 9:40 AM, Massimiliano Montevecchi < > massimiliano.montevecchi at elsagdatamat.com> wrote: > >> Hi. >> >> >> >> I have a compilation error with the latest pjsip release: 1.0 rc3. >> >> My build environment is base on Microsoft Visual C++ 6.0 >> >> >> >> It seems that this pjsip release defines: >> >> # define PJ_SOCK_HAS_GETADDRINFO 1 >> >> > My fault. This should have been enabled only when IPv6 support is set, but a > checkin accidentally removed this check (line 56 of > include/pj/compat/socket.h should be "#if defined(_MSC_VER) && > defined(PJ_HAS_IPV6) && PJ_HAS_IPV6!=0"). > > I'll fix that asap. And I think we've got too many build problems with this > release that it warrants an immediate rc4. > > Cheers > Benny > > > >> >> In the previous release I didn't have any compilation problem. >> >> In attach you can find my config_site.h. >> >> >> >> Beat Regards >> >> Massimiliano >> >> >> >> >> >> Compilation Log: >> >> >> >> --------------------Configuration: pjlib - Win32 >> Release-------------------- >> >> Compiling... >> >> addr_resolv_sock.c >> >> C:\Programmi\Microsoft Visual Studio\VC98\INCLUDE\qos.h(236) : warning >> C4201: nonstandard extension used : nameless struct/union >> >> C:\Programmi\Microsoft Visual Studio\VC98\INCLUDE\qos.h(463) : warning >> C4201: nonstandard extension used : nameless struct/union >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(64) >> : error C2079: 'hint' uses undefined struct 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(97) >> : error C2224: left of '.ai_family' must have struct/union type >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(99) >> : warning C4013: 'getaddrinfo' undefined; assuming extern returning int >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(106) >> : error C2037: left of 'ai_next' specifies undefined struct/union 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(108) >> : error C2037: left of 'ai_family' specifies undefined struct/union >> 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(112) >> : error C2037: left of 'ai_canonname' specifies undefined struct/union >> 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(113) >> : error C2037: left of 'ai_canonname' specifies undefined struct/union >> 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(114) >> : warning C4047: 'function' : 'const char *' differs in levels of >> indirection from 'unsigned int ' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(114) >> : warning C4024: 'strncpy' : different types for formal and actual parameter >> 2 >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(114) >> : error C2198: 'strncpy' : too few actual parameters >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(122) >> : error C2037: left of 'ai_addr' specifies undefined struct/union 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(122) >> : error C2037: left of 'ai_addrlen' specifies undefined struct/union >> 'addrinfo' >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(122) >> : error C2198: 'pj_memcpy' : too few actual parameters >> >> C:\ANTS-Development\IMS\pjproject-1.0-rc3\pjlib\src\pj\addr_resolv_sock.c(130) >> : warning C4013: 'freeaddrinfo' undefined; assuming extern returning int >> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080926/7ca869ee/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 26 Sep 2008 14:54:55 +0300 > From: "Stephen D. Strowes" <stephen.strowes@xxxxxxxxx> > Subject: Re: Default candidate selection in ice_strans.c > To: pjsip list <pjsip at lists.pjsip.org> > Message-ID: <1222430095.21750.28.camel at esdhcp030103> > Content-Type: text/plain > > Hi, > > Fyi, I'm using the pjsua text-based client for testing, not custom code. > > > On Fri, 2008-09-26 at 11:53 +0100, ext Benny Prijono wrote: >> looking at the code, the ice_strans will call the callback with error >> status when it's got no response from the STUN server, and I suppose >> the application should terminate or retry the initialization in this >> case, rather than continuing the operation. Also the application >> shouldn't use the ice_strans before the callback is called with >> initialization complete status. > > Yes, a timeout will trigger the stun_on_status() callback, but this > function will only alter the set of candidates available if the srflx > candidate turns out to the the same as the host candidate, i.e., no NAT. > Otherwise, the srflx candidate remains unset in the list of candidates. > > So if I run with stun, no turn, and host candidates allowed, the set of > candidates is initialised as: > > 0- 0.0.0.0 > 1- host addr > > With the default_cand set to 0. > > If no BIND SUCCESS is received, or the STUN server is down, or I'm > braindead and point at the wrong STUN server, then when I start up pjsua > and attempt to make a call to a REGISTERed used, then an ASSERT fails > elsewhere in the code when building an SDP description. It fails when > trying to copy a sockaddr which is neither type ipv4 or v6, I think: > > pjsua-i686-pc-linux-gnu: ../src/pj/sock_common.c:376: > pj_sockaddr_get_len: Assertion `a->addr.sa_family == PJ_AF_INET || > a->addr.sa_family == PJ_AF_INET6' failed. > Aborted > > Note that the line number might be out, owing to sprinkling some code > with my own logging statements to track down the problem; the failure > happens in pj_sockaddr_get_len() in sock_common.c; call stack at this > point is: > > #0 0xb7f91410 in __kernel_vsyscall () > #1 0xb7c78085 in raise () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7c79a01 in abort () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7c7110e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 > #4 0x08117b2d in pj_sockaddr_get_len () > #5 0x08117d32 in pj_sockaddr_cp () > #6 0x080b00ac in transport_get_info () > #7 0x080b24d2 in transport_get_info () > #8 0x08063624 in pjsua_media_channel_create_sdp () > #9 0x08058f59 in pjsua_call_make_call () > #10 0x0804e8a9 in console_app_main () > #11 0x0805083b in app_main () > #12 0x0804b3d0 in main () > > > My thinking is that this is avoided if the srflx address is only > considered the default, or isn't added to the list, until after a BIND > has succeeded. Hence my suggestion that the default_cand should be set > within the stun_on_status() and turn_on_state() functions. > > Unless I'm thinking about things incorrectly? > > > Cheers, > -S. > > > > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Sep 2008 19:05:42 +0700 > From: "Nanang Izzuddin" <nanang@xxxxxxxxx> > Subject: Re: problem of micro > To: "pjsip list" <pjsip at lists.pjsip.org> > Message-ID: > <f8a01ced0809260505j600694fdicee9a89f23ea301d at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Everything looks fine to me and I couldn't reproduce this with pjsua, > I've checked the recorded file, it contains voice. Btw, have you > checked if this also happens with pjsua? > > On Fri, Sep 26, 2008 at 12:29 AM, R?my LEFEVRE <lefevrer at enserg.fr> wrote: >> Thanks Nanang for you answer! >> >> By "impossible", I mean that the file contains only silence. The file is not >> empty because its size is few hundreds of Kio for few tens of seconds. And >> for call, no sound for the addressee. >> > > Just in case, while your application running please check the mic > volume (and mute setting). Please also check with other recording > application, e.g: sound recorder if you're working in Windows. > >> My pseudo_code is the following for a recorder: >> pjsua_recorder_create(&filename, 0, NULL, 0, 0, p_id); >> pjsua_conf_connect(0, pjsua_recorder_get_conf_port(*p_id)); >> >> pjsua_recorder_create(&filename, 0, NULL, 0, 0, p_id); >> pjsua_conf_connect(0, pjsua_recorder_get_conf_port(*p_id)); >> >> And the following for a call: >> pjsua_call_make_call(acc_id, &uri, 0, NULL, NULL, ¤t_call); >> pjsua_call_get_info(call_id, &ci); >> pjsua_conf_connect(ci.conf_slot, 0); >> pjsua_conf_connect(0, ci.conf_slot); >> > > Looks fine, just make sure p_id is allocated or points to > valid/allocated memory address. > > Regards, > nanang > > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Sep 2008 13:16:12 +0100 > From: "Benny Prijono" <bennylp@xxxxxxxxx> > Subject: Re: Default candidate selection in ice_strans.c > To: "pjsip list" <pjsip at lists.pjsip.org> > Message-ID: > <1879720d0809260516l362c8969gdb2b4e64354c3b13 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Sep 26, 2008 at 12:54 PM, Stephen D. Strowes < > stephen.strowes at nokia.com> wrote: > >> Hi, >> >> Fyi, I'm using the pjsua text-based client for testing, not custom code. >> >> >> On Fri, 2008-09-26 at 11:53 +0100, ext Benny Prijono wrote: >> > looking at the code, the ice_strans will call the callback with error >> > status when it's got no response from the STUN server, and I suppose >> > the application should terminate or retry the initialization in this >> > case, rather than continuing the operation. Also the application >> > shouldn't use the ice_strans before the callback is called with >> > initialization complete status. >> >> Yes, a timeout will trigger the stun_on_status() callback, but this >> function will only alter the set of candidates available if the srflx >> candidate turns out to the the same as the host candidate, i.e., no NAT. >> Otherwise, the srflx candidate remains unset in the list of candidates. >> >> So if I run with stun, no turn, and host candidates allowed, the set of >> candidates is initialised as: >> >> 0- 0.0.0.0 >> 1- host addr >> >> With the default_cand set to 0. >> >> If no BIND SUCCESS is received, or the STUN server is down, or I'm >> braindead and point at the wrong STUN server, then when I start up pjsua >> and attempt to make a call to a REGISTERed used, then an ASSERT fails >> elsewhere in the code when building an SDP description. It fails when >> trying to copy a sockaddr which is neither type ipv4 or v6, I think: >> >> pjsua-i686-pc-linux-gnu: ../src/pj/sock_common.c:376: pj_sockaddr_get_len: >> Assertion `a->addr.sa_family == PJ_AF_INET || a->addr.sa_family == >> PJ_AF_INET6' failed. >> Aborted >> >> Note that the line number might be out, owing to sprinkling some code >> with my own logging statements to track down the problem; the failure >> happens in pj_sockaddr_get_len() in sock_common.c; call stack at this >> point is: >> >> #0 0xb7f91410 in __kernel_vsyscall () >> #1 0xb7c78085 in raise () from /lib/tls/i686/cmov/libc.so.6 >> #2 0xb7c79a01 in abort () from /lib/tls/i686/cmov/libc.so.6 >> #3 0xb7c7110e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 >> #4 0x08117b2d in pj_sockaddr_get_len () >> #5 0x08117d32 in pj_sockaddr_cp () >> #6 0x080b00ac in transport_get_info () >> #7 0x080b24d2 in transport_get_info () >> #8 0x08063624 in pjsua_media_channel_create_sdp () >> #9 0x08058f59 in pjsua_call_make_call () >> #10 0x0804e8a9 in console_app_main () >> #11 0x0805083b in app_main () >> #12 0x0804b3d0 in main () >> >> >> My thinking is that this is avoided if the srflx address is only >> considered the default, or isn't added to the list, until after a BIND >> has succeeded. Hence my suggestion that the default_cand should be set >> within the stun_on_status() and turn_on_state() functions. >> >> Unless I'm thinking about things incorrectly? >> >> > > I'm not sure which version are you using, but in recent pjsip this shouldn't > happen, as pjsua-lib will wait until ice_strans initialization is complete > before application can make any calls. If STUN resolution fails, the media > transport initialization will fail too, and in pjsua this would cause it to > quit. > > Cheers > Benny > > > > > >> >> Cheers, >> -S. >> >> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080926/11317de5/attachment.html> > > ------------------------------ > > _______________________________________________ > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > End of pjsip Digest, Vol 13, Issue 95 > ************************************* > >
