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...
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 tel:+1-229-316-0013 http://ecg.co/lindsey
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
Remember that SDP answers and offers only concern what the peer wants to receive, and never what it will send. Thus, the vendor has absolutely no obligation to send you RTP after 183+SDP. 18x+SDP as an indicator of forthcoming early media is a convention only, and not a protocol or interoperability requirement. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
On 06/03/2015 03:02 PM, April Jones wrote:
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?
Correct. Per RFC 3264 Section 5.1 ("Unicast Streams"): If the offerer wishes to both send and receive media with its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default. But note, as I said in my previous reply, that any SDP answer present in the 183 is merely a declaration of how the terminating gateway would like to receive media, and says nothing about sending it. In the same section: For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. Moreover, RFC 3960, which deals with early media in SIP explicitly, states: Therefore, by only looking at the SIP signalling, a UAC cannot be sure whether or not there will be early media for a particular session. The UAC needs to check if media packets are arriving at a given moment. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
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
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
Did this clear for you? What was the final resolution? On Wed, Jun 3, 2015 at 2:32 PM, 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...
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
It's cleared up, the ticket response was "route advanced." When pressed on the issue, "it was isolated to a ulc." ...helpful. On Jun 5, 2015 6:34 AM, "Pete E" <peeip989 at gmail.com> wrote:
Did this clear for you? What was the final resolution?
On Wed, Jun 3, 2015 at 2:32 PM, 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...
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (5)
-
abalashov＠evaristesys.com -
april＠teliax.com -
colton.conor＠gmail.com -
lindsey＠e-c-group.com -
peeip989＠gmail.com