Hello,
there is probably a cosmetic issue in pjsip-2.2.1 and pjsip-2.3 releases
regarding the above mentioned function call, especially in "ice-mode",
which can be demonstrated by running two copies of pjsip-apps/bin/pjsua
against each other:
having started
pjsip-apps/bin/pjsua
on 192.168.2.100 and then
pjsip-apps/bin/pjsua --use-ice
on 192.168.2.200 and then calling 192.168.2.100, finally after a while
typing
dq
on 192.168.2.100 shows
[CONFIRMED] To: <sip:192.168.2.200>;tag=Broa5SEfTXc53Ma3ydLAsF35w.DzJTa1
Call time: 00h:00m:22s, 1st res in 2110 ms, conn in 2622ms
#0 audio speex @16kHz, sendrecv, peer=192.168.2.200:4011
SRTP status: Not active Crypto-suite:
[... etc ...]
(which is OK as this endpoint has no ice activated); but 'dq' on
192.168.2.200 shows
[CONFIRMED] To: sip:192.168.2.100;tag=r21N27dVpRqJtrciRy7hSgwowSkU7DA7
Call time: 00h:00m:33s, 1st res in 2363 ms, conn in 2629ms
#0 audio speex @16kHz, sendrecv, peer=-
SRTP status: Not active Crypto-suite:
ICE role: Unknown, state: Candidate Gathering, comp_cnt: 2
[... etc ...]
It looks like here above the "peer=-" means that
if (pj_sockaddr_has_addr(&tp_info.src_rtp_name)) ...
fails in ./pjsip/src/pjsua-lib/pjsua_dump.c on 192.168.2.200, and so does
if (pj_sockaddr_has_addr(&ii->comp[jj].rcand_addr)) ...
(having forcefully entered the 'for (jj=0;
ii->sess_state==PJ_ICE_STRANS_STATE_RUNNING && jj<2; ++jj)' loop).
*****
Media connection by itself is up and fine but how to determine the
remote endpoint IP-address programmatically by pjsip APIs in such a case
if ICE negotiation failed?
Eeri Kask
