<div dir="ltr"><div dir="ltr">On Wed, Nov 27, 2019 at 7:16 AM Jaco Kroon <<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>> wrote:</div><div dir="ltr"><br></div><div><snip></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <p> </p>
              <p>Then also, I think I've asked this before, and it
                wasn't possible, but maybe things have changed.</p>
              <p>Is it possible to possible to vary endpoint parameters
                based on the used transport?  For example:</p>
              <p>When using SIP/WSS ice_support = yes, else ice_support
                = no (as but one example).</p>
              <p>Another idea is to somehow manipulate different
                transports into different endpoints, eg:</p>
              <p>[user-rtc]<br>
                type=endpoint<br>
                ice_support=yes<br>
              </p>
              <p>[user-tls]<br>
                type=endpoint<br>
                ... params for tls</p>
              <p>Possibly point them all at the same AOR.</p>
              <p>But the I need support from transport to either prefix
                or suffix the username or the realm with a defined
                string, eg:</p>
              <p>[tls]<br>
                type=transport<br>
                username_sufix=-tls<br>
              </p>
              <p>To suite the above.</p>
              <p>The other alternative is to vary this client-side ...
                which is potentially very error prone (but which I'll do
                to test the concept at least).  For now the urgent one
                for me to sort out is the ICE candidate selection.<br>
              </p>
              <p>Happy to write the patches, would just like to set the
                direction correct first.</p>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Noone has written such functionality.</div>
        </div>
      </div>
    </blockquote>
    <p>Happy.</p>
    <p>I'd like to take a crack at this.  I think manipulating the
      username might be simpler and affect far less code at the end. 
      Your opinion on this, and an indication of where to get started
      would be greatly appreciated.</p></div></blockquote><div><br></div><div>I don't deploy this, so you'd probably want feedback from people who are doing similar things as to whether it is actually viable/useful for them. From a high level perspective as a user it feels strange to place further meaning into the name of the endpoint with the transport as well, but that's just me. As for implementation the entire endpoint identification mechanism is pluggable and a standalone module[1] can be written. Writing a new one is one method, or extending an existing one. For adding options to transports you'd need to extend the transport[2], and then you'd have to determine what transport matches the one the request came in on.</div><div><br></div><div>Extending endpoint specific options to transports is also extremely complicated because things just are fundamentally not written that way on purpose. You don't know what transport is used until a message is sent (unless explicitly configured), and the transport can end up changing.</div><div><br></div><div>[1] <a href="https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_endpoint_identifier_user.c">https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_endpoint_identifier_user.c</a></div><div>[2] <a href="https://github.com/asterisk/asterisk/blob/master/res/res_pjsip/config_transport.c">https://github.com/asterisk/asterisk/blob/master/res/res_pjsip/config_transport.c</a></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Senior Software Developer</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at</font> <a href="http://www.sangoma.com/" style="color:rgb(17,85,204)" target="_blank">www.sangoma.com</a></div></div></div></div></div></div></div></div></div></div>