<div dir="ltr">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. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 2:25 PM, Mark R Lindsey, ECG <span dir="ltr"><<a href="mailto:lindsey@e-c-group.com" target="_blank">lindsey@e-c-group.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You need a packet capture from an example SIP/RTP endpoint.</div><div><br></div><div>With compliant, Standards-based VoIP, there are lots of ways this can fail to work in Real World VoIP. Here are three: </div><div><br></div><div>(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.</div><div><br></div><div>(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.</div><div><br></div><div>(3) If Peerless wishes to do asymmetric RTP such that Peerless </div><div>receives RTP at IP1:port1 </div><div>but sends from IP2:port2, where</div><div>IP1!=IP2 or port1!=port2, </div><div>i.e., so that they don't use the same IP and port for both sending and receiving RTP, </div><div>but your customers are behind a NAT/firewall,</div><div>then your customer's firewalls/NAT *should* block the RTP from peerless.</div><div><br></div><div><br></div><div><br></div><div>In all three of these cases, you can be totally in line with the standards, but it can fail to work.<br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 12:02 PM, April Jones <span dir="ltr"><<a href="mailto:april@teliax.com" target="_blank">april@teliax.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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...)<div>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.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 12:43 PM, Mark R Lindsey <span dir="ltr"><<a href="mailto:lindsey@e-c-group.com" target="_blank">lindsey@e-c-group.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">When they send 183 to you with SDP, are you (or your customers CPE) always sending RTP to Peerless?<div><br></div><div>Are all the SDP sent with attribute a=sendrecv? <div><div><div><br><div>
<div style="background-color:rgb(255,255,255);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="word-wrap:break-word"><font size="1" color="#ff2600"><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span></font></div></div></div><div><blockquote type="cite"><div>On Jun 3, 2015, at 11:32 , April Jones <<a href="mailto:april@teliax.com" target="_blank">april@teliax.com</a>> wrote:</div><br><div><div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>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...</div></div></div></blockquote></div><br></div><div><br></div><div><br></div></div></div><div><div><div style="background-color:rgb(255,255,255);word-wrap:break-word"><div style="word-wrap:break-word"><font size="1" color="#ff2600"><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> ---</span><span style="font-family:Consolas"> </span><font face="Consolas"><a href="mailto:mark@ecg.co" target="_blank">mailto:mark@ecg.co</a> <br></font><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><font face="Consolas">tel:<a href="tel:%2B1-229-316-0013" value="+12293160013" target="_blank">+1-229-316-0013</a> <br></font><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><span style="font-family:Consolas"> </span><font face="Consolas"><a href="http://ecg.co/lindsey" target="_blank">http://ecg.co/lindsey</a> </font></font></div><div style="word-wrap:break-word"><font size="1"><font face="Consolas" color="#ff2600"><br></font></font></div></div><br><br></div></div><div><br></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br></div>