[asterisk-bugs] [Asterisk 0016235]: Placing a URI call fails when URI string contains a non-standard port

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16235 
====================================================================== 
Reported By:                test011
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   16235
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           SVN 
JIRA:                       SWP-419 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-11-12 14:22 CST
Last Modified:              2009-12-07 14:09 CST
====================================================================== 
Summary:                    Placing a URI call fails when URI string contains a
non-standard port
Description: 
You can make a direct URI call with, say, a softphone register to an
Asterisk like this,

123 at myhome.dyndns.earth

with some entry in extensions.conf like this,

Dial(${EXTEN}@${SIPDOMAIN},.....)

Yes, this works great. Let's assume something else,

123 at 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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-07 14:09 lmadsen        Status                   assigned => closed  
2009-12-07 14:09 lmadsen        Resolution               reopened => no change
required
======================================================================