[asterisk-users] [External] Re: Multiple 183 Session Progress for a single call

[Floimair Florian]

Thanks Joshua for the quick answer!

I may put some investigation effort into this after the holidays regarding the known-issue.
For now we “help” ourselves by dropping the second 183 Session progress in Kamailio to mitigate the issue that arises in the second scenario.

Best regards!

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: Donnerstag, 17. Dezember 2020 um 15:22
An: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Betreff: [External] Re: [asterisk-users] Multiple 183 Session Progress for a single call


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 Thu, Dec 17, 2020 at 10:14 AM Floimair Florian <f.floimair at commend.com<mailto:f.floimair at commend.com>> wrote:
Hi List!

I am running into an „issue” that I cannot really explain.
I have a call from Station A to Station B with both legs connected to Asterisk via Kamailio.
Asterisk used is latest 18.1.0 with chan_pjsip.

Station A -> Kamailio -> Asterisk -> Kamailio -> Station B

Now when Station B gets the INVITE it answers with 183 Session Progress to initiate Early Media.
However Asterisk not only passes this 183 Session Progress on to Station A, it creates a second 183 Session Progress with basically the same
Content (only some Header lines might have switched position but their content is identical) to Station A.

The first question that comes to mind is:
Why does Asterisk send the second 183 Session Progress in the first place (it did not get anything from Station A or Station B that would explain this)?

There is already an open issue for this[1], but noone has worked on it as of yet.

And in turn this leads to an issue if I replace station A with another Asterisk and put station A behind this Asterisk.

Station A -> Asterisk2 -> Kamailio -> Asterisk -> Kamailio -> Station B

In that case whatever was in the SDP of the first 183 Session Progress (e.g. audio=recvonly video=inactive) will cause the second Asterisk to put both media streams to sendrecv, and starts sending RTP packets from Station A for both audio and video which clearly is a bug in Asterisk. By the way we tested with different versions from the latest 18 back to an early 16 version. They all show this behaviour.
To recap both 183 Session Progress contain the same SDP, the first one leads to wanted behaviour, the second one causes Asterisk to send both audio and video even though it shouldn’t.

I can't say for certainty, but this is likely because of the way codec and stream negotiation in Asterisk works. Each leg is independent (negotiated between Asterisk and an endpoint), and the result of an outgoing leg (be it from a 200 OK or 183 Session Progress) is not forwarded to the calling side. There is continued work being done to improve this so in the future it could become smarter, but it is not yet there.

[1] issues.asterisk.org/jira/browse/ASTERISK-28185<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fissues.asterisk.org%2Fjira%2Fbrowse%2FASTERISK-28185&data=04%7C01%7Cf.floimair%40commend.com%7C581d516089c74644460b08d8a29722b2%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637438117312983378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e9eGkOstRp1NKZfY%2B315NUitngFoT%2FZ8WoIOd0BDcDk%3D&reserved=0>

--
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%7C581d516089c74644460b08d8a29722b2%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637438117312993368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SMKjlwzSYhg1NWEdQh3xX%2B5lWaRrQecP4Zpu%2B93e9tI%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%7C581d516089c74644460b08d8a29722b2%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637438117313003365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=De%2F%2FLAVHAPL2%2F7tg5n4DBQ%2F4ra%2BVX7kkGVrVFw3na50%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20201217/528524c5/attachment.html>