Я разрабатываю программный телефон SIP с несколькими учетными записями и настраиваемым переносом мультимедиа. Мне нужно управлять несколькими звонками одновременно. Я прочитал в «Книге PJSUA2» ( 3 PJSUA2-API высокого уровня / Общие концепции / Асинхронные операции ):
(...) все операции, которые включают отправку и получение Сообщения SIP являются асинхронными, что означает, что функция, которая вызывает операцию, завершится немедленно (...) Когда эта функция [pj :: Call :: makeCall] успешно завершается, это не означает, что вызов был установлен, а скорее, он означает, что вызов был инициирован успешно. Вам будет предоставлен отчет о ходе и / или завершении вызова в методе обратного вызова onCallState () класса Call.
Итак, я подумал, что могу позвонить pj::Call::makeCall всякий раз, когда / где мне нужно инициировать вызов, функция вернется почти сразу, и любой прогресс будет сообщаться в методах обратного вызова. Но сегодня в своей тестовой среде я заметил задержку в несколько секунд между моментом вызова функции и ее возвратом. Ниже приведены подробные журналы PJSIP, которые появляются между вызовом makeCall и его возвратом. Перед "RTP socket reachable" виден промежуток почти в 4 секунды:
12:08:32.727 pjsua_call.c !Making call with acc #0 to sip:11@10.0.0.21:5060
12:08:32.727 dlg0x7f3a54002f08 .UAC dialog created
12:08:32.727 dlg0x7f3a54002f08 ..Session count inc to 2 by mod-pjsua
12:08:32.727 pjsua_media.c .Call 0: initializing media..
12:08:36.069 pjsua_media.c ..RTP socket reachable at 10.0.0.100:4000
12:08:36.069 pjsua_media.c ..RTCP socket reachable at 10.0.0.100:4001
12:08:36.069 srtp0x7f3a540052d0 ..SRTP keying SDES created
12:08:36.069 pjsua_media.c ..Media index 0 selected for audio call 0
12:08:36.069 pjsua_media.c ..Call 0: media transport initialization complete: Success
12:08:36.069 dlg0x7f3a54002f08 ..Session count dec to 2 by mod-pjsua
12:08:36.069 dlg0x7f3a54002f08 .Module mod-invite added as dialog usage, data=0x7f3a5400d408
12:08:36.069 dlg0x7f3a54002f08 ..Session count inc to 4 by mod-invite
12:08:36.069 dlg0x7f3a54002f08 .Module mod-100rel added as dialog usage, data=0x7f3a5400f0a8
12:08:36.069 dlg0x7f3a54002f08 .100rel module attached
12:08:36.069 inv0x7f3a54002f08 .UAC invite session created for dialog dlg0x7f3a54002f08
12:08:36.069 endpoint .Request msg INVITE/cseq=7778 (tdta0x7f3a5400f308) created.
12:08:36.069 inv0x7f3a54002f08 ..Sending Request msg INVITE/cseq=7778 (tdta0x7f3a5400f308)
12:08:36.069 dlg0x7f3a54002f08 ...Sending Request msg INVITE/cseq=7778 (tdta0x7f3a5400f308)
12:08:36.069 tsx0x7f3a54012278 ....Transaction created for Request msg INVITE/cseq=7777 (tdta0x7f3a5400f308)
12:08:36.069 tsx0x7f3a54012278 ...Sending Request msg INVITE/cseq=7777 (tdta0x7f3a5400f308) in state Null
12:08:36.069 sip_resolve.c ....Target '10.0.0.21:5060' type=Unspecified resolved to '10.0.0.21:5060' type=UDP (UDP transport)
12:08:36.069 tsx0x7f3a54012278 ....State changed from Null to Calling, event=TX_MSG
12:08:36.070 dlg0x7f3a54002f08 .....Transaction tsx0x7f3a54012278 state changed to Calling
12:08:36.070 pjsua_acc.c !Sending 2 bytes keep-alive packet for acc 0 to 10.0.0.21:5060
12:08:36.070 tdta0x7f3a44005248 Destroying txdata raw
12:08:36.070 pjsua_acc.c Sending 2 bytes keep-alive packet for acc 1 to 10.0.0.21:5060
12:08:36.070 tdta0x7f3a44005248 Destroying txdata raw
Это нормально? Я имею в виду, следует ли мне переделать приложение и вызвать makeCall в фоновом потоке? Или это результат какой-то неправильной настройки? Или ошибка (где-то)?
Когда я сравниваю журналы PJSIP с выводом Wireshark с отметкой времени, мне кажется, что на самом деле никакие SIP-пакеты не отправляются в АТС до того, как возвращается makeCall. Таким образом, эти несколько секунд кажутся потраченными на внутреннюю работу PJSIP. Может быть, это результат некоторого (временного) тупика?
Приложение работает на 64-битной Linux (в данном случае Fedora 31 Workstation).