asterisk users - Dec 2020 - Multiple 183 Session Progress for a single call

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)?


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20201217/dcb5ba0e/attachment.html>

On Thu, Dec 17, 2020 at 10:14 AM Floimair Florian <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

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20201217/e2eb220e/attachment.html>