We are effectively upstream for sofia at this point, there are a number of fixes in our tree that are not in their abandoned tree..
On Jun 21, 2017, at 2:40 PM, Lorenzo Miniero <lminiero@gmail.com> wrote:
2017-06-21 19:39 GMT+02:00 Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>>: If you can put a patch together I’m happy to review it…. would simplify our code a bit to use that.
Sure, I'll try to work on one in the next few days. It would be on the plain Sofia SIP source code I have available, though, so I hope that's ok... shouldn't be too hard to adapt to your fork in case it works fine, as I don't expect it to touch much.
L.
On Jun 21, 2017, at 1:20 PM, Lorenzo Miniero <lminiero@gmail.com <mailto:lminiero@gmail.com>> wrote:
2017-06-21 18:22 GMT+02:00 Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>>: The function in play here is: auc_credentials… note the TODO at the top of that function… A new tag that allows for passing those as a structure is probably needed to do this cleaner without issues.
Hi Michael,
yes, that's the function I had identified as well, when debugging. I agree a new tag (or new tags, as I believe multiple ones would be relayed as well, due to how Sofia SIP works internally) would indeed fix the ambiguity here.
Before receiving your answer I also opened an issue on Jira on this: https://freeswitch.org/jira/browse/FS-10415 <https://freeswitch.org/jira/browse/FS-10415>
Apologies for the double post, but I wasn't sure my message here had gone through (it had been in a moderated state for a while).
Lorenzo
On Jun 20, 2017, at 6:24 AM, Lorenzo Miniero <lminiero@gmail.com <mailto:lminiero@gmail.com>> wrote:
Hi,
I'm not sure this is the right place to discuss a potential issue related to Sofia SIP, especially considering I'm going to describe something that happens in another software, but I thought that, considering that Freeswitch uses Sofia SIP as well and has kept it alive so far, it would be of interest to you guys as well, as you may be affected too.
To give you some context, I'm using Sofia SIP in one of the plugins of my WebRTC server, Janus. Specifically, this plugin acts as a SIP client on behalf of WebRTC users, meaning I create NUA instances for them, doing registers, invites and stuff like that from the server side and exposing a simpler API and events (not SIP) to users.
This usually works fine, but I recently encountered a weird problem that can occur when users try to REGISTER and provide a username with a colon in it. This fails, and apparently the cause is in how the NUTAG_AUTH works. As you probably know, NUTAG_AUTH is the tag nua_authenticate requires when answering a REGISTER challenge, and it needs a string that is basically a colon-separated concatenation of digest/realm/user/pass, e.g.:
Digest:"nokia proxy":xyz:secret
This breaks when the username contains a colon, as the method that parses this concatenated string (auc_credentials() in auth_client.c) seems to do a "brutal" split on the colon character. I tried wrapping the username in quotes, but that didn't work, which seems to confirm what the code suggests. Apparently the only way to get Sofia SIP to digest the username with the colon in it, is escaping the colon (%3A) in there, but then this obviously results in a broken authentication when it gets to the registrar, as the usernames differ (ciccio:123 != ciccio%3A123). Some may argue that it should be the registrar's responsibility to unescape the username part, but this is a quoted string in the authorization challenge and not the username part of a URI, so I don't think they're required to do that.
Is this something you encountered as well? Being more of a SIP server, I guess this may be seen as less of an issue in Freeswitch, but it might still occur if/when you're doing active REGISTERs yourself. If it's a known problem, do you happen to know of any workaround that wouldn't require patching auc_credentials to do the right thing? (which might be either changing the delimiter in NUTAG_AUTH to a much less used character, or automatically unescaping %3A internally when formatting the username).
Thanks in advance for any feedback you may have for me! Lorenzo