[Asterisk-Users] Repeated Notice: (UN/REACHABLE)

[Robert Hajime Lanning]

> -----Original Message-----
> From: asterisk-users-admin at lists.digium.com
> [mailto:asterisk-users-admin at lists.digium.com]On Behalf Of Adam
> Goryachev
> Sent: Wednesday, April 21, 2004 2:29 AM
> To: asterisk-users at lists.digium.com
> Subject: Re: [Asterisk-Users] Repeated Notice: (UN/REACHABLE)
>
>
> Should this actually attempt more than a single ping before claiming the
> remote is unreachable?
> ie, one packet (out of the two - one request + one reply) might be lost
> or intermittent congestion might be involved.
>
> Perhaps a config option for setting number of consecutive ping requests
> are un-responsive. Also, subsequent requests might be sooner than
> otherwise queued.
>
> ie, successfully answered probes are re-sent every 60 seconds, while
> after an un-successful probe, we re-send the next probe in 10
> seconds....
>
> Just my 0.02c worth....

That would be more robust/quicker to recover.  You do have to remember that
the RTP session (when you make a call) does not try to recover.  So, usually
when the SIP poke fails, the RTP would be of bad quality.

<quote who="Bisker, Scott (7805)">
> On a somewhat related note.  I was experiencing some random SIP UN/REACHABLE
> messages during random points during the day.  This would also come
> hand-in-hand with poor SIP call quality (jitters, stutters, etc).  Yesterday I
> was tryint to debug a choppy SIP phone and it just so happened that I was in
> my lab , and noticed that we were using Ghostcast server over multicast to
> send images to some new PCs.  On a whim, I cancelled the ghostcast session and
> the problem immediatly vanished.  Must be a misconfig on the switch (Cisco Cat
> 4500 with all copper 10/100/1000 ports ) cause the switch load was minimal,
> but somehow the multicast traffic was screwing with the SIP transmission over
> the wire.  Just something for other people to look for.

You would need to configure the switch for IGMP snooping and the ghost clients
need to send multicast group membership requests, that the switch will be able
to snoop.  Otherwise multicast traffic is broadcast to every active port.  So,
it is not the switch that is being overrun, it is your SIP endpoints, that are
flooded with the ghost traffic.

-- 
END OF LINE
       -MCP