[asterisk-dev] Codec negotiation when incoming re-INVITE has no SDP (ASTERISK-28036)

[Richard Mudgett]

On Sun, Sep 9, 2018 at 8:23 PM, Daniel Harper <daniel at harper.nz> wrote:

> It has been recommended that I bring this up in order to get some
> feedback on ways to move forward regarding this feature "When
> recieving an re-Invite without SDP asterisk can re-offer all available
> codecs supported"
>
> See https://issues.asterisk.org/jira/browse/ASTERISK-28036
>
> I have had a look at the source for res_pjsip_session.c and
> res_pjsip_sdp_rtp.c but I am not sure I have the skillset or knowledge
> to be able to make a patch myself.
>
> I found this in regards to the feature being added to pjsipua
> https://trac.pjsip.org/repos/ticket/1892


For v15+ it looks easier to get the desired behavior.

Looks like in v15+ the res_pjsip_sessions.c:create_local_sdp() function
can be modified to use the configured stream format capabilities when
there is no session->pending_media_state->topology or the topology is empty.

/* We've encountered a situation where we have been told to create a local
SDP but noone has given us any indication
 * of what kind of stream topology they would like. We try to not alter the
current state of the SDP negotiation
 * by using what is currently negotiated. If this is unavailable we fall
back to what is configured on the endpoint.
 */

If there is an active_media_state->topology then we could use that topology
and set the pending_media_state->topology
stream formats to the configured endpoint media formats based on stream
type.

When the session->pending_media_state->topology formats are setup then the
outgoing deferred offer should be correct.

For v13 getting the desired behavior looks to be more difficult to know
when to use the configured
codecs rather than the previously negotiated codecs.

In v13 the same function could also be modified.  Unfortunately, I'm not
seeing a way to know when
to copy the session->endpoint->media.codecs configured capabilities to the
session->req_caps.  If
we knew when to do that the outgoing deferred offer should be correct.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180912/23f7363c/attachment.html>