[asterisk-users] [External] Re: SIP INFO messages with Content-Type: application/media_control+xml

[Floimair Florian]

Thanks Josh!

I was already suspecting something like this.

FLORIAN FLOIMAIR



Von: asterisk-users <asterisk-users-bounces at lists.digium.com> im Auftrag von "Joshua C. Colp" <jcolp at sangoma.com>
Antworten an: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Datum: Mittwoch, 13. Oktober 2021 um 15:12
An: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Betreff: [External] Re: [asterisk-users] SIP INFO messages with Content-Type: application/media_control+xml


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, Oct 13, 2021 at 10:05 AM Floimair Florian <f.floimair at commend.com<mailto:f.floimair at commend.com>> wrote:
Hi all!

We have a WebRTC user-agent (using sip.js) that is giving me headache.

When a different user-agent calls this user-agent, we frequently see Asterisk generating SIP INFO messages with

Content-Type: application/media_control+xml
Content-Length: 178

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
  <vc_primitive>
   <to_encoder>
    <picture_fast_update/>
  </to_encoder>
</vc_primitive>
</media_control>

In the payload, that is sent from Asterisk to the caller UA (the WebRTC client is the callee).

While this does not do any harm usually, I have no clue yet what causes Asterisk to generate these INFO messages.
I do know what they are for (https://datatracker.ietf.org/doc/html/rfc5168<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5168&data=04%7C01%7Cf.floimair%40commend.com%7C348e1e7064704e31218e08d98e4b21d5%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637697275616090301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aaQE409aZSFLW0IKu3zsz187t5MNwDd7q%2FXkZd7mbck%3D&reserved=0>), but not why Asterisk is generating those or what might be the trigger.

Anyone have any hint?

They will occur as a result of a video client requesting a full frame, and there's a few places in Asterisk where it will generate one in certain scenarios. Generally it comes from another client though. It can be received either using an incoming INFO request, or via RTCP through a PLI or FIR. If using PJSIP then the INFO request is only used for the H.264 codec if the WebRTC option is not enabled.

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sangoma.com%2F&data=04%7C01%7Cf.floimair%40commend.com%7C348e1e7064704e31218e08d98e4b21d5%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637697275616100293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BbHjQrV3t1OAspzrXLr1YcQ7k6eJCgUUSVBB40Q4Ai0%3D&reserved=0> and www.asterisk.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asterisk.org%2F&data=04%7C01%7Cf.floimair%40commend.com%7C348e1e7064704e31218e08d98e4b21d5%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637697275616100293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6AM%2BZg%2FL9A04sXw7ntgTjZNzxy4iZ6UJlWRL9bTxyhk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20211013/31e94a73/attachment.html>