Summary:ASTERISK-20674: nat=force_rport,comedia does not behave the same as nat=yes
Reporter:headphones (headphones)Labels:
Date Opened:2012-11-10 07:15:29.000-0600Date Closed:2013-04-22 09:27:53
Versions:11.0.1 Frequency of
duplicatesASTERISK-21225 [patch] Setting nat=force_rport in [general] sip.conf will never work
is related toASTERISK-21225 [patch] Setting nat=force_rport in [general] sip.conf will never work
Environment:Gentoo Linux 64 bit PowerPC, kernel 3.6.1, GCC 4.5.3Attachments:( 0) ASTERISK-20674_debug.diff
( 1) Asterisk-debug-1-nat-yes-outgoing.log
( 2) Asterisk-debug-2-nat-yes-incoming.log
( 3) Asterisk-debug-3-nat-forcerportcomedia-outgoing.log
( 4) Asterisk-debug-4-nat-forcerportcomedia-incoming.log
Description:After an upgrade from to 11.0.1 we get warnings about the deprecation of nat=yes in sip.conf:
{{\[Nov 10 14:02:14\] WARNING\[28487\]: sip/config_parser.c:812 sip_parse_nat_option: nat=yes is deprecated, use nat=force_rport,comedia instead}}

If we change to nat=force_rport,comedia the behavior seems to be fine, except for outside users behind NAT. Our server is also behind NAT.

When an outside NAT:ed user calls in to the network everything works as expected, but when calling the outside user, or when two outside NAT:ed users call each other, the audio only goes one way without any errors shown in the console. When changing back to nat=yes, everything work again.

By looking in the source code for sip/config_parser.c, it seems like the reason for the difference is that when using sip=yes, the auto_force_rport and auto_comedia are cleared from &flags\[2\]. However, when using force_rport,comedia, the auto equivalents are not cleared away.
Comments:By: Michael L. Young (elguero) 2012-11-10 21:52:33.985-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Can you also help clarify if you are setting "nat=" in the general section only, in the peers section or both general and peers?  Also, what is the combination that is causing this issue between the general setting and the peer?

By: headphones (headphones) 2012-11-11 05:01:58.831-0600

I've attached four log files, two with nat=yes and two with nat=force_rport,comedia. The outgoing logs are made when a user inside the same network as the server calls to an outside user behind a NAT. The incoming logs are from when the same ouside user calls into the server network.

In Asterisk-debug-3-nat-forcerportcomedia-outgoing.log the audio can't be heard by any part. In the other logs everything works as expected. In some cases the audio seems to go one way only, but I couldn't seem to reproduce this case now.

The nat= option is set at the same place in both cases, and only in the \[general\] part of sip.conf, along with externaddr=, localnet= and directmedia=no.

By: Walter Doekes (wdoekes) 2012-11-11 07:10:10.713-0600

Hm.. I was messing with these exact same options recently. I don't like how unintuitive the nat settings are either.

Logically, I'd say that:

nat=(void) should mean: clear out all

and then add all settings as provided.. now there's some obscure logic going on that rates the auto stuff higher than the original  options.

By: Luigo (luigohuerta) 2012-11-20 16:06:29.807-0600

I'm having exactly the same issue. One-way audio with two NAT'd users. I'm running r376345.
A sip.conf setting of nat=yes throws the deprecation warning. Changing it to 'force_rport, comedia' avoids the warning message but it doesn't work.


By: Kinsey Moore (kmoore) 2012-11-27 10:48:51.467-0600

Hi headphones,
Could you try the patch I just attached?  It should resolve the issues that you're seeing with force_rport and comedia usage.  Anyone else is welcome to try the patch as well.

By: headphones (headphones) 2012-11-27 14:10:13.697-0600

Yes, the patch seems to work fine for us. Thanks! I'm not sure if it changes anything else though, that could affect other users.

By: Walter Doekes (wdoekes) 2012-11-27 15:06:58.800-0600


That patch looks like a no-op to me.
} else if (!strcasecmp(this, "force_rport") && !ast_test_flag(&flags[2], SIP_PAGE3_NAT_AUTO_RPORT)) {
ast_set_flag(&flags[0], SIP_NAT_FORCE_RPORT);
+ /* In case someone did something dumb like nat=auto_force_rport,force_rport */
+ ast_clear_flag(&flags[2], SIP_PAGE3_NAT_AUTO_RPORT);


By: Luigo (luigohuerta) 2012-11-27 15:59:47.146-0600

Kinsey, many thanks. The patch is working for me too.

By: Kinsey Moore (kmoore) 2012-11-28 07:47:52.031-0600

Walter: Good point, and removing that test would invalidate the current documentation.

Luigo and headphones: could you remove the patch and verify that you can reproduce the problem without it?

By: headphones (headphones) 2012-11-28 11:10:11.132-0600

The patch doesn't seem to be what made it work for me. I could reproduce the problem both with and without the patch, but I don't really know why and when it happens.

By: Kinsey Moore (kmoore) 2012-11-28 12:46:24.982-0600

I have deleted the patch since I don't think that's the issue here at all.

In debug #3, it appears that Asterisk is sending the ACK for the outbound call to the 192.x.x.x local address instead of the remote natted endpoint's external address.  In debug #1, the ACK goes to the correct address.

I have some more digging to do before I know more about why this is happening.

By: Kinsey Moore (kmoore) 2012-11-28 14:36:46.516-0600

I have attached a new patch that adds additional debugging to several places in handle_response_invite in an attempt to track down where the address is actually getting changed.  When you have the time, please apply the patch and try to reproduce the problem.

By: headphones (headphones) 2012-12-04 15:00:19.135-0600

Well, I'm not sure if this really is a problem anymore. It seems like this only happens when the peers' registration time out (or maybe disconnect, not sure). After I've decreased the maxexpiry setting, the problems seems to be gone.

By: Kinsey Moore (kmoore) 2013-01-02 09:34:44.237-0600

Since it seems that this is not actually a bug, I'm closing the issue as such.

By: Aleksandr Gordeev (axonaro) 2013-03-05 02:22:36.630-0600

Same trouble on asterisk 11.2

By: Aleksandr Gordeev (axonaro) 2013-03-06 05:23:19.865-0600

In my case

Client ( - Client NAT ( - My server (

With "nat=yes" my server sending packet to and this normal, but with "nat=force_rport,comedia" packet sending to and this erroneously.

By: Kinsey Moore (kmoore) 2013-03-13 08:06:28.460-0500

This issue describes a configuration problem with the maxexpiry setting.  Please adjust that setting and if you are still having problems unrelated to that setting, open a new issue.

By: headphones (headphones) 2013-03-13 09:31:01.308-0500

Well, we still get some seemingly random reports with calls not working, but I haven't managed to reproduce one under normal circumstances. However, I've noticed that after issuing a "sip reload", calls fail in a similar way, until both clients re-register.

By: Michael L. Young (elguero) 2013-03-13 10:14:10.942-0500

@headphones: keep an eye on issue ASTERISK-21225.  That should help cleanup some issues with setting NAT properly when it comes to the global settings.  Also, ASTERISK-20904 had a bit of cleanup to the NAT settings for peers. Hopefully once the first issue I mentioned is resolved along with the second one (which already was resolved), those random reports of calls not working will go away.

By: Aleksandr Gordeev (axonaro) 2013-03-18 02:07:47.599-0500

"This issue describes a configuration problem with the maxexpiry setting. Please adjust that setting"

What value is the most appropriate ?

By: Aleksandr Gordeev (axonaro) 2013-03-18 06:40:38.067-0500


maxexpiry=900                 ; Maximum allowed time of incoming registrations (seconds)
minexpiry=60                   ; Minimum length of registrations (default 60)
defaultexpiry=600              ; Default length of incoming/outgoing registration

Asterisk #1 ( - NAT ( - Asterisk #2 (My Server) (

With "nat=yes" my server sending packet to and this normal, but with "nat=force_rport,comedia" packet sending to and this erroneously.

By: Aleksandr Gordeev (axonaro) 2013-03-19 01:01:33.980-0500

with "sip=yes"
{code:xml}<--- SIP read from UDP: --->
OPTIONS sip: SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK7234c042;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@>;tag=as7a4f4a22
To: <sip:>
Contact: <sip:asterisk@>
Call-ID: 3a181af619cfeb742df8da847babca49@
User-Agent: Asterisk PBX
Date: Tue, 19 Mar 2013 05:52:02 GMT
Supported: replaces, timer
Content-Length: 0

<--- Transmitting (NAT) to --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK7234c042;received=;rport=6789
From: "asterisk" <sip:asterisk@>;tag=as7a4f4a22
To: <sip:>;tag=as12d5101b
Call-ID: 3a181af619cfeb742df8da847babca49@
Server: Asterisk PBX 11.2.0
Supported: replaces, timer
Contact: <sip:>
Accept: application/sdp
Content-Length: 0{code}

with "sip=force_rport,comedia"
{code:xml}<--- SIP read from UDP: --->
OPTIONS sip: SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK30f1a216;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@>;tag=as0a042694
To: <sip:>
Contact: <sip:asterisk@>
Call-ID: 2bac31670113f59d48c86e6e012ae030@
User-Agent: Asterisk PBX
Date: Tue, 19 Mar 2013 05:51:50 GMT
Supported: replaces, timer
Content-Length: 0

<--- Transmitting (no NAT) to --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK30f1a216;rport;received=
From: "asterisk" <sip:asterisk@>;tag=as0a042694
To: <sip:>;tag=as1c414cce
Call-ID: 2bac31670113f59d48c86e6e012ae030@
Server: Asterisk PBX 11.2.0
Supported: replaces, timer
Contact: <sip:>
Accept: application/sdp
Content-Length: 0{code}

With "REGISTER" situation same as "OPTIONS".

By: Walter Doekes (wdoekes) 2013-03-19 03:43:38.529-0500

I'm reopening this. If Kinsey closed this because the topic changed, he should alter the subject/description.

By: Michael L. Young (elguero) 2013-03-19 09:57:57.310-0500

@Alexandr:  Try applying the patches on ASTERISK-20904 and ASTERISK-21225 to your Asterisk 11.2.0 box.  See if that helps clear this up for you.

If not, what are your NAT settings?  [general] section and the peer.  What does "sip show settings" show?  What does "sip show peer <peername>" show?

By: Aleksandr Gordeev (axonaro) 2013-03-20 01:11:31.910-0500

{quote}what are your NAT settings ?{quote}
I'm setting NAT parameter only in [General] section.
{code}asterisk -rx "sip show settings"

Global Settings:
 UDP Bindaddress:
 TCP SIP Bindaddress:    Disabled
 TLS SIP Bindaddress:    Disabled
 Videosupport:           No
 Textsupport:            No
 Ignore SDP sess. ver.:  No
 AutoCreate Peer:        Off
 Match Auth Username:    Yes
 Allow unknown access:   No
 Allow subscriptions:    No
 Allow overlap dialing:  No
 Allow promisc. redir:   No
 Enable call counters:   No
 SIP domain support:     No
 Realm. auth:            No
 Our auth realm          asterisk
 Use domains as realms:  No
 Call to non-local dom.: Yes
 URI user is phone no:   No
 Always auth rejects:    Yes
 Direct RTP setup:       No
 User Agent:             Asterisk PBX 11.2.0
 SDP Session Name:       Asterisk PBX 11.2.0
 SDP Owner Name:         root
 Reg. context:           (not set)
 Regexten on Qualify:    No
 Trust RPID:             No
 Send RPID:              No
 Legacy userfield parse: No
 Send Diversion:         Yes
 Caller ID:              asterisk
 From: Domain:          
 Record SIP history:     Off
 Call Events:            Off
 Auth. Failure Events:   Off
 T.38 support:           Yes
 T.38 EC mode:           Redundancy
 T.38 MaxDtgrm:          -1
 SIP realtime:           Disabled
 Qualify Freq :          60000 ms
 Q.850 Reason header:    No
 Store SIP_CAUSE:        No

Network QoS Settings:
 IP ToS SIP:             CS0
 IP ToS RTP audio:       CS0
 IP ToS RTP video:       CS0
 IP ToS RTP text:        CS0
 802.1p CoS SIP:         4
 802.1p CoS RTP audio:   5
 802.1p CoS RTP video:   6
 802.1p CoS RTP text:    5
 Jitterbuffer enabled:   No

Network Settings:
 SIP address remapping:  Disabled, no localnet list
 Externhost:             <none>
 Externaddr:             (null)
 Externrefresh:          10

Global Signalling Settings:
 Codecs:                 (gsm|ulaw|alaw|h263|testlaw)
 Codec Order:            none
 Relax DTMF:             No
 RFC2833 Compensation:   No
 Symmetric RTP:          Yes
 Compact SIP headers:    No
 RTP Keepalive:          0 (Disabled)
 RTP Timeout:            60
 RTP Hold Timeout:       120
 MWI NOTIFY mime type:   application/simple-message-summary
 DNS SRV lookup:         No
 Pedantic SIP support:   Yes
 Reg. min duration       60 secs
 Reg. max duration:      900 secs
 Reg. default duration:  600 secs
 Sub. min duration       60 secs
 Sub. max duration:      900 secs
 Outbound reg. timeout:  20 secs
 Outbound reg. attempts: 0
 Notify ringing state:   Yes
   Include CID:          No
 Notify hold state:      No
 SIP Transfer mode:      closed
 Max Call Bitrate:       384 kbps
 Auto-Framing:           No
 Outb. proxy:            <not set>
 Session Timers:         Accept
 Session Refresher:      uas
 Session Expires:        1800 secs
 Session Min-SE:         90 secs
 Timer T1:               500
 Timer T1 minimum:       100
 Timer B:                32000
 No premature media:     Yes
 Max forwards:           70

Default Settings:
 Allowed transports:     UDP
 Outbound transport:     UDP
 Context:                default
 Record on feature:      automon
 Record off feature:     automon
 Force rport:            Auto (No)
 DTMF:                   rfc2833
 Qualify:                0
 Keepalive:              0
 Use ClientCode:         No
 Progress inband:        Never
 Language:               ru
 Tone zone:              ru
 MOH Interpret:          default
 MOH Suggest:            
 Voice Mail Extension:   asterisk

Asterisk ending (0).{code}
{code}asterisk -rx "sip show peer office"

 * Name       : office
 Description  :
 Secret       : <Set>
 MD5Secret    : <Not set>
 Remote Secret: <Not set>
 Context      : from-office
 Record On feature : automon
 Record Off feature : automon
 Subscr.Cont. : <Not set>
 Language     : ru
 Tonezone     : ru
 AMA flags    : Unknown
 Transfer mode: closed
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    :
 Pickupgroup  :
 Named Callgr :
 Nam. Pickupgr:
 MOH Suggest  :
 Mailbox      :
 VM Extension : asterisk
 LastMsgsSent : 0/0
 Call limit   : 50
 Max forwards : 0
 Dynamic      : No
 Callerid     : "" <>
 MaxCallBR    : 384 kbps
 Expire       : -1
 Insecure     : no
 Force rport  : Auto (No)
 Symmetric RTP: Yes
 ACL          : Yes
 DirectMedACL : No
 T.38 support : Yes
 T.38 EC mode : Redundancy
 T.38 MaxDtgrm: -1
 DirectMedia  : No
 PromiscRedir : No
 User=Phone   : No
 Video Support: No
 Text Support : No
 Ign SDP ver  : No
 Trust RPID   : No
 Send RPID    : No
 Subscriptions: No
 Overlap dial : No
 DTMFmode     : rfc2833
 Timer T1     : 500
 Timer B      : 32000
 ToHost       :
 Addr->IP     :
 Defaddr->IP  : (null)
 Prim.Transp. : UDP
 Allowed.Trsp : UDP
 Def. Username: office
 SIP Options  : replaces replace timer
 Codecs       : (g729)
 Codec Order  : (g729:20)
 Auto-Framing :  No
 Status       : OK (3 ms)
 Useragent    :
 Reg. Contact :
 Qualify Freq : 60000 ms
 Keepalive    : 0 ms
 Variables    :
                FAXOPT(gateway) = yes
 Sess-Timers  : Accept
 Sess-Refresh : uas
 Sess-Expires : 1800 secs
 Min-Sess     : 90 secs
 RTP Engine   : asterisk
 Parkinglot   :
 Use Reason   : No
 Encryption   : No

Asterisk ending (0).{code}

By: Michael L. Young (elguero) 2013-03-20 11:15:46.134-0500

-What are you setting it to under [general]?-

If the above sip settings is based on "nat=force_rport,comedia", you would benefit from the patches that I posted earlier.  In ASTERISK-21225, https://issues.asterisk.org/jira/secure/attachment/46729/asterisk-21225-handle-options-default-prob_v3.diff is for Asterisk 11.  That is the patch that fixes the _default_ global setting not being overridden by what is in the sip.conf file.

By: Aleksandr Gordeev (axonaro) 2013-03-22 03:00:12.548-0500

On Asterisk 11.2.0 without patch
{code}Force rport  : Auto (No){code}
On Asterisk 11.2.1 with patch
{code}Force rport  : Yes{code}

By: Michael L. Young (elguero) 2013-03-25 15:47:15.845-0500

Alexandr:  There is a lot of missing context with your last post.  I feel like we are starting to turn this issue into a support conversation rather than the issue at hand.

If you have any success or fail comments that you would like to add in regards to the the patch that I felt would solve your issue, please do so by commenting on ASTERISK-21225.  Detailed information is very benefecial to help us understand how / why things didn't work if the patch did not solve the issue.


By: Aleksandr Gordeev (axonaro) 2013-04-01 01:33:58.461-0500

With patch work as expected. Thanks.

By: Rusty Newton (rnewton) 2013-04-02 15:41:11.204-0500

@headphones can you confirm if the latest patch from ASTERISK-21225 appears to resolve your issue? If it does not, can you confirm if the behavior has changed from your previously submitted log files and if you are able to reproduce it? (perhaps then submit a new log file and describe the current behavior).

If that patch does resolve the issue then we will close this out as a duplicate of ASTERISK-21225 based on the other users experiences with similar symptoms and the patch resolving their issues.

If the patch does not resolve your issue and your issue is reproducible then we'll continue to investigate here with your new logs.

By: Rusty Newton (rnewton) 2013-04-22 09:27:53.866-0500

We believe this issue duplicates ASTERISK-21225 and is fixed with the patch on that issue. Closing this out.