[Asterisk-code-review] ACN: res_pjsip endpoint options (asterisk[master])

Kevin Harwell asteriskteam at digium.com
Tue Jul 7 15:37:31 CDT 2020


Kevin Harwell has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/14629 )

Change subject: ACN: res_pjsip endpoint options
......................................................................


Patch Set 2: Code-Review-1

(4 comments)

https://gerrit.asterisk.org/c/asterisk/+/14629/2/configs/samples/pjsip.conf.sample 
File configs/samples/pjsip.conf.sample:

https://gerrit.asterisk.org/c/asterisk/+/14629/2/configs/samples/pjsip.conf.sample@850 
PS2, Line 850:                            ; operation: <intersect | only_preferred
             :                             ;    | only_nonpreferred>,
I think the operation in this case would only allow "intersect". We'd never pass a codec along that's not in both lists (pending and configured). For instance if pending has alaw,ulaw, and configured has alaw,g722 then I don't think there is a reason to ever pass along ulaw or g722.


https://gerrit.asterisk.org/c/asterisk/+/14629/2/configs/samples/pjsip.conf.sample@863 
PS2, Line 863:                             ; operation: <intersect | union
             :                             ;    | only_preferred | only_nonpreferred>,
Similar here. I don't think we'd pass codecs along that are not in both lists. It seems possible by setting only_preferred, or only_nonpreferred that could occur. For instance if pending has alaw,ulaw and configured has alaw,g722 and if prefer: pending, operation: only_preferred then alaw,ulaw are sent in the outgoing sdp which I don't think is correct. Unless I am misunderstanding.

I think "union" here could cause similar (as I understand union to be everything in set A + everything in set B). If pending has codecs not in configured those should be removed from the joint list, and not included.


https://gerrit.asterisk.org/c/asterisk/+/14629/2/configs/samples/pjsip.conf.sample@867 
PS2, Line 867: ;incoming_answer_codec_prefs=; This is a string that describes how the codecs
             :                              ; specified in an incoming SDP answer (pending)
             :                              ; are reconciled with the codecs specified on an
             :                              ; endpoint (configured) when receiving an SDP
             :                              ; answer.
I would have expected this option to relate to the answer sent in response to an incoming offer? To me "incoming" relates to the incoming side of a call from an Asterisk perspective.


https://gerrit.asterisk.org/c/asterisk/+/14629/2/configs/samples/pjsip.conf.sample@879 
PS2, Line 879: ;outgoing_answer_codec_prefs=; This is a string that describes how the codecs
             :                              ; that come from the core (pending) are reconciled
             :                              ; with the codecs specified on an endpoint
             :                              ; (configured) when sending an SDP answer.
Similar, I would expect this to relate to the outgoing side of the call's answer. Seems like this description would be for "incoming_answer_codec_prefs" and those here?



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/14629
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: I920ba925d7dd36430dfd2ebd9d82d23f123d0e11
Gerrit-Change-Number: 14629
Gerrit-PatchSet: 2
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-Reviewer: Kevin Harwell <kharwell at digium.com>
Gerrit-Comment-Date: Tue, 07 Jul 2020 20:37:31 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20200707/fada06c2/attachment-0001.html>


More information about the asterisk-code-review mailing list