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-0600 | Date Closed: | 2013-04-22 09:27:53 | ||||
Priority: | Minor | Regression? | |||||
Status: | Closed/Complete | Components: | Core/Configuration | ||||
Versions: | 11.0.1 | Frequency of Occurrence | |||||
Related Issues: |
| ||||||
Environment: | Gentoo Linux 64 bit PowerPC, kernel 3.6.1, GCC 4.5.3 | Attachments: | ( 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 1.8.17.0 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. Thanks, 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. {noformat} } 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); {noformat} IF NOT isset(SIP_PAGE3_NAT_AUTO_RPORT) THEN unset(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 (172.16.0.33:5060) - Client NAT (95.138.160.45:6789) - My server (88.80.1.50:5060) With "nat=yes" my server sending packet to 95.138.160.45:6789 and this normal, but with "nat=force_rport,comedia" packet sending to 95.138.160.45:5060 and this erroneously. By: Kinsey Moore (kmoore) 2013-03-13 08:06:28.460-0500 Alexandr, 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 sip.conf 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 nat=force_rport,comedia Asterisk #1 (10.10.0.3:5060) - NAT (95.138.160.45:6789) - Asterisk #2 (My Server) (88.80.1.50:5060) With "nat=yes" my server sending packet to 95.138.160.45:6789 and this normal, but with "nat=force_rport,comedia" packet sending to 95.138.160.45:5060 and this erroneously. By: Aleksandr Gordeev (axonaro) 2013-03-19 01:01:33.980-0500 with "sip=yes" {code:xml}<--- SIP read from UDP:95.138.160.45:6789 ---> OPTIONS sip:88.80.1.50 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.33:5060;branch=z9hG4bK7234c042;rport Max-Forwards: 70 From: "asterisk" <sip:asterisk@172.16.0.33>;tag=as7a4f4a22 To: <sip:88.80.1.50> Contact: <sip:asterisk@172.16.0.33:5060> Call-ID: 3a181af619cfeb742df8da847babca49@172.16.0.33:5060 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 1.8.15.0 Date: Tue, 19 Mar 2013 05:52:02 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 <--- Transmitting (NAT) to 95.138.160.45:6789 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.0.33:5060;branch=z9hG4bK7234c042;received=95.138.160.45;rport=6789 From: "asterisk" <sip:asterisk@172.16.0.33>;tag=as7a4f4a22 To: <sip:88.80.1.50>;tag=as12d5101b Call-ID: 3a181af619cfeb742df8da847babca49@172.16.0.33:5060 CSeq: 102 OPTIONS Server: Asterisk PBX 11.2.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Contact: <sip:88.80.1.50:5060> Accept: application/sdp Content-Length: 0{code} with "sip=force_rport,comedia" {code:xml}<--- SIP read from UDP:95.138.160.45:6789 ---> OPTIONS sip:88.80.1.50 SIP/2.0 Via: SIP/2.0/UDP 172.16.0.33:5060;branch=z9hG4bK30f1a216;rport Max-Forwards: 70 From: "asterisk" <sip:asterisk@172.16.0.33>;tag=as0a042694 To: <sip:88.80.1.50> Contact: <sip:asterisk@172.16.0.33:5060> Call-ID: 2bac31670113f59d48c86e6e012ae030@172.16.0.33:5060 CSeq: 102 OPTIONS User-Agent: Asterisk PBX 1.8.15.0 Date: Tue, 19 Mar 2013 05:51:50 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 <--- Transmitting (no NAT) to 95.138.160.45:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.0.33:5060;branch=z9hG4bK30f1a216;rport;received=95.138.160.45 From: "asterisk" <sip:asterisk@172.16.0.33>;tag=as0a042694 To: <sip:88.80.1.50>;tag=as1c414cce Call-ID: 2bac31670113f59d48c86e6e012ae030@172.16.0.33:5060 CSeq: 102 OPTIONS Server: Asterisk PBX 11.2.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Contact: <sip:88.80.1.50:5060> 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: 88.80.1.50:5060 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 : 95.138.160.45 Addr->IP : 95.138.160.45:6789 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. Thanks 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. |