Asterisk sends two SDPs after negotiation is done

Hi! I am using Asterisk 20, I also have a sip client, based on pjsip, used for SIP calls.

I am currently having some issues regarding video calls.The call flow looks roughly like:
SIP client sends invite with video sendrecv,
the asterisk responds with 200 OK with video sendrecv but the Asterisk immediately sends a new invite with video as sendonly (since the device I am calling only supports sendonly), making the sip client sometimes deadlock.
Why does the asterisk send two invites?

So these are the sdps:

Invite from the SIP client to Asterisk:

INVITE sip
Via: SIP/2.0/UDP
Max-Forwards: 70
From: sip:SIP_CLIENT
To: sip:Asterisk
Contact:
Call-ID: x
CSeq: 14690 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 984

v=0
o=-
s=pjmedia
b=AS:386
t=0 0
a=X-nat:0
m=audio 59735 RTP/AVP 96 97 98 99 3 0 8 9 100 120 121 122 123
c=IN IP4
b=TIAS:96000
a=rtcp:59736 IN
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 opus/48000/2
a=fmtp:100 useinbandfec=1
a=rtpmap:120 telephone-event/16000
a=fmtp:120 0-16
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=rtpmap:122 telephone-event/32000
a=fmtp:122 0-16
a=rtpmap:123 telephone-event/48000
a=fmtp:123 0-16
a=ssrc:x cname:x
m=video 47010 RTP/AVP 97
c=IN IP4
b=TIAS:256000
a=rtcp:47011 IN IP4
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
a=ssrc:x cname:x

200 OK from Asterisk to SIP_client with sendrecv video direction:

SIP/2.0 200 OK
Via: SIP/2.0/UDP
Call-ID: x
From: SIP_CLIENT
To: Asterisk
CSeq: 14690 INVITE
Server: Asterisk PBX 20.6.0~dfsg+~cs6.13.40431414-2build5
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Contact:
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 407

v=0
o=- IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 28926 RTP/AVP 0 8 97 121
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 speex/8000
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=ptime:20
a=maxptime:60
a=sendrecv
m=video 29586 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=42E01E
a=sendrecv

ACK:
ACK/cseq=14690
ACK sip SIP/2.0
Via: SIP/2.0/UDP
Max-Forwards: 70
From: SIP_Client
To: DUT
Call-ID: x
CSeq: 14690 ACK
Content-Length: 0

The SIP client then starts both encoding and decoding video, but the Asterisk sends a new invite directly after ACK with new video direction:

INVITE from Asterisk to SIP client with new video direction (sendonly):
INVITE sip
Via: SIP/2.0/UDP
From: Asterisk
To: SIP_Client
Contact:
Call-ID: x
CSeq: 15452 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800;refresher=uas
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 20.6.0~dfsg+~cs6.13.40431414-2build5
Content-Type: application/sdp
Content-Length: 407

v=0
o=- x
s=Asterisk
c=IN IP4
t=0 0
m=audio 28926 RTP/AVP 0 8 97 121
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 speex/8000
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=ptime:20
a=maxptime:60
a=sendrecv
m=video 29586 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=42E01E
a=sendonly

When looking at the SDPs on the DUT, I see that there is only one 200 OK and that is with a=sendonly for video direction. Also, when making peer to peer calls, there is only one 200 OK between SIP client and DUT that has a=sendonly as video direction. So this only seems to happen when making registered calls.

This is the pjsip.conf used for the Asterisk:

[global]

debug = no

keep_alive_interval = 10

[system]

threadpool_initial_size = 1

threadpool_max_size = 10

disable_tcp_switch = yes

[transport-udp-ipv4]

type = transport

protocol = udp

bind = {udp_address}

[transport-tcp-ipv4]

type = transport

protocol = tcp

bind = {tcp_address}

[transport-tls-ipv4]

type = transport

protocol = tls

bind = {tls_address}

allow_reload = yes

method = tlsv1_2

require_client_cert = no

verify_client = no

verify_server = no

cert_file = {cert_file}

priv_key_file= {priv_key_file}

ca_list_file= {ca_list_file}

[basic_settings_endpoint](!) ; A template used for endpoints

type = endpoint

context = Internal-Main

disallow = all

allow = ulaw,alaw,speex,h264

direct_media =no

dtmf_mode = auto_info

media_encryption=no

media_encryption_optimistic = yes

identify_by = username

trust_id_outbound = yes

[basic_settings_auth](!) ; A template used for auth

type = auth

auth_type = userpass

[basic_settings_aor](!) ; A template used for aor

type = aor

max_contacts = 1

remove_existing = yes

minimum_expiration = 1 ; Minimum keep alive time for an AoR (default: “60”)

[1000](basic_settings_endpoint)

auth = 1000

aors = 1000

callerid = Lindsey Freddie <1000>

[1000](basic_settings_auth)

password = 1000

username = 1000

[1000](basic_settings_aor)

mailboxes = 1000@example

Asterisk does not forward the 200 OK response from an outgoing leg to the 200 OK it sends. If the outgoing leg isn’t sendrecv, then after bridging it will re-INVITE accordingly.

The second INVITE is a re-INVITE, but you have redacted out the information that actually identifies it as one (call ID, From tag, and, in particular, To tag). Simple INVITEs don’t have To tags.

Is there a way to configure the Asterisk to only send one 200 OK with the correct sdp, or will it always send its own 200 OK first and then a RE-INVITE with the recipients capabilities?

There is no configuration to alter the behavior.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.