[asterisk-bugs] [Asterisk 0018172]: Peer goes unreachable when placing a call from it.

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Oct 22 08:03:04 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18172 
====================================================================== 
Reported By:                jordankirby
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18172
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.8.0-rc5 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-20 06:23 CDT
Last Modified:              2010-10-22 08:03 CDT
====================================================================== 
Summary:                    Peer goes unreachable when placing a call from it.
Description: 
We are using 1.8RC5, Asterisk RealTime (MySQL) and realtime caching.
Both the server and the phones are behind separate NAT (phone in office,
server in data centre).

In this example, SIP/3001 calls SIP/3002 (via a gosub). The call proceeds
fine but asterisk sees SIP/3001 as unavailable for a period of time after
the initial invite.

This looks to be because asterisk starts sending OPTIONS and NOTIFIES to
the LAN IP address of the phone rather than it's NATed IP address.

In the attached trace:
  10.50.0.47 is the server's LAN IP.
  212.62.4.230 is the server's NATed IP.
  192.168.1.231 is 3001's LAN IP.
  195.59.152.66 is 3001's NATed IP.

Asterisk output:

  == Using SIP RTP CoS mark 5
    -- Executing [3002 at DLPN_All:1] Gosub("SIP/3001-000000aa",
"internal,3002,1")
    -- Executing [3002 at internal:1] Dial("SIP/3001-000000aa", "SIP/3002")
  == Using UDPTL CoS mark 5
  == Using SIP RTP CoS mark 5
    -- Called 3002
    -- SIP/3002-000000ab is ringing
[Oct 20 12:11:05] NOTICE[24099]: chan_sip.c:24694 sip_poke_noanswer: Peer
'3001' is now UNREACHABLE!  Last qualify: 37
  == Spawn extension (internal, 3002, 1) exited non-zero on
'SIP/3001-000000aa'
    -- Registered SIP '3001' at 195.59.152.66:17261
[Oct 20 12:11:55] NOTICE[24099]: chan_sip.c:19523
handle_response_peerpoke: Peer '3001' is now Reachable. (34ms / 2000ms)

====================================================================== 

---------------------------------------------------------------------- 
 (0128313) pabelanger (manager) - 2010-10-22 08:03
 https://issues.asterisk.org/view.php?id=18172#c128313 
---------------------------------------------------------------------- 
Reopening after a discussion on #asterisk-dev (see below).  I'd like to see
the reporter resolve the nat issue and sip.conf file.

---
<schmidts> pabelanger about issue 18172 do you really think this is a
configuration issue?
<MuffinMan> [closed] [Asterisk] Channels/chan_sip/General 0018172: Peer
goes unreachable when placing a call from it. reported by jordankirby
https://issues.asterisk.org/view.php?id=18172
<pabelanger> schmidts: Until he fixes the nat issue with his phone, no
need to waste time on it.
<pabelanger> I suspect it is a routing issue, asterisk is setting the
option message to the private IP, which is not routed properly.
<schmidts> But should an invite ever change the the IPaddr field of a
peer?
<schmidts> yes, but directly after the invite and before sending a trying
back to the user
<pabelanger> schmidts: I'm not sure honestly. 
<pabelanger> However, looking at this in the log:
<pabelanger> [Oct 20 13:58:25] DEBUG[24099] chan_sip.c: Trying to put
'OPTIONS sip' onto UDP socket destined for 192.168.1.231:17261
<pabelanger> [Oct 20 13:58:25] NOTICE[24099] chan_sip.c: Peer '3001' is
now UNREACHABLE!  Last qualify: 35
<schmidts> yes but, as you can see in the log the dialog itself will go
through the right contact adress
<schmidts> 100 trying, 200 ok, and bye or ACK is sent back to the right
ip, but the internal one is also saved into the pvt structure of the peer
<pabelanger> Ya, but like you pointed out in the SDP, c=IN IP4
192.168.1.231 is an issue
<schmidts> thats only for rtp and has nothing to do with the sip adress
for this pvt
<schmidts> the problem i see with this is if we dont find what cause this
problem it could be a possible way to DOS
<schmidts> if its really a asterisk bug
<pabelanger> schmidts: Fair enough, we can reopen it.  Get more feedback.
<schmidts> will do ;)
<pabelanger> But would like to see him resolve is natting issue first 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-22 08:03 pabelanger     Note Added: 0128313                          
======================================================================




More information about the asterisk-bugs mailing list