[Asterisk-code-review] res pjsip: Re-use IP version of signaling (SIP) for media (R... (asterisk[13])

[Alexander Traud]

Alexander Traud has posted comments on this change.

Change subject: res_pjsip: Re-use IP version of signaling (SIP) for media (RTP).
......................................................................


Patch Set 1:

Actually, I was about the other way around: SIP = IPv6 and RTP = IPv4. Are both scenarios a use-case or just the one you mention? How does that work in SIP/SDP - are there any guides somewhere on the Internet or other implementations which do it this way, so I can read into that topic myself. Or stated differently: I played around with it here in my Asterisk and it did not work, yet.

> Since the automatic support takes precedence

Please, when you propose something be a concrete as possible, even a stomach feeling example normally helps me to understand the scenario better. For example, when you propose a pjsip.conf parameter, simply make up a name. Even if it is a first shot, that helps me to work it out, determine what you are looking for and what style you use for parameters. For me as external contributor this is very complicated because I have to look at all the other parameters to understand the style, to avoid review ping pong. I do not have a bird's eye view on the project.

For example, I am guessing wild now: If you like, I raise the priority of rtp_ipv6 again, so it is able to overwrite this automatic behavior. Consequently, when rtp_ipv6=yes or rtp_ipv6=no is specified, the corresponding version is used. When rtp_ipv6 is not specified, 'automatic' is assumed. Or do you want me to keep the default to 'no' and create a new third state 'automatic'. Or do you want me to create a complete new parameter with default 'no' and if set 'automatic'?

> it's a behavior change nonetheless with no ability to change it.

Looking through all the documentation, I did not find a single guide or wiki how to enable res_pjsip for IPv4/IPv6 Dual Stack. Consequently until last week, res_pjsip was used either IPv4 or IPv6. Looking at that and because determining the IP version was not available back when this code was written (that via Via stuff was introduced just recently), there was no way to determine the intention of the administrator. Therefore, a variable rtp_ipv6 was introduced to enable IPv6 even on the RTP layer. Therefore, rtp_ipv6 was used in tandem with an IPv6-only transport.

This was wrong, because res_pjsip should have been Dual Stack from day one, especially because IPv6 is a topic at least since the year 2006. This change/patch actually removes this variable and this bug. Every bug removal is a behavior change. Now, you state that there is a use case and you want to keep rtp_ipv6. OK. I do not understand those use-cases yet, but that is part of the above question. Anyway, please keep in mind that setting up IPv4/IPv6 Dual Stack is complicated. So complicated you did not investigate the actual cause of this issue (and reported it to PJSIP) and even downstream projects like FreePBX gave up on IPv6 with res_pjsip completely, yet: <http://issues.freepbx.org/browse/FREEPBX-10181>.

Normally, IPv4/IPv6 should work out of the box (very much like chan_sip), without requiring obscure configuration parameters. Because this tackles Software Usability here and might create misery for all users (except that target group with your mentioned use case), I please for soul-searching and/or re-asking your colleagues if that is OK with the long term goals of Asterisk. If something is too complicated, near to all administrators might see this as untested or even do not find it, and do not enable it. End-users then do not get IPv6 capable servers or we see even more special domain names with IPv6-only servers. Just because of your mentioned target group.

>From my point of view, rtp_ipv6 was a bug and must be removed. Therefore, please, consider this point of view. If you want me to drive this issue through, we have to respect the misery which is created when adding another parameter. For that, I have to understand and double-check your use-cases first. Because otherwise I give your point of view a +1 indirectly.

-- 
To view, visit https://gerrit.asterisk.org/3663
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I01a85a8c6723fcc12e86139f80e090e2078d04bb
Gerrit-PatchSet: 1
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Owner: Alexander Traud <pabstraud at compuserve.com>
Gerrit-Reviewer: Alexander Traud <pabstraud at compuserve.com>
Gerrit-Reviewer: Anonymous Coward #1000019
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-HasComments: No