Bug in asterisk? Register string ignores port

First I will apologize for the double post as this was posted to aah forums: sourceforge.net/forum/forum.php? … _id=420324
However, this seemed to be more fitting here (Note, I have removed the portion about a possible amp bug)

I am hoping that I am doing something wrong and that this is not a bug but given the sketchey success reports for vbuzzer and other sip providers that use non-standard ports, I am guessing we are dealing with a bug specific to some versions of asterisk.

I am using aah 2.7, and have tested this on aah 2.6. Both have the same issue.

Asterisk seems to be ignoring the :port option in the register string. I am trying to get vbuzzer working which uses port 80, not 5060.

So, I configure this register string:
username:password:username@vbuzzer.com:80

The product in sip.conf is (which should be fine):
register=username:password:username@vbuzzer.com:80

Then I do a: sip debug ip vbuzzer.com
This error is the result:
SIP Debugging Enabled for IP: 209.47.41.48

Retransmitting #3 (NAT) to 209.47.41.48:5060:
REGISTER sip:vbuzzer.com SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK5a9d558d;rport
From: sip:########@vbuzzer.com;tag=as2e5ad0a2
To: sip:#########@vbuzzer.com
Call-ID: 77ece06633c13df71e60df4f28957c73@
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Expires: 120
Contact: <sip:@>
Event: registration
Content-Length: 0

You will notice that it is still trying to register on port 5060 (in the first line of the debug)

I have also tried changing the register to: register => username:password:username@vbuzzer.com:port
register => username:password:username@vbuzzer.com:port/extension

Nothing seems to change it.

Thanks
Lance

[quote=“lrissman”]First I will apologize for the double post as this was posted to aah forums: sourceforge.net/forum/forum.php? … _id=420324
However, this seemed to be more fitting here (Note, I have removed the portion about a possible amp bug)

I am hoping that I am doing something wrong and that this is not a bug but given the sketchey success reports for vbuzzer and other sip providers that use non-standard ports, I am guessing we are dealing with a bug specific to some versions of asterisk.

I am using aah 2.7, and have tested this on aah 2.6. Both have the same issue.

Asterisk seems to be ignoring the :port option in the register string. I am trying to get vbuzzer working which uses port 80, not 5060.

So, I configure this register string:
username:password:username@vbuzzer.com:80

The product in sip.conf is (which should be fine):
register=username:password:username@vbuzzer.com:80

Then I do a: sip debug ip vbuzzer.com
This error is the result:
SIP Debugging Enabled for IP: 209.47.41.48

Retransmitting #3 (NAT) to 209.47.41.48:5060:
REGISTER sip:vbuzzer.com SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK5a9d558d;rport
From: sip:########@vbuzzer.com;tag=as2e5ad0a2
To: sip:#########@vbuzzer.com
Call-ID: 77ece06633c13df71e60df4f28957c73@
CSeq: 103 REGISTER
User-Agent: Asterisk PBX
Max-Forwards: 70
Expires: 120
Contact: <sip:@>
Event: registration
Content-Length: 0

You will notice that it is still trying to register on port 5060 (in the first line of the debug)

I have also tried changing the register to: register => username:password:username@vbuzzer.com:port
register => username:password:username@vbuzzer.com:port/extension

Nothing seems to change it.

Thanks
Lance[/quote]

Yes, this is Asterisk’s bug! But I found workaround - use construction like this:

register => username:password:username@peer_name

[peer_name]
...
host=xxx.xxx.xxx.xxx
port=80
...

It works fine at least in Asterisk 1.2.4. Hope this helps…

[quote=“kokoska.rokoska”]

Yes, this is Asterisk’s bug! But I found workaround - use construction like this:

register => username:password:username@peer_name

[peer_name]
...
host=xxx.xxx.xxx.xxx
port=80
...

It works fine at least in Asterisk 1.2.4. Hope this helps…[/quote]

Absolutely this worked… now to debug the next issue… :smiley:

Does anybody know if this bug has been submitted or how to go about submitting this bug?

I’m also seeing this, and am also using the same “workaround” successfuly. Bugs should go to bugs.digium.com/…. am looking over there to see if it’s reported already.