[asterisk-users] Asterisk 1.8.7.2 now sends rport always

Sun Dec 18 13:22:54 CST 2011

Thanks for answering Kevin.

I guess my eyes were tired the night I started this thread, and yes, it
would be ridiculous that Cisco phones couldn´t do rport. I actually found
that its not the rport parameter, but the UDP ports usage. nat=no receives
the REGISTER with source port 5400 for example, and the VIA header as
1.1.1.1:5060, so the 200 OK goes out with destination port 5060 as well,
this works for the Cisco phone.

nat=yes|force_rport sends the 200 OK out to destination port 5400 instead.

I was aware of the change introduced because it was also mentioned in the
"asterisk-users] Asterisk 1.8.8.0 Now Available" mail a few days ago, so  I
tried nat=no in the peer definition and it didn´t take effect for some damn
reason and I got extra worried for nothing the past 24 hours to the point I
couldn´t sleep (about to deploy 25 new phones with latest asterisk).

Embarrassingly enough,  I just tried the nat=no again both in the general
and peer sections and the blessed phone registered.... My apologies, again,
I wrote the thread late at night probably this blinded me.

Now, one question about a previous answer from you ("It is exactly that;
'force_rport' is now the default....."):

is the trigger for using the source UDP port from the REGISTER, inside the
rport field and inside the destination UDP port of the 200 OK:

   1. The mismatch between the UDP source port of the REGISTER and the VIA
   port?   Or
   2. The fact that the other entity sends an empty rport?
   3. Or any of the above?

Its a difficult question to ask/describe, so if I am not asking correctly
please let me know. Thanks a lot, really.

 José Pablo Méndez

On Sun, Dec 18, 2011 at 12:18 PM, Kevin P. Fleming <kpfleming at digium.com>
wrote:
>
> On 12/18/2011 01:42 AM, José Pablo Méndez Soto wrote:
>
>> I have been testing with Cisco phones and have been able to register
>> them with new firmware 9.2.1 (7911/7945/7970). All worked until I
>> realized that from version 1.8.7.2, the VIA header contains the rport
>> parameter, which breaks the phone registration process. Basically, the
>> device can´t parse the VIA header this way, and when it gets the 200 OK
>> to the REGISTER message containing the rport parameter, it refuses to
>> process the registration internally, although it doesn´t complaint about
>> it and Asterisk shows it as registered.
>
>
> First, let me say that it is pretty ridiculous that Cisco phones refuse
to accept SIP responses with rport parameters in the Via header. But
getting back to your problem... did you read the CHANGES file included with
Asterisk 1.8.7.2? The *only* change between 1.8.7.1 and 1.8.7.2 was
specifically handling of the 'nat' option in chan_sip to address a security
vulnerability, but your message reads as if you are not aware of this.
>
>> Asterisk 1.8.7.1  doesn´t behave this way and all works fine. The
>> documentation about the use of the nat= parameter in sip.conf states:
>>
>> ;        nat = no                ; Default. Use rport*if* the remote
>>
>> side says to use it.
>
>
> This is a bug in the sample configuration file; 'no' is no longer the
default, 'force_rport' is.
>
>
>> I understand that the other side must send an empty rport parameter to
>> report the far end it needs the rport field to be filled in as per the
>> RFC. The IP Phone is not sending the field at all, generating
>> incongruity between the documentation and the real behavior. The only
>> reason I think Asterisk would find the condition to be true, is due to a
>> mismatch between the source port and VIA header ip:port inside the
>> REGISTER message.
>>
>> Could this be the trigger of the 200 OK with rport (and, other SIP
>> messages as well)?
>
>
> It is exactly that; 'force_rport' is now the default, and if you need
'no' behavior, you have to explicitly configure it that way.
>
>
>> Can it be implemented a nat = never option in future releases?
>
>
> There is no need for such an option (which is why it was removed in the
Asterisk 1.6.x timeframe).
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>              http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20111218/3e111821/attachment.htm>