All things related to multicast

["Lucy E. Lynch" <>]

James -

I'm using both SDR v2.8 and xmim (see:http://videolab.uoregon.edu/mim/)
to try and gather sap announcements on a linux box (redhat 7.1) -
XMIM will collect announcements for a while and then seg faults -
while sdr manages to collect announcements and stay up - but if I
exit and then re-start it dumps core. I currently have cached versions
of both your long & short entries - if I delete the long one from
.sdr/cache then sdr starts up just fine (and reads the short version
with no problem) but is the long version is cached - core dump!

I'm not sure why this is happening - I've had problems in the past
with announcements with high-bit char - maybe this is just another
way that sap is broken -

Can anyone else duplicate my result?

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon

                (541) 346-1774/Cell: 912-7998

On Fri, 10 May 2002, James O. Whitlock wrote:

> Lucy,
>
> I shortened both the title and description and preserved the original
> so I can return to it.  Let me know if that seems to have eliminated
> the problem.  I'll be interested in details and also is why this
> is all of a sudden an issue since we've been using the same announcement
> for a *long* time, probably well over a year, possibly two.  We've also
> been interoperating with a number of I2 sites that way over the same
> time period.  At least one of them, SURFNet, heavily uses the Unix
> tools and never reported problems.  As the announcement notes, that's
> one of our test/development signals and it has actually been on-line
> 24/7 continuously most of the time.
>
> I'm not conversant with Unix but vaguely recall that SDR is the
> tool for picking up announcements.  Is that correct?  What about
> XMIM?
>
> To my knowledge, there are no constraints on field length for either
> of those fields.  Do you know otherwise and can you point me towards an
> appropriate RFC?
>
> I'd like to restore the original description at some point and, if you
> believe the problem is on our end, will want to be able to reproduce
> it.  Aren't you heavily vested in IP/TV as well?
>
> Thanks & Regards,
>
> Jim
>
>
>
> ----- Original Message -----
> From: "James O. Whitlock" 
> <>
> To: "Lucy E. Lynch" 
> <>
> Sent: Thursday, May 09, 2002 6:36 PM
> Subject: Re: USA WNY-HPNVI 24/7 Live Surgery at 1330 EST
>
>
> > Sure.  I won't be able to get to it until later, however.  Sorry, but
> > I'm racing behind for a late meeting now.  I'll be further interested in
> > working with you to appreciate the details of the problem & workaround
> > since the regional groups & global groups I work with all seem to have
> > interests in the IP/TV technology that's the source of the announcement.
> > I'll pick this up later tonight.  Regards -- Jim
> >
> >
> > James O'Connor Whitlock
> > Associate Director of Computing Services
> > Director, WNY High Performance Networked Video Initiative
> > University at Buffalo
> > 248 Computing Center
> > Buffalo, New York  14260
> >
> > http://wny-hpnvi.buffalo.edu/wny-hpnvi/
> > Tel:     (716) 645-3060
> > FAX:     (716) 645-2895
> >
> > ----- Original Message -----
> > From: "Lucy E. Lynch" 
> > <>
> > To: 
> > <>
> > Cc: 
> > <>
> > Sent: Thursday, May 09, 2002 6:01 PM
> > Subject: USA WNY-HPNVI 24/7 Live Surgery at 1330 EST
> >
> >
> > > James -
> > >
> > > This session announcement seems to break SDR/XMIM in a bad way -
> > > I'm not sure why - could you try shortening the info field & see if
> > > that helps?
> > >
> > > Thanks -
> > >
> > > Lucy E. Lynch Academic User Services
> > > Computing Center University of Oregon
> > > 
> > >  (541) 346-1774/Cell: 912-7998
> > >
> > > n=2160921135 2160921135 1020977696 224.2.127.254 9875 127 trusted none
> > > none  noauth noenc notset notset
> > > k=
> > > v=0
> > > o=- 54849 32 IN IP4 ub-iptv-mgr-1.cit.buffalo.edu
> > > s=USA  WNY-HPNVI 24/7 Live Surgery at 1330 EST
> > > i=This is a test and development multicast from the University at
> > > Buffalo's Western New York High Performance Networked Video Initiative 
> > > in
> > > Buffalo, NY. Under usual circunstances, this program will contain sound
> > > and motion 24 hours per day, 7 days per week. The stream is generated by
> > > an IP/TV encoder and server donated by Cisco Corporation. It is a feed
> > > from the WNY-HPNVI head-end H.323 system, a Zydacron Z360 donated by
> > > Viewcommunications, a system integrator/distributor who has been
> > > generously suppporting the developmental efforts of the group since its
> > > inception. The head-end system is normally up and available for
> > > test/development activity 24/7, with a motion source on-camera and a CD
> > > sound source. Remote sites may connect directly to the head-end and 
> > > their
> > > video content will be broadcast on this channel for observation and
> > > monitoring. During live event broadcasts, the head-end system is used 
> > > for
> > > event control and is usually connected, as the stream source and control
> > > point, to the active MCU. Normally, this will be a 1.15 Mbps MPEG-1
> > > stream. A companion low-bandwidth stream, produced by a Windows Media
> > > Player encoder and server donated by Veraview, another supporting
> > > distributor/integrator in Buffalo, NY, is also available and can be 
> > > found
> > > by referring to the WNY-HPNVI Web site at
> > > (http://ub-iptv-mgr-1.cit.buffalo.edu/ wny-hpnvi).
> > > u=http://ub-iptv-mgr-1.cit.buffalo.edu/wny-hpnvi
> > > e=James O. Whitlock 
> > > <>
> > > p=James O. Whitlock <(716) 645-3060>
> > > t=0 0
> > > a=type:broadcast
> > > a=tool:IP/TV Content Manager 3.0.662
> > > a=x-iptv-fwd:128.205.10.64 139.127.182.18 128.205.190.60
> > > m=video 61966 RTP/AVP 32
> > > c=IN IP4 224.2.181.27/127
> > > a=quality:8
> > > a=framerate:30
> > > a=rtpmap:96 WBIH/90000
> > > a=x-iptv-svr:video 128.205.10.64 live
> > > m=audio 26300 RTP/AVP 14
> > > c=IN IP4 224.2.211.209/127
> > > a=rtpmap:96 X-WAVE/8000
> > > a=rtpmap:97 L8/8000/2
> > > a=rtpmap:98 L8/8000
> > > a=rtpmap:9
> > >
> > >
> > >
> > >
> >
> >
> >
>