[asterisk-dev] Answering SDP video 0 to video 0 Offer (or why Lync cannot get user off on-hold)

[Walter Doekes]

Hi,

I was trying to find out why my Asterisk and a Lync server are
arguing over the on-hold state.

* During a re-INVITE on-hold request, the Lync server sends
   "m=video 0" in its offer. (After answering our video offer with
   a 0 port on 200 earlier.)
* Asterisk fails to reply with "m=video 0" in its answer because
   there was no video set up in the first place.
* The Lync server thinks that the on-hold offer was rejected.

Now asterisk has put the caller (A) on hold, but the callee (B)
behind the Lync cannot get A back, because the Lync thinks that
A is not on-hold at all. See log [1].


Disabling the video support for this peer was the quick fix, but
I'd prefer something better.

After scouring through the SDP RFCs [2], I found this in rfc3264
8.2:

> A stream that is offered with a port of zero MUST be marked with port
> zero in the answer.

That's not what we do when there is no video set up: see [3] and
[4].

Instead, we say "Ignoring video media offer because port number
is zero", and ignore the video.


Changing this would meet two of my goals:

(1) I'd like to get rid of the WARNING which really isn't worthy
     of the warning status.

(2) Replying with "m=video 0" will probably make the Lync happy
     and won't hurt.

I see that there are significant changes in 11&trunk in this area
that probably already fix it. (r369028 and reviewboard 1988)


Does anyone care for a fix for this issue for 1.8 and 10?

(And can I tone down the WARNING to a VERBOSE in all branches?)


Regards,
Walter Doekes
OSSO B.V.


[1] Example log:

> [2012-10-12 14:38:29] VERBOSE[25970] app_dial.c:     -- SIP/LYNC-000028c6 is ringing
> ...
> [2012-10-12 14:38:31] WARNING[25066] chan_sip.c: Ignoring video media offer because port number is zero
> [2012-10-12 14:38:31] VERBOSE[25970] app_dial.c:     -- SIP/LYNC-000028c6 answered Local/ID14091 at trunkaccount-590d;2
> [2012-10-12 14:38:31] VERBOSE[25969] app_dial.c:     -- Local/ID14091 at trunkaccount-590d;1 answered SIP/BACKEND-000028c5
> ...
> [2012-10-12 14:38:36] WARNING[25066] chan_sip.c: Ignoring video media offer because port number is zero
> [2012-10-12 14:38:36] VERBOSE[25970] res_musiconhold.c:     -- Started music on hold, class 'default', on Local/ID14091 at trunkaccount-590d;2

at this point, SIP/BACKEND is on-hold, but SIP/LYNC thinks it isn't.


[2] Relevant RFCs:

   2327 "SDP: Session Description Protocol"

   3264 "An Offer/Answer Model with [.. SDP]"
        claims to obsolete rfc2543 (old SIP) ?!

   (3266 "Support for IPv6 in [.. SDP]")

   4317 "SDP Offer/Answer Examples"

   4566 "SDP: Session Description Protocol"
        obsoletes 2327 and 3266


[3] chan_sip.c:process_sdp

   if (x == 0) {
     ast_log(LOG_WARNING, "Ignoring video media offer because port 
number is zero\n");
     continue;
   }
   ...
   p->offered_media[SDP_VIDEO].order_offered = ++numberofmediastreams;


[4] chan_sip.c:add_sdp

   if (...p->offered_media[SDP_VIDEO].order_offered...)
     ...
     if (p->offered_media[SDP_VIDEO].order_offered == i)
       ...
       if (!needvideo)
         ...
         add "m=video 0 RTP/AVP %s\r\n"