[Asterisk-video] app_rtsp: No media found!

Matthew Allen Matthew.Allen at nrc-cnrc.gc.ca
Thu Apr 2 12:37:10 CDT 2009 

Good idea Sergio.

In ethereal it looks like for every packet Asterisk gets from QTSS, it 
sends one out to X-Lite, in proper H.263+ format. X-Lite isn't 
recognizing that it's receiving video. I tried disabling my firewall 
completely, no difference.

Something might be wonky with the feature negotiation, since I can have 
H.263+ video calls with other X-Lite clients through this Asterisk 
instance just fine. So this should be fixable on the server side... 
X-Lite was receiving h263p video from other clients and from mp4_play 
with no problem.

I'll investigate more and see if I come up with anything.

Thanks for your help,
Mat






X-Lite's debug log doesn't say much about video except that it "can't 
locate stream".

Sergio Garcia Murillo wrote:
> Check h263p is enabled in XLite and get an ethereal trace of the call 
> between Asterisk and Xlite to check if rtp packets are correctly sent 
> from Asterisk.
>
> Best regards
> Sergio
>
> Allen, Matthew escribió:
>> Hi Sergio,
>>
>> I think that my sip.conf and X-Lite are configured correctly.  I tried putting videosupport=yes on the user and not just in [general] but it made no difference.  We can have video calls between two X-Lites on this SIP channel and they work.
>>
>> This morning I tried taking out the check completely, and it seems to get past that point fine now.  (Someone else apparently tried this too with the same results: http://www.asteriskguru.com/archives/asterisk-video-amr-audio-continued-vt124127.html )
>>
>> Interestingly, on subsequent calls my debug log gives the right value for chan->nativeformats:
>>
>>     [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:1247 rtsp_play: !!! About to check (sdp->video->formats[0]->format & chan->nativeformats) == (1048576 & 1572868) == 1048576
>>
>> Value 1572868 describes the formats alaw|ulaw|gsm|h263|h263p (as set in my sip.conf).
>>
>> I'm not sure what caused nativeformats to start giving the correct value, but it was either:
>>  * skipping the check caused some necessary SIP setup to happen
>>  * I tried starting my video in X-Lite while it was doing the GetUdpPorts dance, before app_rtsp, which might have kicked in my video support.  (But this was never necessary for normal video calls, or for mp4_save or mp4_play).
>>
>> However, even though nativeformats is correct now, and it gets past that check, I still see no video in X-Lite.
>>
>> It seems to set the write format to h263p only (there is no audio in the stream), talks about some rtp packets for a second but then switches to ulaw only for some reason.  I never see any video in my client.
>>
>> Any other clues that might help?
>>
>> Thanks for any help,
>>
>> Mat
>>
>> < snip ... this is near where it used to fail, now it continues ... >
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:749 CreateSDP: -line [a=control:trackID=1]
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:1246 rtsp_play: -video [1048576,96,trackID=1]
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:1247 rtsp_play: !!! About to check (sdp->video->formats[0]->format & chan->nativeformats) == (1048576 & 1572868) == 1048576
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:510 RtspPlayerSetupVideo: -SETUP VIDEO [trackID=1]
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:562 RtspPlayerPlay: -PLAY [/10-10-24-160-h263.sdp]
>> [Apr  2 11:04:59] DEBUG[16087]: app_rtsp.c:1395 rtsp_play: -Started playback [0]
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:3174 ast_rtp_write: Ooh, format changed from unknown to h263p
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:3038 ast_rtp_raw_write: Difference is 9000, ms is 0 (0), pred/ts/samples 168210/177210/9000
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:3038 ast_rtp_raw_write: Difference is 9030, ms is 0 (0), pred/ts/samples 276330/285360/9030
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:3038 ast_rtp_raw_write: Difference is 9030, ms is 0 (0), pred/ts/samples 342390/351420/9030
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:3038 ast_rtp_raw_write: Difference is 54090, ms is 0 (0), pred/ts/samples 357390/411480/54090
>> [Apr  2 11:04:59] DEBUG[16087]: rtp.c:1100 ast_rtcp_read: Got RTCP report of 176 bytes
>> [Apr  2 11:05:00] DEBUG[16087]: rtp.c:3038 ast_rtp_raw_write: Difference is 19290, ms is 19 (1710), pred/ts/samples 389160/408450/21000
>> [Apr  2 11:05:00] DEBUG[16087]: chan_sip.c:5754 sip_rtp_read: Oooh, format changed to 2 gsm
>> [Apr  2 11:05:00] DEBUG[16087]: channel.c:3376 set_format: Set channel SIP/mat-082168a0 to read format ulaw
>> [Apr  2 11:05:00] DEBUG[16087]: channel.c:3376 set_format: Set channel SIP/mat-082168a0 to write format ulaw
>> [Apr  2 11:05:01] DEBUG[16087]: rtp.c:1100 ast_rtcp_read: Got RTCP report of 176 bytes
>> [Apr  2 11:05:03] DEBUG[16087]: rtp.c:1100 ast_rtcp_read: Got RTCP report of 176 bytes
>>
>>
>>
>>
>> -----Original Message-----
>> From: asterisk-video-bounces at lists.digium.com on behalf of Sergio Garcia Murillo
>> Sent: Thu 4/2/2009 6:16 AM
>> To: Development discussion of video media support in Asterisk
>> Subject: Re: [Asterisk-video] app_rtsp: No media found!
>>  
>> Hi Matthew,
>>
>> If nativeformats is 4, then there is no videosupport for the channel. 
>> Are you calling with xlite?
>> Try opening the video tab and check that in the SDP there is video 
>> offer. Also try putting the
>> videosupport=yes on the extension and not only on the general part.
>>
>> About the GetUdpPorts, RTSP expect two consecutive udp ports, even for 
>> RTP and odd for RTCP,
>> it should be quite inmediate. Is your machine under heavy load?
>> It is extrange to have so much difference between two sockets creating 
>> them almos consecutively:
>>
>> 6331,54114,55376,58352,60667,33667,58224,58225
>>
>> Best regards
>> Sergio
>>
>> Matthew Allen escribió:
>>   
>>> Hello,
>>>
>>> I'm trying to use Sergio's app_rtsp (latest version) to connect to a
>>> QTSS stream. I'm running Asterisk 1.6.0.
>>>
>>> The stream is video only in H.263+ (H.263-1998) encoding.  My sip.conf
>>> has "videosupport=yes" and "allow=h263p" among other codecs. We can
>>> successfully have video calls using the X-Lite client using H.263+ for
>>> video.  The extension that calls app_rtsp is set up correctly. The
>>> stream should be fine; both Quicktime and VLC play the stream just fine.
>>>
>>> When I call up the extension to test app_rtsp I always get "No media
>>> found".  It doesn't make it past the DESCRIBE request.
>>>
>>> (Also, at the start of the call, there's about 5 to 10 seconds of
>>> repeatedly calling GetUdpPorts before it actually proceeds to the
>>> DESCRIBE.  It could be related to these warnings when I compile:
>>>
>>> app_rtsp.c: In function 'GetUdpPorts':
>>> app_rtsp.c:284: warning: pointer targets in passing argument 3 of
>>> 'getsockname' differ in signedness
>>> app_rtsp.c:287: warning: pointer targets in passing argument 3 of
>>> 'getsockname' differ in signedness
>>> app_rtsp.c:306: warning: pointer targets in passing argument 3 of
>>> 'getsockname' differ in signedness
>>>
>>> ...but I don't think this is the source of my problem.)
>>>
>>> I've been trying to track down where the problem is... I think it might
>>> be on line 1247:
>>>
>>> 1247:    if (sdp->video->formats[i]->format & chan->nativeformats)
>>> 1248:    {
>>>              < ... sets videoType, videoFormat, videoControl ...>
>>> 1257:    }
>>>
>>> That if statement evaluates to false for me.  The video format gets set
>>> properly to 1048576 (which is the bit for H.263-1998), but the value of
>>> chan->nativeformats is 4, whatever that is, so it's false and those
>>> variables never get set.  Later on it decides "no media found".  Do I
>>> need to do something to change the value of chan->nativeformats?
>>>
>>> I'm attaching my debug log, I added a couple of debug statements of my
>>> own (start with !!!).
>>>
>>> Thanks for any help, let me know if I can should any other info,
>>>
>>> Mat
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>>>     
>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-video

More information about the asterisk-video mailing list