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

[Mark R Lindsey, ECG]

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
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20150603/cabe613d/attachment.html>