Bug found: Asterisk not handles "a=recvonly" for video in "183 Session Progress" response correctly

[meiky]

When Asterisk receives “183 Session Progress” (with “a=recvonly” for video) from SIP phone (when early media phase starts), it treats this (recvonly) as “pending” and later when the session is established sends re-INVITE with “a=recvonly” for video (and therefore video only works in one direction for the whole call).

Description:
Asterisk Server (Asterisk 20.4.0~dfsg+~cs6.13.40431414-2 on Ubuntu) can talk to upstream Trunk (SIP server) and SIP Phone (number 2003) Grandstream GXV3240 directly in LAN (without special routing).
All PJSIP endpoints are configured with “direct_media=no”.

Scenario:
1) Call comes in (from trunk) to Asterisk Server to reach 2003 (Grandstream GXV3240) with “a=sendrecv” for video stream (INVITE).
2) Asterisk itself calls Grandstream GXV3240, 2003 with “a=sendrecv” for video stream (INVITE).
3) Grandstream GXV3240 answers with “183 Session Progress” and “a=recvonly” for video stream (early media, only wants to receive video but does not want to send video).
4) Asterisk sends “183 Session Progress” to upstream trunk with “a=sendrecv” for video stream (early media).
5) early media works, callee (on Grandstream GXV3240) can see caller (from trunk) on video-display but caller cannot see callee (as expected, all correct)
6) someone picks up SIP phone and Asterisk receives “200 OK” from Grandstream GXV3240 (now) with “a=sendrecv” for video stream
8) Asterisk sends “200 OK” back to upstream SIP trunk with “a=sendrecv” for video stream
9) when call established, Asterisk sends “re-INVITE” to upstream trunk with “a=recvonly” for video stream
10) upstream trunk respons back with “200 OK” and “a=sendonly” for video stream
11) call works with audio in both directions but video works only in one direction from “Trunk => Grandstream GXV3240”!!!
12) BYE

Problem starts at 3) when Asterisk receives the “a=recvonly” (for video) as part of “Session Progress” fro SIP phone when early media starts.
Asterisk does not forwards this to to upstream SIP trunk server in 4), instead sends normal “a=sendrecv” for video.
At this point there is a pending change for the session in Asterisk (for setting video stream to “a=recvonly”).
Later when session is established for both call legs, Asterisk checks that there is a pending change and sends re-INVITE with “a=recvonly” for video stream.
This causes that video works only in one direction.

I have detailed debug output of Asterisk with with “debug=yes” set in pjsip.conf and
“core set verbose 5” and “core set debug 9 res_pjsip_session.so” enabled on cli which shows the behaviour.
But unfortunatley it is too long to post this here.

Can someone confirm this bug in Asterisk or what can be wrong here?

Thanks.

[jcolp]

Does enabling the accept_multiple_sdp_answers option[1] change things? Note it also needs to be enabled in the system section as well.

[1] asterisk/configs/samples/pjsip.conf.sample at master · asterisk/asterisk · GitHub

[meiky]

Now i have added “accept_multiple_sdp_answers=yes” both in [system] and (every) [endpoint] section of pjsip.conf file.
After restart of Asterisk service (cli “reload” is not sufficent), Asterisk does indeed not sends the re-INVITE to SIP phone at all (so session is not updated to video “a=recvonly”) and therefore video works in both directions!!! Awesome!
Works for me (tested between two SIP video phones) but does not know how all my other SIP devices behave (have to test).

Unfortunatley Asterisk still forwards incoming “183 Session Progress” with SDP “a=recvonly” for video as “a=sendrecv” to SIP Phone on second call leg.
Would be nice when Asterisk forwards incoming “Session Progress” with same “a=recvonly” for video as it is received and when later receiving “OK” also forwards “a=sendrecv” as it was received (from phone).
Currently calling device/trunk expects video data from Asterisk after receiving “Session Progress” (with “a=sendrecv”) in early media phase but called device does not send video data to Asterisk because it just responded with “a=recvonly” for video.

[jcolp]

No configuration will alter that, it’s a limitation of the core and how the progress side works. Requires code changes.

[meiky]

Thanks a lot and for letting me know.
Maybe this can be fixed in a future version of Asterisk…