Hi Jonathan,

Thanks for your response. Your suggestions helped me dig deeper into
code and explore further.

In a normal example below

05:19:49.416  pjsua_call.c  .....Call 3: received updated media offer
05:19:49.416  pjsua_media.c  ......Call 3: re-initializing media..
05:19:49.416  pjsua_media.c  .......Media index 0 selected for audio
call 3
05:19:49.418  pjsua_media.c  ......Call 3: updating media..
05:19:49.419  pjsua_media.c  ........Media stream call03:0 is destroyed
05:19:49.419    pjsua_aud.c  .......Audio channel update..
05:19:49.420  strm0xdeaf34  ........VAD temporarily disabled
05:19:49.420  strm0xdeaf34  ........Encoder stream started
05:19:49.421  strm0xdeaf34  ........Decoder stream started
05:19:49.421  pjsua_media.c  .......Audio updated, stream #0: G722
(sendrecv)
05:19:49.421    pjsua_app.c  ......Call 3 media 0 [type=audio], status
is Active
05:19:49.421    pjsua_aud.c  ......Conf connect: 3 --> 0
05:19:49.421  conference.c  .......Port 3 (sip:2005@192.168.1.152)
transmitting to port 0 (Master/sound)
05:19:49.421    pjsua_aud.c  ......Conf connect: 0 --> 3
05:19:49.422  conference.c  .......Port 0 (Master/sound) transmitting
to port 3 (sip:2005@192.168.1.152)
05:19:49.422  pjsua_core.c  ........TX 953 bytes Response msg
200/INVITE/cseq=13507 (tdta0xe02964) to UDP 192.168.1.2:5060:

I tried calling the snippet you shared earlier, in
on_call_media_update(pjsua_app.c). needed to include pjsua_internal.h
to directly access the structures in snippet, but it works.

**********The user is 2003 (pjsua_get_var ()) --> retrieving internal
variable.
***********00:05:07.613  strm0x7060dc !...Unable to receive RTP
packet, recv() returned 70014: Operation cancelled (PJ_ECANCELLED)
00:05:07.619  strm0x7060dc  ...RTCP recv() error: Operation cancelled
(PJ_ECANCELLED) [err:70014]
00:05:07.622  pjsua_core.c  ....TX 952 bytes Response msg
200/INVITE/cseq=10918 (tdta0x701fcc) to UDP 192.168.1.2:5060:

*********** Looks like ports got closed.
--end msg--
00:05:07.629  pjsua_call.c  .....Call 0: received updated
media offer
00:05:07.630  pjsua_media.c  ....Bus error

But, after a call is confirmed, streams are getting created where
on_rx_rtp and on_rx_rtcp callbacks are registered. Closing transport
media, will crash the process if transport media is closed(unable to
recv error, followed by Bus error).

My SLIC/DSP software handles codec information, packetization periods
etc., and other parameters. It only needs the rtp_cfg information. So,
could we disable stream creation and audio device call back in pjmedia?
Or should we disconnect the media elsewhere?

Regards,
SMS

On Wed, 2021-05-26 at 22:47 +0000, Cook, Jonathan E. (Fed) wrote:

I could not find a way to prevent stream creation so I waited until the streams were created and disconnected them.

Regards,
Jonathan Cook

-----Original Message-----
From: Sai Mukund Sagar Deshpande saimukunds@tejasnetworks.com
Sent: Thursday, May 27, 2021 1:09 PM
To: Cook, Jonathan E. (Fed) jonathan.cook@nist.gov; pjsip@lists.pjsip.org
Subject: Re: Only use SIP signalling and disable pjmedia RTP

Hi Jonathan,

Thanks for your response. Your suggestions helped me dig deeper into code and explore further.

In a normal example below

05:19:49.416  pjsua_call.c  .....Call 3: received updated media offer
05:19:49.416  pjsua_media.c  ......Call 3: re-initializing media..
05:19:49.416  pjsua_media.c  .......Media index 0 selected for audio call 3
05:19:49.418  pjsua_media.c  ......Call 3: updating media..
05:19:49.419  pjsua_media.c  ........Media stream call03:0 is destroyed
05:19:49.419    pjsua_aud.c  .......Audio channel update..
05:19:49.420  strm0xdeaf34  ........VAD temporarily disabled
05:19:49.420  strm0xdeaf34  ........Encoder stream started
05:19:49.421  strm0xdeaf34  ........Decoder stream started
05:19:49.421  pjsua_media.c  .......Audio updated, stream #0: G722
(sendrecv)
05:19:49.421    pjsua_app.c  ......Call 3 media 0 [type=audio], status
is Active
05:19:49.421    pjsua_aud.c  ......Conf connect: 3 --> 0
05:19:49.421  conference.c  .......Port 3 (sip:2005@192.168.1.152)
transmitting to port 0 (Master/sound)
05:19:49.421    pjsua_aud.c  ......Conf connect: 0 --> 3
05:19:49.422  conference.c  .......Port 0 (Master/sound) transmitting
to port 3 (sip:2005@192.168.1.152)
05:19:49.422  pjsua_core.c  ........TX 953 bytes Response msg
200/INVITE/cseq=13507 (tdta0xe02964) to UDP 192.168.1.2:5060:

I tried calling the snippet you shared earlier, in on_call_media_update(pjsua_app.c). needed to include pjsua_internal.h to directly access the structures in snippet, but it works.

**********The user is 2003 (pjsua_get_var ()) --> retrieving internal variable.
***********00:05:07.613  strm0x7060dc !...Unable to receive RTP
packet, recv() returned 70014: Operation cancelled (PJ_ECANCELLED)
00:05:07.619  strm0x7060dc  ...RTCP recv() error: Operation cancelled
(PJ_ECANCELLED) [err:70014]
00:05:07.622  pjsua_core.c  ....TX 952 bytes Response msg
200/INVITE/cseq=10918 (tdta0x701fcc) to UDP 192.168.1.2:5060:

*********** Looks like ports got closed.
--end msg--
00:05:07.629  pjsua_call.c  .....Call 0: received updated
media offer
00:05:07.630  pjsua_media.c  ....Bus error

But, after a call is confirmed, streams are getting created where on_rx_rtp and on_rx_rtcp callbacks are registered. Closing transport media, will crash the process if transport media is closed(unable to recv error, followed by Bus error).

My SLIC/DSP software handles codec information, packetization periods etc., and other parameters. It only needs the rtp_cfg information. So, could we disable stream creation and audio device call back in pjmedia?
Or should we disconnect the media elsewhere?

Regards,
SMS

On Wed, 2021-05-26 at 22:47 +0000, Cook, Jonathan E. (Fed) wrote:

Could you please share how you did it? It didn't work for me.

From: Cook, Jonathan E. (Fed) jonathan.cook@nist.gov
Sent: Friday, May 28, 2021 1:58:54 AM
To: Sai Mukund Sagar Deshpande saimukunds@tejasnetworks.com; pjsip@lists.pjsip.org pjsip@lists.pjsip.org
Subject: RE: Only use SIP signalling and disable pjmedia RTP

I could not find a way to prevent stream creation so I waited until the streams were created and disconnected them.

Regards,
Jonathan Cook

-----Original Message-----
From: Sai Mukund Sagar Deshpande saimukunds@tejasnetworks.com
Sent: Thursday, May 27, 2021 1:09 PM
To: Cook, Jonathan E. (Fed) jonathan.cook@nist.gov; pjsip@lists.pjsip.org
Subject: Re: Only use SIP signalling and disable pjmedia RTP

Hi Jonathan,

Thanks for your response. Your suggestions helped me dig deeper into code and explore further.

In a normal example below

05:19:49.416  pjsua_call.c  .....Call 3: received updated media offer
05:19:49.416  pjsua_media.c  ......Call 3: re-initializing media..
05:19:49.416  pjsua_media.c  .......Media index 0 selected for audio call 3
05:19:49.418  pjsua_media.c  ......Call 3: updating media..
05:19:49.419  pjsua_media.c  ........Media stream call03:0 is destroyed
05:19:49.419    pjsua_aud.c  .......Audio channel update..
05:19:49.420  strm0xdeaf34  ........VAD temporarily disabled
05:19:49.420  strm0xdeaf34  ........Encoder stream started
05:19:49.421  strm0xdeaf34  ........Decoder stream started
05:19:49.421  pjsua_media.c  .......Audio updated, stream #0: G722
(sendrecv)
05:19:49.421    pjsua_app.c  ......Call 3 media 0 [type=audio], status
is Active
05:19:49.421    pjsua_aud.c  ......Conf connect: 3 --> 0
05:19:49.421  conference.c  .......Port 3 (sip:2005@192.168.1.152)
transmitting to port 0 (Master/sound)
05:19:49.421    pjsua_aud.c  ......Conf connect: 0 --> 3
05:19:49.422  conference.c  .......Port 0 (Master/sound) transmitting
to port 3 (sip:2005@192.168.1.152)
05:19:49.422  pjsua_core.c  ........TX 953 bytes Response msg
200/INVITE/cseq=13507 (tdta0xe02964) to UDP 192.168.1.2:5060:

I tried calling the snippet you shared earlier, in on_call_media_update(pjsua_app.c). needed to include pjsua_internal.h to directly access the structures in snippet, but it works.

**********The user is 2003 (pjsua_get_var ()) --> retrieving internal variable.
***********00:05:07.613  strm0x7060dc !...Unable to receive RTP
packet, recv() returned 70014: Operation cancelled (PJ_ECANCELLED)
00:05:07.619  strm0x7060dc  ...RTCP recv() error: Operation cancelled
(PJ_ECANCELLED) [err:70014]
00:05:07.622  pjsua_core.c  ....TX 952 bytes Response msg
200/INVITE/cseq=10918 (tdta0x701fcc) to UDP 192.168.1.2:5060:

*********** Looks like ports got closed.
--end msg--
00:05:07.629  pjsua_call.c  .....Call 0: received updated
media offer
00:05:07.630  pjsua_media.c  ....Bus error

But, after a call is confirmed, streams are getting created where on_rx_rtp and on_rx_rtcp callbacks are registered. Closing transport media, will crash the process if transport media is closed(unable to recv error, followed by Bus error).

My SLIC/DSP software handles codec information, packetization periods etc., and other parameters. It only needs the rtp_cfg information. So, could we disable stream creation and audio device call back in pjmedia?
Or should we disconnect the media elsewhere?

Regards,
SMS

On Wed, 2021-05-26 at 22:47 +0000, Cook, Jonathan E. (Fed) wrote:

Hi,

I observed there is 30 seconds delay on my mips embedded device when
placing a call.

Initial TCP/UDP sip binding(5060) during boot also takes same amount of
time.

In API create_rtp_rtcp_sock

    printf("\n*****getting local ip***** \n");
    /* Get local IP address. */
    status = pj_gethostip(af, &addr);
    if (status != PJ_SUCCESS)
        goto on_error;

    pj_sockaddr_copy_addr(&bound_addr, &addr);
    printf("\n**** got local ip ****** \n");

pj_gethostip probably takes 30 seconds to resolve IP. It has
implementation to assign weights to different interfaces and choose the
best fit. This is very slow in realtime. Incoming calls are also
received after 30 seconds. Is this observed on any other device and is
this expected behavior?

Pasting dd logs

00:31:23.284  pjsua_core.c !Start dumping application states:
PJLIB (c)2008-2016 Teluu Inc.
Dumping configurations:
PJ_VERSION                : 2.8
PJ_M_NAME                : mips
PJ_HAS_PENTIUM            : 0
PJ_OS_NAME                : mips-unknown-elf
PJ_CC_NAME/VER_(1,2,3)    : gcc-5.3.0
PJ_IS_(BIG/LITTLE)_ENDIAN : big-endian
PJ_HAS_INT64              : 1
PJ_HAS_FLOATING_POINT    : 1
PJ_DEBUG                  : 1
PJ_FUNCTIONS_ARE_INLINED  : 0
PJ_LOG_MAX_LEVEL          : 5
PJ_LOG_MAX_SIZE          : 4000
PJ_LOG_USE_STACK_BUFFER  : 1
PJ_POOL_DEBUG            : 0
PJ_HAS_POOL_ALT_API      : 0
PJ_HAS_TCP                : 1
PJ_MAX_HOSTNAME          : 128
ioqueue type              : select
PJ_IOQUEUE_MAX_HANDLES    : 64
PJ_IOQUEUE_HAS_SAFE_UNREG : 1
PJ_HAS_THREADS            : 1
PJ_LOG_USE_STACK_BUFFER  : 1
PJ_HAS_SEMAPHORE          : 1
PJ_HAS_EVENT_OBJ          : 1
PJ_ENABLE_EXTRA_CHECK    : 1
PJ_HAS_EXCEPTION_NAMES    : 1
PJ_MAX_EXCEPTION_ID      : 16
PJ_EXCEPTION_USE_WIN32_SEH: 0
PJ_TIMESTAMP_USE_RDTSC:  : 0
PJ_OS_HAS_CHECK_STACK    : 0
PJ_HAS_HIGH_RES_TIMER    : 1
PJ_HAS_IPV6              : 0
Dumping endpoint 0xb5d3bc:
Dumping caching pool:
Capacity=0, max_capacity=0, used_cnt=15
Dumping all active pools:
pjsua:    9888 of    11024 (89%) used
pept0xb5d358:    49432 of    52096 (94%) used
pjsua-app:    1440 of    2024 (71%) used
tsxlayer:    4332 of    5120 (84%) used
ua0xb5ce28:    2320 of    3072 (75%) used
med-ept:    24424 of    26112 (93%) used
codec-mgr:      196 of      256 (76%) used
evt mgr:      304 of      512 (59%) used
evsub:    1564 of    2048 (76%) used
udp0xb757e0:      836 of    1024 (81%) used
glck0xb75bf0:      408 of      512 (79%) used
rtd0xb75df8:    4592 of    12096 (37%) used
acc0xb5c8a8:      596 of      768 (77%) used
regc0xb78d48:    2120 of    3072 (69%) used
auth_cli0xb7d4c8:      108 of    1024 (10%) used
Total    102560 of    120760 (84 %) used!
Endpoint pool capacity=52096, used_size=49432
Outstanding transmit buffers: 0
Dumping listeners:
Dumping transports:
udp0xb757e0 udp 0.0.0.0:5060 [published as 172.17.2.17:5060]
(refcnt=3)
Timer heap has 3 entries
Dumping PJMEDIA capabilities:
Total number of installed codecs: 3
Audio codec # 0: pt=18 (G729 @8KHz/1, 8.0Kbps, 10ms vad plc)
Audio codec # 1: pt=0 (PCMU @8KHz/1, 64.0Kbps, 10ms vad plc)
Audio codec # 2: pt=96 (FOO @16KHz/1, 5.0Kbps, 20ms vad plc)
Dumping media transports:
Dumping transaction table:
Total 0 transactions

• none -
  Number of dialog sets: 0
  Dumping pjsua server subscriptions:
  sip:2003@172.17.2.18
• none -
  Dumping pjsua client subscriptions:
• no buddy list -
  00:31:23.293  pjsua_core.c  Dump complete

Regards,
SMS

Hi,

in pjlib/include/pj/compat/os_auto.h resolved this issue but seems like
dns resolution will be disabled due to this.

Same issue was seen in IOS as per #1342 where delay is 5 seconds but
here on mips, I see 30 seconds delay which is very high.

After enabling
#define PJ_GETHOSTIP_DISABLE_LOCAL_RESOLUTION 1
Initialization is fast and calls are going immediately.

Regards,
SMS

On Mon, 2021-07-05 at 07:34 +0000, Sai Mukund Sagar Deshpande via pjsip
wrote:

I could be wrong, but this looks to me like a misconfigured/firewalled DNS request/reply, with 30 seconds being the timeout on a DNS resolve.

July 5, 2021 9:37 AM, "Sai Mukund Sagar Deshpande via pjsip" pjsip@lists.pjsip.org wrote:

Yes, i think that is problem. thanks for response.

On Thu, 2021-07-08 at 13:38 +0000, buldozer@aufbix.org wrote: