[asterisk-dev] asterisk 16 / pjsip: SDP handling on outbound calls - unnecessary transcoding

[Joshua C. Colp]

On Sun, Jun 23, 2019, at 1:47 AM, Michael Maier wrote:
> On 22.06.19 at 23:59 Joshua C. Colp wrote:
> > On Sat, Jun 22, 2019, at 4:40 PM, Michael Maier wrote:
> >> Hello!
> >>
> >> On outbound calls, the codecs for the subsequent INVITE to the ISP are 
> >> derived from the codecs defined for the trunk and from the received 
> >> INVITE from the local device.
> >>
> >> The codecs presented by the ISP in 200 OK seem to be ignored 
> >> unfortunately later on.
> >>
> >> E.g.:
> >> direct_media disabled
> >> Local endpoint definition: g722, alaw, ulaw
> >> Trunk definition: g722, alaw, ulaw
> >>
> >> Outbound call:
> >> Initial INVITE from local endpoint: g722, alaw, ulaw, g726
> >>
> >> Subsequent INVITE to ISP: g722, alaw, ulaw (the codecs are derived 
> >> from the initial INVITE and the codecs defined for the trunk)
> >> Response from ISP: 200 OK: alaw
> >>
> >> 200 OK to local endpoint: g722, alaw, ulaw (based on initial INVITE 
> >> and local endpoint definition - the 200 OK from the ISP is ignored)
> >>
> >> => asterisk has to transcode between g722 <-> alaw
> >>
> >>
> >> Is there any chance to get the codec information of the ISP during 
> >> building the 200 OK for the local endpoint in 
> >> handle_negotiated_sdp_session_media() or maybe somewhere else? Or did I 
> >> miss something else? I want to remove g722 in 200 OK to
> >> local endpoint.
> > 
> > There's nothing built in explicitly to do this and it's not something that has really been scoped out. A few people have wanted such functionality, but it hasn't been implemented. You can't really reach across and get the information - it has to be communicated back probably through using a frame.
> 
> That's a pity. Especially because it's working as expected on inbound calls.
> 
> What do you exactly mean by "using a frame"?

Things (such as answer, ringing, etc) are negotiated using control frames. This could be used to communicate the negotiated codecs back so it could then be used for the construction of the answer on the ingress side.

> 
> BTW, while analyzing, I found a potentially unnecessary variable in 
> set_caps (see patch), which never seems to be used. I removed it 
> without any side effects yet.

Yes, it does not appear to be used. Please create an issue[1].

[1] https://issues.asterisk.org/jira

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org