The log you’re referring to is Asterisk’s. It shows indeed that the incoming message contained a video line but it must be wrong because the outgoing packets sniffed with the Android capture tool did not show any such video line. In addition, tcpdump on Asterisk server did not show any video line in the incoming INVITE from caller either. So Asterisk’s log must be incorrect, I guess.
On looking at https://www.ietf.org/rfc/rfc3264.txt it seems that sending port=0 on the response rejects the stream, even though, on re-invites, this is generally treated as a hold.
Sending it on the initial request doesn’t make sense unless you intend to add it back in a subsequent re-invite.
One significant point is that few people use video, so your chances of finding someone on the forum that both uses video and has any deep knowledge of the code are quire small.
1 Like
My analysis is based not on Asterisk’s log but on the actual packets sniffed out from the calling SIP phone and into Asterisk. There is absolutely no video line in the actual incoming SDP. Also, tcpdump and wireshark showed that the outgoing INVITE sent less than a second later from Asterisk IP to callee IP did contain the video line. So Asterisk must have added the line itself. There are no other possibilities in IMHO. It is what the actual sniffed packets show, not Asterisk’s log which I believe is inaccurate in this case.
Moreover, the add_sip() function is definitely buggy as you noticed and it is actually being called from many functions, specifically functions which transmit INVITE and re-INVITE messages as I mentioned in a previous reply here. The bug has obviously the effect of appending the video line to the SDP. I have no doubt about that.
I will surely report the bug asap to issues.asterisk.org and will also patch it meanwhile myself (by replacing tmpcap with p->caps in the second condition), recompile everything and test it. I will let you know.
Thank you very much! I really appreciate your help.
All the ast_format_cap_ is new since I last looked at this area in depth, and then only for audio, but I think the bug in the code only affects the correct generation of debugging log messages.
Asterisk logs the incoming request so early in the processing that it doesn’t even know which peer it relates to, let alone whether there is video involved.
The incoming packets from peer A into Asterisk show no video line, as captured by tcpdump. How would you explain that?
Something added it between tcpdump and Asterisk. There is simply not enough intelligence between where the socket is read and Asterisk writing the log, for it to have added anything to the incoming request.
In any case, looking more deeply at the code, your B side behaviour looks like it would be the result of setting videosupport=always in sip.conf. This causes video to be negotiated unconditionally on outgoing calls.
Responding with m=video 0 … is expected if m=video appears in the incoming request, but doesn’t create a stream.
I have no idea about anything between tcpdump and Asterisk which could have added the video line. Why would anything add such a line anyway? Are you sure the log creation functions are not calling buggy add_sdp()?
I have videosupport=yes in sip.conf. Didn’t know about the always value.
Anyway, I will patch the code and give it a try next week.
Thanks
On further consideration, I’m not sure that videosupport looks at the caller’s capabilities. Asterisk may simply always negotiate video on an outgoing call if the peer supports it. That may be intentional.
But that behavior would result in Asterisk offering video systematically if peer supports it making it impossible to make an audio-only call in such a case. It doesn’t seem really practical to me.