|Summary:||ASTERISK-21432: Video isn't negotiated when endpoint switches to video on an established SIP to SIP call|
|Reporter:||Nikita Voloshin (sinoptik)||Labels:|
|Date Opened:||2013-04-15 09:54:20||Date Closed:||2013-06-05 15:58:58|
|Environment:||Server OS: Ubuntu 12.04.2 LTS Client: X-Lite, Jitsi, Linphone||Attachments:||( 0) dump1.pcap|
( 1) dump2.pcap
( 2) dump3.pcap
( 3) dump4.pcap
( 4) extensions.conf
( 5) log-1.txt
( 6) log-2.txt
( 7) log-3.txt
( 8) log-4.txt
( 9) sip_show_peer.txt
|Description:||How to reproduce:
Step 1: Start a conversation between users (User 1, User 2)
Step 2: Try to switch to a video call (User 1)
Video does not start.
I Get this string in log:
"chan_sip.c:13001 add_sdp: This call needs video offers, but caller probably did not offer it!"
*If after Step 2 I try to start video on User 2 it is work fine.
**If I do video call at start, it is work fine.
I think that it is similar to the bug: ASTERISK-14139
My post on forum: [Video didn't work from the first time.|http://forums.asterisk.org/viewtopic.php?f=1&t=86160]
Full log: [http://pastebin.com/whqtkqYb]
Server on public IP
Client behind NAT, ICE enabled
|Comments:||By: Rusty Newton (rnewton) 2013-04-19 15:27:22.034-0500|
Is the behavior the same regardless whether you use h263 or h264 ?
We'll need more information:
Please provide everything we would need to directly reproduce the issue. Please attach the dialplan in use, sip.conf configs, and descriptions of client configs all to the issue in separate .txt files. (More Actions > Attach Files)
Please gather the same log you have in your pastebin, but along with VERBOSE messages enabled. Make sure to capture the entire call from the very beginning to the end. Get a PCAP at the same time.
By: Nikita Voloshin (sinoptik) 2013-05-07 11:39:19.404-0500
I added a logs of the two attempts.
In Log 1 (log-1.txt, dump1.pcap) video does not work, in log 2 (log-2.txt, dump2.pcap) video started to work after the second user sent the request.
OS: Ubuntu 12.04.2 LTS
Asterisk: Asterisk 11.3.0
By: Rusty Newton (rnewton) 2013-05-13 16:53:38.394-0500
It looks like for some reason, Asterisk possibly thinks the other leg of the call is not capable of video and so it appropriately rejects video on the one leg. We need to figure out why it thinks the other side is not capable.
Can you provide the output of "sip show peer <name>" on both peers before the test call where it fails?
Can you also provide a pcap that includes both legs of the call to make this it easier to correlate events on both sides of the call with what is happening in the Asterisk log?
Also, the log file needs to preferably be the same log for the call in the pcap, so that that call-id's and such match up for easier debugging.
By: Nikita Voloshin (sinoptik) 2013-05-27 12:40:55.925-0500
sip show peer 6000333
sip show peer 6000444
By: Nikita Voloshin (sinoptik) 2013-05-27 13:20:37.341-0500
I added new log and pcap,(Log 3/Dump 3, Log 4/Dump 4)
I used this command to make it 'sudo tcpdump -i eth0 -n -s 0 port 5060 -vvv -w /tmp/capture_file_name' is it correct command?
This can help you?
By: Rusty Newton (rnewton) 2013-06-05 15:58:20.792-0500
Thanks for the additional info.
In the cases where it looks like it isn't working for you (Log/Dump 3) it appears that your second endpoint is rejecting the video offer by responding back in the SDP header "m=" with "video 0 RTP/AVP 0"
I'm goign to go ahead and close this issue out for three reasons:
1. This looks like a configuration issue. Asterisk appears to be responding appropriately to the traffic it receives in your PCAPs and logs
When the issue occurs, your endpoint is rejecting the video offer from Asterisk, therefore the other leg shouldn't get setup for video.
3. issues.asterisk.org is not used for support. You'll need to seek support on the [Asterisk users list or forums|http://www.asterisk.org/community/discuss] and try to get a clearer picture of what you feel is a bug before you report it here again.
4. I also noticed that you have VP8 in your codec setup which tells me that you might be using a patched version of Asterisk since Asterisk doesn't have support for that yet. Being that the problem you are having here is concerning video support - if you file a new issue you'll need to verify you are using a vanilla version of Asterisk.
You might try reconfiguring your endpoint, or reconfiguring your codec orders on both Asterisk and the endpoint. If anything, try to simplify the the scenario as much as possible and reduce the number of codecs you are offering to one audio and one video. Then you may get a clearer picture as to what is happening.