<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>ALU Usually just mean Alcatel/Lucent, and they have a number of different models of switches.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>RFC 3398 (Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping) usually makes me think of “SIP-T”, and BroadSoft doesn’t really speak SIP-T (or didn’t when I last looked into it) well enough to handle some of these situations.  I’ve also seen issues with “NPDI” fields that come down to something similar.  More importantly, I don’t think BroadSoft normally benefits in any major way from the extra information SIP-T provides.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>So one thing to check with your ITSP is if they have the trunk built as SIP or SIP-T (or whatever terminology goes with this in their switch).<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If they can re-build your trunk as “plain” SIP, it should stop sending the extra 18X’s because it will no longer be trying to pass along the ISUP information that BroadSoft is likely ignoring or improperly handling anyway.  If you have done any packet captures and see an ISUP body section below the SDP body, this basically confirms they are doing SIP-T with you.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If the AS now has the means to support RFC3398 and you can’t get the ITSP to reconfigure or rebuild the trunk, changing that settings certainly may fix your issue.  My concern about “testing” that on a production system is that the AS may change its behavior in other scenarios where right now its ignoring a value in the SIP-T encapsulated ISUP body, but once it starts paying attention you could have any number of other issues instead or in addition.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Hope that helps,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>-Scott<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> voiceops-bounces@voiceops.org [mailto:voiceops-bounces@voiceops.org] <b>On Behalf Of </b>John Myhre<br><b>Sent:</b> Wednesday, April 25, 2012 12:56 PM<br><b>To:</b> voiceops@voiceops.org<br><b>Subject:</b> Re: [VoiceOps] Broadworks media server not playing well with early media<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>There’s a (ALU?) sip/isup gateway on the far side of the itsp I shipping the call to.  The gateway’s attempt to following rfc 3398, and is therefore mapping isup cpgs to 18x messages.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I’ve gotten pointed to the supportRFC3398 setting under interface>sip on the Broadworks AS.  Setting it to true is supposed to inhibit the AS from attempting to transition the call back to local ring when it receives a 18x message with no sdp, after receiving on with sdp.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>That seems to match my issue.  I’ve got a maintenance window coming up and will see if reality matches the theory.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>/John<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Scott Berkman <a href="mailto:[mailto:scott@sberkman.net]">[mailto:scott@sberkman.net]</a> <br><b>Sent:</b> Tuesday, April 24, 2012 2:01 PM<br><b>To:</b> 'John Myhre'; <a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br><b>Subject:</b> RE: [VoiceOps] Broadworks media server not playing well with early media<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>What is on the network side?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I don’t believe BroadSoft allows for multiple 18X responses, and in my opinion no system should.  Once you have sent an offer, the only way to modify it should be a RE-INVITE.  I believe the RFC’s do technically allow for this though, and in that case the newer 18X message will override/replace the previous.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Another issue may be that 183 messages usually are accompanied with SDP, where 180 message are used when no early media (and therefore no SDP) is to be used.  So a second 183 with no SDP is all kinds of wrong to me.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Hope that helps,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>-Scott<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a> <a href="mailto:[mailto:voiceops-bounces@voiceops.org]">[mailto:voiceops-bounces@voiceops.org]</a> <b>On Behalf Of </b>John Myhre<br><b>Sent:</b> Monday, April 23, 2012 4:19 PM<br><b>To:</b> <a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br><b>Subject:</b> [VoiceOps] Broadworks media server not playing well with early media<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I seem to be having a problem with Broadworks thinking an early media stream has ended.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m sending a call out to the PSTN and receiving back a 183 with SDP (presumably early media).  Broadworks is dutifully passing everything down to the device.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m then receiving a second 183, this time with no SDP (presumably because someone’s gateway received a CPG).  In this case, Broadworks appears to interpret the lack of SDP as meaning the early media has ended (not the case) and plumbs the media server into the bearer path to play ringing.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Anyone run into this problem?  Any ideas for a way around it?  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve found a reference for dealing with this problem from the access side, but not when the 183s are coming from the network side.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m running Broadworks Rel14sp4.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Many thanks for any ideas!<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>/John<o:p></o:p></p></div></body></html>