asterisk users - Apr 2004 - Repeated Notice: (UN/REACHABLE)

-----Original Message-----
From: asterisk-users-admin@lists.digium.com
[mailto:asterisk-users-admin@lists.digium.com]On Behalf Of Adam
Goryachev
Sent: Wednesday, April 21, 2004 2:29 AM
To: asterisk-users@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....



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.

-sb

> -----Original Message-----
> From: asterisk-users-admin@lists.digium.com
> [mailto:asterisk-users-admin@lists.digium.com]On Behalf Of Adam
> Goryachev
> Sent: Wednesday, April 21, 2004 2:29 AM
> To: asterisk-users@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