[Spce-user] blank calls

[Lorenzo Mangani]

Matthew,

If you can replicate/catch the issue with the user and have mediaproxy in
the path and know the port/ip, you might be able to see if either end is
not active by checking out the internal RTP statistics for the endpoint:
# cat /proc/mediaproxy/0/list

Not an optimal method since it requires you to be witnessing the problem as
it happens, but just in case it helps in your research,

Best,

Lorenzo Mangani
QXIP - Network Engineering


On Fri, May 18, 2012 at 2:15 PM, Andrew Pogrebennyk <
apogrebennyk at sipwise.com> wrote:

> Matthew,
> we don't do the RTP activity detection yet (although it's on our todo
> list). To detect when one of the parties is down on the SIP level make
> sure to enable SST (config.yml should have session_timer.enable: yes).
>
> To find when the parties stop sending the RTP traffic just use tcpdump
> or wireshark. Tshark can write to capture "ring buffer" of multiple
> files that are automatically rotated if you have much traffic, e.g.:
> tshark -b filesize:10000 -b files:50 -w spce_tshark.pcap port not 22
> BR,
> Andrew
>
> On 05/18/2012 12:09 PM, Matthew Ogden wrote:
> > If I am getting dead calls periodically. How would I go about
> > investigating deeper that from the SPCE side, if both parties were
> > sending RTP traffic and so forth? (and the bytes count etc)
> >
> >
> >
> > I have attached the proxy log, and replaced My tel, their CLI, my IP
> > there IP etc to try and make it more readable.
> >
> >
> >
> > The call was ended by the subscriber hanging up.
> >
> >
> >
> > Kind Regards
> >
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>



--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20120518/535bb8af/attachment-0001.html>