Summary:	ASTERISK-15128: Placing a URI call fails when URI string contains a non-standard port
Reporter:	test011 (test011)	Labels:
Date Opened:	2009-11-12 14:22:49.000-0600	Date Closed:	2011-06-07 14:00:47
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	You can make a direct URI call with, say, a softphone register to an Asterisk like this, 123@myhome.dyndns.earth with some entry in extensions.conf like this, Dial(${EXTEN}@${SIPDOMAIN},.....) Yes, this works great. Let's assume something else, 123@myhome.dyndns.earth:8777  (notice the port number at the end) This does not work. Because ${SIPDOMAIN} does not have ":8777" part of the URI dialed. It seems Asterisk just throws that part away. If it's not, I guess it's not documented well enough. Some document claims that ${SIPDOMAIN} will contain all the string after '@' But I guess this is not the case. ****** ADDITIONAL INFORMATION ****** If you hardcode the second URI in extensions.conf, it works perfectly. So, it is a matter of parsing rather than something more terrible :) I believe, originally SIPDOMAIN has different meaning, realted to realm, domain entry of sip.conf which does not have to deal with any port number. (Not really sure though) However, as far as direct URI IP calling is concerned, there must be something like ${SIPPORT} or at least in common sense, ":port" part should not be just thrown away. It's never a good idea to ignore user's dialed input data at will.
Comments:	By: Joshua C. Colp (jcolp) 2009-12-02 12:10:00.000-0600 The SIPDOMAIN channel variable is documented as "SIP destination domain of an inbound call". It does not say that it contains everything after @ 'nor does it say that it contains the port. That being said I would suggest using SIP_HEADER to get the To header and use that to place your subsequent outgoing call. By: test011 (test011) 2009-12-02 17:41:48.000-0600 Thank you for the suggestion. That would be a workaround. I haven't thought about that. I wish to make a point that the document does not say anything about domain part of Outbound call URI automatically put into ${SIPDOMAIN} variable either. Not to mention cutting off Port part. Is this designed for some purpose? If there is any purpose in there, leaving the trailing Port info doesn't really make any sense. Asterisk took the whole URI and did parse it into ${EXTEN} and ${SIPDOMAIN} and discarded Port info first place. Should reconstructing it involve Header string hunt? I am sure would like to question the purpose of the design, if it is by design. :) I wonder should getting a user-entered outbound URI as whole be that difficult? By: test011 (test011) 2009-12-05 02:15:45.000-0600 Regarding my previous note, in the asterisk's view point when client enters URI, it can be seen as Inbound, I guess. Making a direct URI call without a trunk configuration may be something out of scope of Asterisk too, even though so many community informers have claimed that Asterisk supports direct URI calling. But it sure looks incomplete when we already have ${EXTEN} and ${SIPDOMAIN} parsed out of entered URI and 'PORT' information just discarded.