[asterisk-dev] Intermittent one-way audio and call failure on trunk

[Mark Michelson]

On 07/12/2012 08:37 PM, Paul Belanger wrote:
> On 12-07-12 09:21 PM, Matthew Jordan wrote:
>>
>> <snip>
>>
>>> I'd drop FreePBX and try straight asterisk.  At least this will help
>>> developers try to reproduce the issue.
>>>
>>> Also, is this even a valid SDP?
>>>
>>> ---
>>>
>>> INVITE sip:103 at 192.168.183.144:5060 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.183.1:5060;branch=z9hG4bK437855a3
>>> Max-Forwards: 70
>>> From: "WIRELESS CALLER" <sip:6512454836 at 192.168.183.1>;tag=as36dfaa7e
>>> To: <sip:103 at 192.168.183.144:5060>
>>> Contact: <sip:6512454836 at 192.168.183.1:5060>
>>> Call-ID: 7c6fa93a4befd2de4a279c20428c6a10 at 192.168.183.1:5060
>>> CSeq: 102 INVITE
>>> User-Agent: FPBX-2.10.0(10.0)
>>> Date: Thu, 12 Jul 2012 20:22:41 GMT
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH
>>> Supported: replaces, timer
>>> Content-Type: application/sdp
>>> Content-Length: 1674
>>>
>>> v=0
>>> o=root 241945485 241945485 IN IP4 192.168.183.1
>>> s=Asterisk PBX SVN-trunk-r369995
>>> c=IN IP4 192.168.183.1
>>> t=0 0
>>> m=audio 10634 RTP/AVP 0 18 3 101
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:18 G729/8000
>>> a=fmtp:18 annexb=no
>>> a=rtpmap:3 GSM/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=ptime:20
>>> a=ice-ufrag:4ad9cb956dd68be267c870d710720d32
>>> a=ice-pwd:06ef6d3c320442d9407e11062b9a7e97
>>> a=candidate:Had08679d 1 UDP 2130706431 173.8.103.157 10634 typ host
>>> a=candidate:Hc0a8b701 1 UDP 2130706431 192.168.183.1 10634 typ host
>>> a=candidate:Hc0a8ac02 1 UDP 2130706431 192.168.172.2 10634 typ host
>>> a=candidate:Ha0a0001 1 UDP 2130706431 10.10.0.1 10634 typ host
>>> a=candidate:Had08679d 2 UDP 2130706430 173.8.103.157 10635 typ host
>>> a=candidate:Hc0a8b701 2 UDP 2130706430 192.168.183.1 10635 typ host
>>> a=candidate:Hc0a8ac02 2 UDP 2130706430 192.168.172.2 10635 typ host
>>> a=candidate:Ha0a0001 2 UDP 2130706430 10.10.0.1 10635 typ host
>>> a=sendrecv
>>> m=video 10660 RTP/AVP 99 104
>>> a=ice-ufrag:4719753d76024bab3a6d5d487fcdbcc9
>>> a=ice-pwd:46c323cb23353b5b6ad6669014a1a89e
>>> a=candidate:Had08679d 1 UDP 2130706431 173.8.103.157 10660 typ host
>>> a=candidate:Hc0a8b701 1 UDP 2130706431 192.168.183.1 10660 typ host
>>> a=candidate:Hc0a8ac02 1 UDP 2130706431 192.168.172.2 10660 typ host
>>> a=candidate:Ha0a0001 1 UDP 2130706431 10.10.0.1 10660 typ host
>>> a=candidate:Had08679d 2 UDP 2130706430 173.8.103.157 10661 typ host
>>> a=candidate:Hc0a8b701 2 UDP 2130706430 192.168.183.1 10661 typ host
>>> a=candidate:Hc0a8ac02 2 UDP 2130706430 192.168.172.2 10661 typ host
>>> a=candidate:Ha0a0001 2 UDP 2130706430 10.10.0.1 10661 typ host
>>> a=rtpmap:99 H264/90000
>>> a=rtpmap:104 MP4V-ES/90000
>>> a=sendrecv
>>>
>>
>> Yup, those are ICE candidates.
>>
> What about the two a=sendrecv? I didn't think you could duplicate 
> attributes.
>
> Either way, that is a massive SDP.
>
There are two m= lines, meaning two streams. Each a= line corresponds to 
the preceding m= line. So both the audio and video stream being offered 
are sendrecv.