Should support media description with port: 0 (indicates stream should not be used)

[MayamaTakeshi]

Write a test for multiple media where some of them should not be used (port number 0).

[MayamaTakeshi]

From https://www.ietf.org/rfc/rfc3264.txt

 The answer has a matching media
   stream for each stream in the offer, indicating whether the stream is
   accepted or not, along with the codecs that will be used and the IP
   addresses and ports that the answerer wants to use to receive media.

and

A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness,
   since the answer can contain a zero port indicating a rejected stream
   (Section 6). 

So we can set media like this in both offer and answer:

[
  {
    type: "audio",
    port: 0,
    fields: [...]
  },
]

[MayamaTakeshi]

This discussion clarifies things:

https://stackoverflow.com/questions/34508546/sip-offer-answer-model

So, ideally we should match all m= lines in offer and answer. However, for this tool to be more broadly useful we should accept cases when the answer will not have the same number of m= lines as the offer.

[MayamaTakeshi]

In on_media_update, when building the media_update event string, we can use the active local and remove sdps as they are adjusted by pjmedia. For example, this is the SDP we built to reply to an offer with 2 m= lines, but accepting only one of them:

process_media call_id=1 call->local_sdp: v=0^M
o=- 3912367707 3912367707 IN IP4 0.0.0.0^M
s=pjmedia^M
t=0 0^M
m=audio 10004 RTP/AVP 0 8 3 96 97 98 99 9 18 120 121 122^M
c=IN IP4 127.0.0.1^M
b=TIAS:64000^M
a=rtcp:10005 IN IP4 127.0.0.1^M
a=sendrecv^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:8 PCMA/8000^M
a=rtpmap:3 GSM/8000^M
a=rtpmap:96 iLBC/8000^M
a=fmtp:96 mode=30^M
a=rtpmap:97 speex/32000^M
a=rtpmap:98 speex/16000^M
a=rtpmap:99 speex/8000^M
a=rtpmap:9 G722/8000^M
a=rtpmap:18 G729/8000^M
a=rtpmap:120 telephone-event/8000^M
a=fmtp:120 0-16^M
a=rtpmap:121 telephone-event/32000^M
a=fmtp:121 0-16^M
a=rtpmap:122 telephone-event/16000^M
a=fmtp:122 

However, this is what was actually sent:

v=0
o=- 3912367707 3912367708 IN IP4 0.0.0.0
s=pjmedia
t=0 0
m=audio 10004 RTP/AVP 0 120
c=IN IP4 127.0.0.1
b=TIAS:64000
a=rtcp:10005 IN IP4 127.0.0.1
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:120 telephone-event/8000
a=fmtp:120 0-16
m=audio 0 RTP/AVP 0 8 3 96 97 98 99 9 18 120 121 122
c=IN IP4 127.0.0.1
b=TIAS:64000

Notice in particular that an m= line for refused media was added to the SDP.

So my undestanding is that we can trust the offer and answer will be balanced and we can easily build the media_update event string based on them.

[MayamaTakeshi]

To test the port=zero we added this test: samples/two_audio_streams.port_zero.js.future (it currently fails)