[Home]

Summary:ASTERISK-13324: [patch] Specifying a host port number in a registration string causes incorrect port in contact header
Reporter:nick_lewis (nick_lewis)Labels:
Date Opened:2009-01-08 04:19:37.000-0600Date Closed:2009-01-08 14:12:23.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c-contactport.patch
Description:The Register String format is
[transport://]user[:secret[:authuser]]@host[:port][/contact][~expiry]

If a port is specified then it is correctly used for the uri in the request line but it is also incorrectly used for the contact uri in the contact header

For Example if the asterisk unit is at 123.123.123.123:5060 and the host is at 21.21.21.21:5082 then incoming calls try to go to 123.123.123.123:5082 because the contact header is incorrect
Comments:By: nick_lewis (nick_lewis) 2009-01-08 05:22:32.000-0600

I think the problem is this line in the transmit_register function:

p->socket.port = htons(r->portno);

If I understand it correctly p->socket.port is the port of the local socket whereas r->portno is the port of the registrar
By: nick_lewis (nick_lewis) 2009-01-08 06:31:30.000-0600

Please find attached a patch that appears to fix this issue. It simply removes the line of code that makes the incorrect port assignment. It has been tested successfully with asterisk running on port 5060.

I expect that the build_contact function will also work correctly if the contact port needs to be other than 5060.

I will try changing the bindport config parameter to check whether it is ok with asterisk running on other ports. (It may also be worth changing the port bit of the externip config parameter to confirm that it works ok behind a port forwarding firewall with other ports.)
By: nick_lewis (nick_lewis) 2009-01-08 06:48:04.000-0600

Tested successfully with different bindport config parameters. The contact header correctly contains the port as set by the bindport value.
By: Mark Michelson (mmichelson) 2009-01-08 14:12:22.000-0600

Thanks for the effort in tracking this down.

The problem is that if you update your 1.6.0 branch, you'll see that this line has already been removed and has been replaced with some different logic for setting the port. This change was made to correct issue ASTERISK-12835, which appears to be the same as what you have brought up here. As such, I am closing this issue since it appears to be a duplicate. If you find that the fix already in place is not sufficient, then feel free to re-open this ticket.