[VoiceOps] No RTP stream during 183 w/SDP via Peerless?

[Colton Conor]

Are you using Adtran CPE's by chance? There is a SDP 183 early media issue
on some of the latest firmware that to our knowledge hasn't been fixed.
Both in their stable and new releases.

On Wed, Jun 3, 2015 at 2:25 PM, Mark R Lindsey, ECG <lindsey at e-c-group.com>
wrote:

> You need a packet capture from an example SIP/RTP endpoint.
>
> With compliant, Standards-based VoIP, there are lots of ways this can fail
> to work in Real World VoIP. Here are three:
>
> (1) If the calling SIP/RTP endpoint doesn't send an RTP frame to the
> termination device when the calling device receives SDP from the called
> endpoint, then the termination device may never send RTP to the calling
> device. Some of them (e.g., Oracle SBC) can wait until receiving an RTP
> frame to "latch" on the IP and port from which the RTP comes. This is
> intended to accommodate VoIP behind NAT or firewalls, because the IP/port
> in the SDP generally don't match the actual IP/port to be used for media.
>
> (2) If the calling device doesn't send an RTP frame, and the calling
> device is behind a NAT/firewall device, then the NAT/firewall device might
> block any incoming RTP as if it's unauthorized. Most NAT/firewall devices
> don't understand SDP very well.
>
> (3) If Peerless wishes to do asymmetric RTP such that Peerless
> receives RTP at IP1:port1
> but sends from IP2:port2, where
> IP1!=IP2 or port1!=port2,
> i.e., so that they don't use the same IP and port for both sending and
> receiving RTP,
> but your customers are behind a NAT/firewall,
> then your customer's firewalls/NAT *should* block the RTP from peerless.
>
>
>
> In all three of these cases, you can be totally in line with the
> standards, but it can fail to work.
>
>
>
> On Wed, Jun 3, 2015 at 12:02 PM, April Jones <april at teliax.com> wrote:
>
>> I'm out of the media stream on the calls. The customer reports no RTP
>> whatsoever (sounds like it's being misrouted or not otherwise arriving...)
>> SDP on 183 is always missing the a=sendrecv attrib. RFC is kind of
>> unclear of whether sendrecv is necessary, but it feels like sendrecv is
>> assumed. Is that correct? FWIW, CPE SDP in INVITE has a=sendrecv, the
>> attrib is only missing on the 183.
>>
>> On Wed, Jun 3, 2015 at 12:43 PM, Mark R Lindsey <lindsey at e-c-group.com>
>> wrote:
>>
>>> When they send 183 to you with SDP, are you (or your customers CPE)
>>> always sending RTP to Peerless?
>>>
>>> Are all the SDP sent with attribute  a=sendrecv?
>>>
>>>
>>>
>>> On Jun 3, 2015, at 11:32 , April Jones <april at teliax.com> wrote:
>>>
>>> Hi all,
>>>
>>> I'm seeing a rash of calls this week, egressing Peerless, with no RTP
>>> stream during 183. First it looked like multiple vendors (or a CPE issue)
>>> but checking SDP, calls exhibiting the behavior are originating from
>>> Peerless.
>>>
>>> Calls will receive a 183 Progress w/SDP, then 200 OK w/SDP, but no RBT
>>> or media is heard during the 183. Tickets are being opened with Peerless
>>> (and other ULCs who are using Peerless) but I'm curious if this is being
>>> observed elsewhere...
>>>
>>>
>>>
>>>
>>>               --- mailto:mark at ecg.co <mark at ecg.co>
>>>                   tel:+1-229-316-0013
>>>                   http://ecg.co/lindsey
>>>
>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20150604/6232db66/attachment-0001.html>