|Summary:||ASTERISK-17789: [patch] Peer address always overwritten by contact address|
|Reporter:||Byron Clark (byronclark)||Labels:|
|Date Opened:||2011-05-03 13:14:25||Date Closed:||2011-07-26 13:08:32|
|Environment:||Attachments:||( 0) use_sip_nat_force_rport.patch|
|Description:||In asterisk 184.108.40.206.3 setting nat=yes in sip.conf resulted in the ipaddr field of a realtime peer being used as the addr field in the sip_peer structure.|
In asterisk 220.127.116.11 I'm seeing that the address in the fullcontact field is being used regardless of the nat setting in sip.conf, except during registration when the rport option is present.
I've attached a patch (against 1.8 svn) that uses SIP_NAT_FORCE_RPORT for the overwrite check in build_peer instead of SIP_NAT_RPORT_PRESENT. SIP_NAT_FORCE_RPORT is set by the nat option in sip.conf and appears to be what most users of the 1.6.2 flag SIP_NAT_ROUTE were changed to.
|Comments:||By: Byron Clark (byronclark) 2011-05-05 10:23:13|
My apologies, I've searched about how this should work now and, after reading https://wiki.asterisk.org/wiki/display/AST/Reviewboard+Usage , I'm still not quite sure what to do now.
This bug has been moved to "ready for review" status. Does that mean I should submit the patch for review on reviewboard or does that need to be done by a committer?
By: Jonathan Rose (jrose) 2011-06-08 11:19:29.711-0500
Could be done by you, as long as you have a reviewboard account or wanted to make one. I'll go ahead and have a look though and post it on reviewboard if it looks right.
By: Jonathan Rose (jrose) 2011-06-14 11:31:11.146-0500
I've reviewed the patch and Russell agrees with the intent of it, and I've checked it to make sure it seems right, and as it was it turned out that the check itself was just redundant anyway, so I'm committing this change. Thanks.
By: Byron Clark (byronclark) 2011-07-26 10:22:27.282-0500
It looks like this was resolved on the 1.8 branch by r323371, but the commit never made it to JIRA to close the issue.
By: Jonathan Rose (jrose) 2011-07-26 13:08:32.917-0500
Resolved back in June through clone, closing parent issue.