Asterisk remove video codec from SDP sip packet 200 OK

Silas · July 16, 2023, 5:34am

Hi all,

I have upgraded the version of Asterisk from 11.18.0 to Asterisk 16.18.0 due to some compatibility issues with the OS version. However, I have encountered a problem with video calls. In the directmedia=yes mode, video is not displayed on both peers. (I used chan_sip)

Flow call:
phone 1 ------> asterisk ------>phone 2

Both phone 1 and phone 2 have video support enabled (videosupport=yes), directmedia=yes, and maxbitrate=512.

Case 1: Using asterisk 11.18, the video is working fine and quality is excellent;

Case 2: using asterisk 16.18.0, with all the same configure as above. However, phone 1 is in audio mode, and phone 2 is in video mode but no video is displayed.
I used the wireshark tool to log the sip flow call, and i noticed a diference when asterisk receives 200OK/SDP from phone 2:

Step 1: Phone 1 invite with profile-level-id=640C16
Step 2: Asterisk send invite to phone 2 with profile-level-id=640C16
Step 3: Phone 2 not support profile-level-id=640C16, and after that it reply 200OK/SDP with profile-level-id=42801F

Asterisk 11:

Step 4: Asterisk send 200OK/SDP with profile-level-id=42801F to phone 1, the video is working fine.

Asterisk 16:

Step 4: Asterisk send 200OK/SDP with no profile video, only audio to phone 1 ==> problem is here.

I believe Asterisk 16 compares the profile-level-id difference between the invite and the 200OK/SDP.
Please help me with some advices on this issue:

Which code needs to be changed (file chan_sip.c or others)?
How can I configure Asterisk 16 to achieve the same result as shown in the above scenario with Asterisk 11?

Thanks so much!

david551 · July 16, 2023, 12:02pm

16.18 is still too old to support. 16 is on security updates only and is at 16.30.1.

chan_sip is also not supported, and certainly not so for customising the source code itself.

Please reproduce the problem with Asterisk 20 and chan_pjsip.

Also, for people here to understand what is wrong, you need to provide the “psjsip set logger on” (“sip set debug on”) logging, and probably enable debug level logging, as well as the verbose, needed for those commands.

Silas · July 17, 2023, 3:38pm

Hi David,
Thank you for your reply.
I’m attaching some log screenshots and the SIP call log file on asterisk version 16, directmedia=yes, directrtpsetup=yes in sip.conf, phone 1 caller, phone 2 called:

Phone 1 ---------------------Assterisk 16 -----------------Phone 2
(IP:172.16.1.217) (IP: 172.16.1.75) (IP: 172.16.1.213)

I post some wireshark images and sip log (sip set debug on) to show my problem with asterisk 16.18.0 version;

Asterisk 11: The SIP message 200 OK/SDP (as shown in step 4 of the image) sent to phone 1 is successful, including the video profile, as expected.

a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42801F; packetization-mode=1

Asterisk 16: when sending the SIP message 200 OK/SDP to phone 1, the video profile (rtpmap) is removed, and only audio is sent

Please support me with some instructions on the changed location or commit ID/version of Asterisk that modified the handling of this SDP packet? and is there any change in the handling of SDP messages from version 11 to version 16?
What modifications can I make to achieve similar functionality as version 11?
Thanks so much!

Log SIP Call.txt (10.9 KB)

david551 · July 17, 2023, 5:39pm

Please provide the plain text logs from Asterisk. One possibility is that your packet capture is truncating the packet. as I think it unlikely that other people wouldn’t have complained about a media stream with an undefined payload type.

Silas · July 18, 2023, 2:08am

Hi David, thanks for your reply.
Below is the detailed plain text from Wireshark:
Step 1: Phone 1 send invite message to asterisk 16 with SDP (profile-level-id is high profile)

INVITE sip:650001@172.16.1.75 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.217:5072;branch=z9hG4bK921225804;rport
From: "650005" <sip:650005@172.16.1.75>;tag=1232538312
To: <sip:650001@172.16.1.75>
Call-ID: 433826295-5072-6@BHC.BG.B.CBH
CSeq: 51 INVITE
Contact: "650005" <sip:650005@172.16.1.217:5072>
Authorization: Digest username="650005", realm="asterisk", nonce="2218746a", uri="sip:650001@172.16.1.75", response="db89d714cb92b051239d23133f2e4a49", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream GXV3275 1.0.3.224
Privacy: none
P-Preferred-Identity: "650005" <sip:650005@172.16.1.75>
P-Access-Network-Info: IEEE-EUI-48;eui-48-addr=00-1D-AA-8C-FE-A0
P-Emergency-Info: IEEE-EUI-48;eui-48-addr=00-0B-82-73-95-82
Supported: replaces, path, timer, eventlist
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length: 506

v=0
o=650005 8000 8000 IN IP4 172.16.1.217
s=SIP Call
c=IN IP4 172.16.1.217
t=0 0
m=audio 5004 RTP/AVP 0 8 101
a=sendrecv
a=rtcp:5005 IN IP4 172.16.1.217
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 5006 RTP/AVP 100
b=AS:2240
a=sendrecv
a=rtcp:5007 IN IP4 172.16.1.217
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=64001F; packetization-mode=1
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=content:main
a=label:11

Step 2: asterisk send invite message to phone 2


INVITE sip:650001@172.16.1.213;transport=udp SIP/2.0
Via: SIP/2.0/UDP 172.16.1.75:5060;branch=z9hG4bK6af027e0
Max-Forwards: 70
From: <sip:650005@172.16.1.75>;tag=as4802ee08
To: <sip:650001@172.16.1.213;transport=udp>
Contact: <sip:650005@172.16.1.75:5060>
Call-ID: 2fe37d861d3ded1b31df4a8468212c62@172.16.1.75:5060
CSeq: 102 INVITE
User-Agent: asterisk
Date: Mon, 17 Jul 2023 12:56:56 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 356

v=0
o=root 2117605073 2117605073 IN IP4 172.16.1.75
s=asterisk
c=IN IP4 172.16.1.217
b=CT:512
t=0 0
m=audio 5004 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
m=video 5006 RTP/AVP 100
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=1;profile-level-id=64001F
a=sendrecv

Step 3: Phone 2 reply asterisk with message 200OK, SDP and profile-level-id is changed (baseline)

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 172.16.1.75:5060;branch=z9hG4bK6af027e0
From: <sip:650005@172.16.1.75>;tag=as4802ee08
To: <sip:650001@172.16.1.213;transport=udp>;tag=N8zOhLF
Call-ID: 2fe37d861d3ded1b31df4a8468212c62@172.16.1.75:5060
CSeq: 102 INVITE
User-Agent: vipphone-19/4.4.25 - Core/4.4.0
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Contact: <sip:650001@172.16.1.213;transport=udp>;expires=3600;+sip.instance="<urn:uuid:408db02f-15a4-003b-bf33-245aaa0b1712>"
Content-Type: application/sdp
Content-Length: 288
v=0
o=650001 3720 1086 IN IP4 172.16.1.213
s=Talk
c=IN IP4 172.16.1.213
b=AS:3000
t=0 0
m=audio 7078 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
m=video 9078 RTP/AVP 100
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42801F; packetization-mode=1

Step 4: Asterisk reply message 200OK with SDP, but no profile video to phone 1

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.217:5072;branch=z9hG4bK921225804;received=172.16.1.217;rport=5072
From: "650005" <sip:650005@172.16.1.75>;tag=1232538312
To: <sip:650001@172.16.1.75>;tag=as56d917a7
Call-ID: 433826295-5072-6@BHC.BG.B.CBH
CSeq: 51 INVITE
Server: asterisk
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: <sip:650001@172.16.1.75:5060>
Content-Type: application/sdp
Require: timer
Content-Length: 247

v=0
o=root 595057351 595057351 IN IP4 172.16.1.75
s=asterisk
c=IN IP4 172.16.1.213
t=0 0
m=audio 7078 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
m=video 0 RTP/AVP 100

The problem in step 4: I expected Asterisk to include the video attribute in SDP when sending the 200 OK/SDP message to phone 1, but it didn’t happen:

a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42801F; packetization-mode=1

I tested the same scenario with Asterisk 11.18, it worked as expected, the video attribute in SDP when sending the 200 OK/SDP message to phone 1.

Thanks so much!

david551 · July 18, 2023, 11:26am

I asked for the logs from Asterisk.

There is definitely something wrong, but, it could be caused by truncation rather than an error in constructing the SDP.

Silas · July 18, 2023, 3:46pm

Hi David,
apologies for any misunderstanding! I’m sending back the Asterisk log file, which includes call logs, the configuration of SIP phone 1 and phone 2, and SIP General settings, debug file (core set debug).

My issue is whether Asterisk compares the video attributes in the outgoing INVITE message with the received 200OK/SDP video attributes or not. Specifically, when asterisk send video H264 with attribute “fmtp: 100 profile-level-id=64001F” in the INVITE message and it received “fmtp: 100 profile-level-id=42801F” in response, asterisk removed it due to the difference in the value of the “profile-level-id” parameter ??

In Asterisk version 11.18, it seems to accept this behavior, but in version 16, it doesn’t work, and the video attribute is removed.
Thanks so much!

debug_level_9.txt (117.0 KB)
sip_show_peer_phone1.txt (2.0 KB)
sip_show_peer_phone2.txt (2.0 KB)
sip_show_settings.txt (4.0 KB)
SIP-Log.txt (13.2 KB)

david551 · July 18, 2023, 4:03pm

Sorry. It’s not truncation, but you are highlighting the wrong part of it. The problem is:

The 0 means it is rejecting the stream, so doesn’t need to explain what media type 100 is, so it is perfectly valid not to have the rtpmap=

I’m not sure the B side is allowed to request asymmetric format codes on a single stream, but I’d have to delve into the details of the RFCs. I’m sure that Asterisk is not going to create that situation on the A side.

With 11, did it actually reply with the modified profile, or did it simply return the requested one, which would have been an error, as it wouldn’t be able to convert between the two.

Silas · July 18, 2023, 4:17pm

Thanks for your reply, David!

I sure that Asterisk 11 does not reject the video and copies the ‘ftmp: 100 profile-level-id=42801F;packetization-mode=1’ from side B to send to side A, allowing both phones to enter normal video call mode.

However, in Asterisk 16, this behavior seems to be different, and it might be the reason why it works differently.
Could you please point me to the code section where this comparison is happening so that I can check and debug it myself
Thanks so much!

rvk · July 18, 2023, 4:19pm

Seems to be the requested one from phone one (answer should still be interesting)
Other topic:

I’m also wondering if phone 1 shouldn’t pass all allowed profiles (so asterisk can match them directly). But maybe that’s not done.

Also level-asymmetry-allowed is not provided by phone 1 so it’s not allowed. Phone 2 needs to answer with the same level, doesn’t it?

If level-asymmetry-allowed is equal to 0 (or not present) in either the offer or the answer, level asymmetry is not allowed. In this case, the level to use in the direction from the offerer to the answerer MUST be the same as the level to use in the opposite direction.

david551 · July 18, 2023, 4:28pm

I would find that surprising, as Asterisk doesn’t normally propagate media information backwards. I think it more likely it reflected the A side and you got away with it.

rvk · July 18, 2023, 6:10pm

Maybe here (for latest version)?

github.com

asterisk/asterisk/blob/master/res/res_format_attr_h264.c#L101


      
          
          	if (original) {
          		*attr = *original;
          	}
          
          	ast_format_set_attribute_data(dst, attr);
          
          	return 0;
          }
          
          static enum ast_format_cmp_res h264_cmp(const struct ast_format *format1, const struct ast_format *format2)
          {
          	struct h264_attr *attr1 = ast_format_get_attribute_data(format1);
          	struct h264_attr *attr2 = ast_format_get_attribute_data(format2);
          
          	if (!attr1 || !attr1->PROFILE_IDC || !attr2 || !attr2->PROFILE_IDC ||
          		(attr1->PROFILE_IDC == attr2->PROFILE_IDC)) {
          		return AST_FORMAT_CMP_EQUAL;
          	}
          
          	return AST_FORMAT_CMP_NOT_EQUAL;

For Asterisk 11

github.com

asterisk/asterisk/blob/11/res/res_format_attr_h264.c#L81


      
          	H264_ATTR_KEY_SPROP_MAX_DON_DIFF,
          	H264_ATTR_KEY_MAX_RCMD_NALU_SIZE,
          	H264_ATTR_KEY_LEVEL_ASYMMETRY_ALLOWED,
          	H264_ATTR_KEY_SPS_LEN,
          	H264_ATTR_KEY_PPS_LEN,
          	H264_ATTR_KEY_SPS,
          	H264_ATTR_KEY_PPS = H264_ATTR_KEY_SPS + H264_MAX_SPS_PPS_SIZE,
          	H264_ATTR_KEY_END = H264_ATTR_KEY_PPS + H264_MAX_SPS_PPS_SIZE,
          };
          
          static enum ast_format_cmp_res h264_format_attr_cmp(const struct ast_format_attr *fattr1, const struct ast_format_attr *fattr2)
          {
          	if (!fattr1->format_attr[H264_ATTR_KEY_PROFILE_IDC] || !fattr2->format_attr[H264_ATTR_KEY_PROFILE_IDC] ||
          	    (fattr1->format_attr[H264_ATTR_KEY_PROFILE_IDC] == fattr2->format_attr[H264_ATTR_KEY_PROFILE_IDC])) {
          		return AST_FORMAT_CMP_EQUAL;
          	}
          
          	return AST_FORMAT_CMP_NOT_EQUAL;
          }
          
          static int h264_format_attr_get_joint(const struct ast_format_attr *fattr1, const struct ast_format_attr *fattr2, struct ast_format_attr *result)

BTW. I assume everything works again if you set the H.264 Profile Type of the Grandstream (phone 1) to Baseline (B=42, H=64)?

Silas · July 19, 2023, 1:39am

I’m sorry David, I remembered it wrong, asterisk 11 didn’t copy, but this version still sends the video attribute back to phone 1, and then phone 1 and phone 2’s video work fine.

Silas · July 19, 2023, 1:45am

Hi rvk,
Thank you for your support, I will check following your instructions.
If I set phone 1 as baseline (profile-level-id=42xxxx), both phones will have video because of two phone used same profile-level-id=42XXXX.
However, if I set phone 1 as profile-level-id=64xxxx, the issue occurs on Asterisk 16 (while Asterisk 11 still has video normally because Asterisk doesn’t remove the video attribute).
I expect is that Asterisk 16 will still attach the video profile when there is a difference between the profile-level-id of the two phones.
Thanks so much!

rvk · July 19, 2023, 9:14am

Yes, Asterisk 16 only sends back profile-level-id when both sides have matching offers. Now they don’t.

Shouldn’t phone 1 then send all supported levels? You now have set a specific level in the Grandstream.

Have you tried setting the H.264 Profile Type in the Grandstream to “BP/MP/HP”? And if you do, can you look at the requested profile-level-id’s? Are there multiple now? And does Asterisk now match one of them? (because then it should work) Phone one now also sends both 42XXXX and 64xxxx in which case Asterisk could match the 42XXXX one.

If “BP/MP/HP” is selected, all three profiles “Baseline Profile” “Main Profile” and “High Profile” will be used for negotiation during video decoding to achieve the best result.

Silas · July 19, 2023, 10:26am

Hi rvk,
I have changed the H.264 Profile Type in Grandstream to baseline, and the video is now working fine. My issue has been resolved. Many thanks to @david551 and @rvk for supporting me.
Thanks!

david551 · July 19, 2023, 12:41pm

It was probably working because what was actually being sent was in the intersection of both profiles, or the B side accepted more than it admitted to. Part of the change was probably adding feedback to the A side.

rvk · July 19, 2023, 1:06pm

Did you mean you now tried “BP/MP/HP”?
Or did you set Baseline Profile?

If you set Baseline then the Grandstream won’t request higher formats anymore, even to phones which can handle that. It’s best to set it to “BP/MP/HP” so the best possible profile is chosen.

Silas · July 19, 2023, 2:24pm

Hi rvk, I have tried setting the baseline or HP/MP/BP in Grandstream, and it worked fine. However, I encountered a problem when I only set HP in Grandstream
Thanks!

system · August 18, 2023, 2:24pm

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

Topic		Replies	Views
How to configure asterisk 1.6.2 to video call? Asterisk Support	3	489	August 10, 2011
SDP header issue Asterisk Support	2	228	September 25, 2014
How to upgrade to video from audio-only call Asterisk SIP	7	2863	October 12, 2018
Missing Audio/Video SDP issue Asterisk SIP	0	1338	December 5, 2017
Asterisk + sipml5 + webrtc2sip Asterisk Support	8	712	July 10, 2013

Asterisk remove video codec from SDP sip packet 200 OK

Related topics