[Freeswitch-dev] Issue with Sofia SIP: username and colons
lminiero at gmail.com
Thu Jun 22 08:53:36 UTC 2017
2017-06-21 20:49 GMT+02:00 Michael Jerris <mike at jerris.com>:
> 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..
Yep, I know, but AFAIK there's no repo for Sofia SIP alone, one would have
to grab the whole Freeswitch repo even to just have access to the updated
library, which means I can't just take that and work on it. Same if I
wanted to suggest people to use yours rather than what repos provide (e.g.,
my Fedora 25). Or am I mistaken and there is indeed a way to do that?
> On Jun 21, 2017, at 2:40 PM, Lorenzo Miniero <lminiero at gmail.com> wrote:
> 2017-06-21 19:39 GMT+02:00 Michael Jerris <mike at 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.
>> On Jun 21, 2017, at 1:20 PM, Lorenzo Miniero <lminiero at gmail.com> wrote:
>> 2017-06-21 18:22 GMT+02:00 Michael Jerris <mike at 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:
>> 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).
>>> > On Jun 20, 2017, at 6:24 AM, Lorenzo Miniero <lminiero at gmail.com>
>>> > 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
>>> > 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
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> Official FreeSWITCH Sites
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FreeSWITCH-dev