Summary:	ASTERISK-15720: Buggy parse of request-line in function check_user_full()
Reporter:	nick_lewis (nick_lewis)	Labels:
Date Opened:	2010-03-01 11:26:19.000-0600	Date Closed:	2015-02-25 22:26:31.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Before get_destination() does a proper parsing of the request-line to find the pvt->exten, pvt->domain etc, check_user_full does a buggy parse of it to build a contact. The buggy parser does not correctly handle the userinfo portion of the request-line if it contains a password or a ";" character ****** ADDITIONAL INFORMATION ****** Is getting the pvt->exten at this stage really necessary? Could the contact instead be set to S_OR(peer->username,peer->peername). Does it matter about the user portion of the contact at this stage as long as it is in the correct dialog? If the requested exten does need to be in the contact then the request-line should be parsed properly before check_user_full and get_destination
Comments:	By: Leif Madsen (lmadsen) 2010-03-03 09:44:51.000-0600 Is there a particular problem this is causing, or is this more of a code cleanup issue? By: nick_lewis (nick_lewis) 2010-03-04 08:47:34.000-0600 It does not correctly handle the userinfo portion of the request-line if it contains a password or a ";" character which could be considered a minor bug By: Matt Jordan (mjordan) 2015-02-25 22:26:21.759-0600 I don't think is a bug any longer. The aforementioned function - {{check_user_full}} - should end up calling {{get_in_brackets_full}} to extract the user portion out of the URI. This appears to correctly extract only what is within quotes for the user portion, and not incorrectly skip or stop due to a ';' in between the quotes. If this is still an issue, please comment here and I'll be happy to re-open it. An example of a request that contains a URI that trips the behaviour would be helpful for further analysis.