Summary:	ASTERISK-06816: alphanumeric username in register to Sip-Proxy (sip.conf) makes [/extension] not working
Reporter:	Thomas Meier (thmeier)	Labels:
Date Opened:	2006-04-19 17:01:38	Date Closed:	2006-05-05 12:20:56
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	If the username in the register to an SIP-Proxy is only alphanumeric the jump to the [/extension] is ignored. register => user:password@provider.com/200 register => user:password@provider.com/s It looks only for extension "user" and is ignoring 200 or anything else If user is numeric it works as expected: register => 44198:password@provider.com/200 This jumps to 200.
Comments:	By: Joshua C. Colp (jcolp) 2006-04-19 19:07:02 Are these to the same provider? By: Thomas Meier (thmeier) 2006-04-20 01:02:45 I do not have two accounts at the same provider with numeric and alphanumeric username. But I have tested this with four different Provider: www.sparvoip.com alphanumeric username -> not working www.t-online.de numeric username -> working www.bluesip.net alphanumeric username -> not working fwd.pulver.com numeric username -> working By: Serge Vecher (serge-v) 2006-05-04 13:58:52 It is unclear to me how this is a problem with Asterisk. Looks like it is a problem of a specific provider. Can you show that this is a problem within Asterisk with a trace of a sip registration? By: Andrey S Pankov (casper) 2006-05-04 16:00:29 It can be a bit unclear what vechers says. You need to issue 'sip debug' at the cli prompt. By: Thomas Meier (thmeier) 2006-05-05 11:24:48 OK, it seemed to be that the problem is happened at the registration. The working provider will make an proper registration and notice the requested extension and the not working provider is ignoring this. So Asterisk is handling the incomming call as an anonymous call. Some kind of warning for this registrytion would be helpfull, because the dialplan has to be adjusted to receive calls from this provider. I have extracted the relevant information. If you need more, please request. working example: numeric_user:pw:auth_user@sip-proxy/numeric_extension Register OK with: Contact: <sip:numeric_extension@myIP>;expires=605 Call comes in with: To: <sip:numeric_extension@myIP> Found peer 'sip-proxy' Looking for numeric_extension in Right_context (domain IP_Provider) not working example: alpha_numeric_user:pw:auth_user@sip-proxy/numeric_extension Register OK with: Contact: sip:80.239.235.200:5060 Call comes in with: To: <sip:alpha_numeric_user@connectionserver.sparvoip.de:5060> Contact: sip:Anonymous@194.120.0.202:5060 Found peer 'sip-proxy' Looking for alpha_numeric_user in Right_context (domain connectionserver.sparvoip.de) Contact: <sip:alpha_numeric_user@myIP> By: Joshua C. Colp (jcolp) 2006-05-05 12:20:55 It's up to the person configuring the system to know how calls from their provider are going to come in. Even though you have found a way to differentiate the way that provider will send calls does not mean it is applicable to others. Putting in something in chan_sip to this effect could just lead to other issues with other individuals stating, "it told me to do this - but it didn't work - instead this happens!" because while your check may have been fine, the provider may still send calls differently. To that effect I am closing this bug out.