[asterisk-users] outgoing sip calls work; incoming calls fail

[listmail at websage.ca]

On Wed, 14 Oct 2009 11:51:02 +0200
Ivan Stepaniuk <ivan at albafotonica.com> wrote:

> listmail at websage.ca wrote:
> > On Sat, 10 Oct 2009 18:02:04 -0700
> > listmail at websage.ca wrote:
> > 
> >> On Sun, 11 Oct 2009 02:11:47 +0200
> >> Ivan Stepaniuk <ivan at albafotonica.com> wrote:
> >>
> >>> listmail at websage.ca wrote:
> >>>> On the LAN side I can see the INVITE and OKAY messages which end
> >>>> with a CANCEL, apparently initiated by the Asterisk gateway.
> >>>>
> >>>> On the WAN side I can see that my Asterisk gateway is repeatedly
> >>>> sending OKAY messages in response to the INVITE from my ITSP. I
> >>>> assume the trouble is that these messages are either not getting
> >>>> back to my provider or something is blocking the confirmation
> >>>> from them. This more or less confirms what was seen in the sip
> >>>> debug trace as well.
> >>> Post that SIP message from the CLI (sip debug), try adding 
> >>> "externip=XXX.XXX.XXX.XXX" (your external/public IP address) to
> >>> your sip.conf global section, asterisk may be including it's
> >>> private address in the OKAY sent to your provider.
> >>>
> >>>
> >>
> >> Here's the last message in sip debug before it gives up:
> >>
> >> ...
> >>
> >> Retransmitting #6 (no NAT) to 66.51.127.173:5060:
> >> SIP/2.0 200 OK
> >> Via: SIP/2.0/UDP
> >> 66.51.127.173;branch=z9hG4bKee03.6a63373.0;received=66.51.127.173
> >> Via: SIP/2.0/UDP
> >> 66.51.127.163:5080;rport=5080;branch=z9hG4bKpae7KcSeB2Bte
> >> Record-Route: <sip:66.51.127.173;lr;ftag=9Z5N4eayXp3Qm> From:
> >> "2508864577" <sip:2508864577 at 66.51.127.163>;tag=9Z5N4eayXp3Qm To:
> >> <sip:12504129568 at 66.51.127.173>;tag=as32af6364 Call-ID:
> >> b734bd26-2fae-122d-91a5-653b331e358a CSeq: 121440337 INVITE
> >> User-Agent: Asterisk PBX 1.6.0.15 Allow: INVITE, ACK, CANCEL,
> >> OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces,
> >> timer Require: timer
> >> Session-Expires: -1;refresher=uas
> >> Contact: <sip:12504129568 at 96.50.76.138>
> >> Content-Type: application/sdp
> >> Content-Length: 262
> >>
> >> v=0
> >> o=root 992672626 992672626 IN IP4 96.50.76.138
> >> s=Asterisk PBX 1.6.0.15
> >> c=IN IP4 96.50.76.138
> >> t=0 0
> >> m=audio 15550 RTP/AVP 0 101
> >> a=rtpmap:0 PCMU/8000
> >> a=rtpmap:101 telephone-event/8000
> >> a=fmtp:101 0-16
> >> a=silenceSupp:off - - - -
> >> a=ptime:20
> >> a=sendrecv
> >>
> >> ---
> >> [Oct  9 12:42:47] WARNING[1056]: chan_sip.c:2917 retrans_pkt:
> >> Maximum retries exceeded on transmission
> >> b734bd26-2fae-122d-91a5-653b331e358a for seqno 121440337 (Critical
> >> Response) -- See doc/sip-retransmit.txt. [Oct  9 12:42:47]
> >> WARNING[1056]: chan_sip.c:2944 retrans_pkt: Hanging up call
> >> b734bd26-2fae-122d-91a5-653b331e358a - no reply to our critical
> >> packet (see doc/sip-retransmit.txt). Scheduling destruction of SIP
> >> dialog '4e8ef1b977bf0e062212334634080665 at 192.168.11.1' in 6400 ms
> >> (Method: INVITE)
> >>
> >> ...
> >>
> >> 66.51.127.173 is my provider's SIP server
> >> 66.51.127.163 is my provider's RTP server
> >>
> >> I even check DNS to make sure both forward and reverse records
> >> jive. 
> >>
> >> Externip was a good suggestion, and worth a try, though because I'm
> >> registering with my provider and using dynamic=yes, wouldn't they
> >> just reply to that anyway, especially given that the registration
> >> works fine? 
> >>
> >> Anyway, after adding externip=<my-external-ip> to [general] and
> >> doing a sip reload in the console the problem remains...
> >>
> > 
> > 
> > [Bumping this in the hope that someone might have some new insight
> > or suggestions since I posted this on a holiday weekend (in my part
> > of the world anyway)...]
> 
> I was staring at the SIP transcript and I don't see anything wrong,
> I'm out of suggestions, except that you could analyze and compare the
> packets when your phone is connected directly (if it's physically
> possible). I hope someone throws some light over this.
> 


Ivan,

Thanks for the sympathetic words. After studying the configuration
until I was ready to scream and testing everything I could think of I
came to the conclusion that it was not likely my very simple setup
that was to blame. I opened a ticket with my ITSP and although they were
initially quite eager to help, we ultimately couldn't sort it out. I
figure they think it's all my fault <shrug>.

I moved to another provider with nearly the same configuration and
interestingly enough, the problem disappeared. Wish I knew why it
failed in the first place but on the other hand I'm happy that I at
least have a working phone system once again and can get back to my
regular job.

Thanks again for your interest in trying to help.

GM

-- 
   
Greg Maruszeczka