<div dir="ltr"><div>Hi</div><div><br></div><div>Ok the word is final from our interconnect partner that they are unable to change this. The advice from their vendor is:</div><div><br></div><div>
<span style="color:windowtext">- It is not in contravention of the RFC. And it aligns with recommendations for ISDN interworking
to SIP (T-REC-Q.1912.5) for a media gateway interworking function between SIP and ISUP.</span> <br></div><div><br></div><div>This is a significant issue and would mean that we would not be able to use the pro or carrier version ultimately either presumably? This is an interconnect with by far the largest carrier here who have this as their standard signalling across any interconnect they have with any other operator. The question remains though that if it is not in violation of RFC (and according to them recommended in their particular environment), should it not work regardless of it being silly?</div><div><br></div><div>Regards</div><div>Theo<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 17, 2019 at 1:06 PM qabane me <<a href="mailto:qabaneitsolutions@gmail.com">qabaneitsolutions@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi</div><div><br></div><div>We still live in some hope that the interconnect partner will change this but so far now joy. They seem to not be wrong though:</div><div><br></div><div>
"This only happens when the call is not
answered. Based on the RFC we are not out of specification"</div><div>and</div><div>"
<span style="font-family:"Arial",sans-serif">According to Section 15 of RFC3261, callee (UAS)
MUST NOT send a BYE on early dialogs, but the caller (UAC)
MAY send a BYE to terminate early dialogs.</span>"</div><div><br></div><div>So while what they do is completely out of the ordinary, our interconnect agreement is guided by the RFC and we therefore cannot force them to change this. As this is an interconnect between 2 carriers, not just a chosen carrier, there is no alternative here.</div><div><br></div><div>If indeed this is allowed as per RFC - is it then not the case that sipwise is not handling this correctly as even though not usual, it should still be able to deal with it?</div><div><br></div><div>Is my reasoning correct?</div><div><br></div><div>Regards</div><div>Theo<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2019 at 4:15 PM qabane me <<a href="mailto:qabaneitsolutions@gmail.com" target="_blank">qabaneitsolutions@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi</div><div><br></div><div>I agree but that's not possible. This is the NATIONAL carrier, like a Vodafone in the UK.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2019 at 4:10 PM Daniel Grotti <<a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
you should better change your carrier then in this case.<br>
Nobody is using BYE to cancel early state calls in SIP.<br>
<br>
<br>
Cheers,<br>
<br>
<br>
Daniel Grotti<br>
<br>
Head of Customer Support Sipwise GmbH<br>
e: <a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a> Europaring F15<br>
t: +43(0)130120332 A-2345 Brunn Am Gebirge<br>
w: <a href="http://www.sipwise.com" rel="noreferrer" target="_blank">www.sipwise.com</a> FN: 305595f FG: LG Wiener Neustadt<br>
<br>
On 5/14/19 4:02 PM, qabane me wrote:<br>
> Hi<br>
> <br>
> The carrier in question is not very helpful and while we are still <br>
> trying to get them to change this, for the moment they are refusing, citing:<br>
> <br>
> AS per RFC 5407 ( The caller MAY send a BYE in the Early state, even though this behavior is not recommended. A BYE sent in the Early state terminates the early dialog using a specific To tag)<br>
> <br>
> This is causing phones to keep on ringing upon the bye. If they really <br>
> will not change their behaviour, how do I change ours so that we don't <br>
> have that issue?<br>
> <br>
> <br>
> On Fri, May 10, 2019 at 4:46 PM qabane me <<a href="mailto:qabaneitsolutions@gmail.com" target="_blank">qabaneitsolutions@gmail.com</a> <br>
> <mailto:<a href="mailto:qabaneitsolutions@gmail.com" target="_blank">qabaneitsolutions@gmail.com</a>>> wrote:<br>
> <br>
> Thanks Daniel!<br>
> <br>
> On Fri, May 10, 2019 at 4:16 PM Daniel Grotti <<a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a><br>
> <mailto:<a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a>>> wrote:<br>
> <br>
> Hi,<br>
> in general chapter 15 of RF3261, here an extract:<br>
> <br>
> <br>
> "The notion of "hanging up" is not well defined within SIP. It is<br>
> specific to a particular, albeit common, user interface.<br>
> Typically, when the user hangs up, it indicates a desire to<br>
> terminate the attempt to establish a session, and to<br>
> terminate any<br>
> sessions already created. For the caller's UA, this<br>
> would imply a<br>
> CANCEL request if the initial INVITE has not generated a<br>
> final<br>
> response, and a BYE to all confirmed dialogs after a final<br>
> response. For the callee's UA, it would typically imply<br>
> a BYE;<br>
> presumably, when the user picked up the phone, a 2xx was<br>
> generated, and so hanging up would result in a BYE after<br>
> the ACK<br>
> is received."<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Daniel Grotti<br>
> <br>
> Head of Customer Support Sipwise GmbH<br>
> e: <a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a> <mailto:<a href="mailto:dgrotti@sipwise.com" target="_blank">dgrotti@sipwise.com</a>> <br>
> Europaring F15<br>
> t: +43(0)130120332 A-2345 Brunn Am Gebirge<br>
> w: <a href="http://www.sipwise.com" rel="noreferrer" target="_blank">www.sipwise.com</a> <<a href="http://www.sipwise.com" rel="noreferrer" target="_blank">http://www.sipwise.com</a>> FN: 305595f FG:<br>
> LG Wiener Neustadt<br>
> <br>
> On 5/10/19 3:34 PM, qabane me wrote:<br>
> > Hi<br>
> ><br>
> > On of our interconnects sends calls to us. When the caller<br>
> cancels the<br>
> > call before a session is established, they send us a BYE.<br>
> That should be<br>
> > a CANCEL as far as I know. This is causing issues with the<br>
> callee's<br>
> > phone continuing to ring. I am trying to argue with them but<br>
> they are<br>
> > saying it's allowed. I am trying to check the RFCs but am not<br>
> finding<br>
> > ammunition. Does any one have a link to show that indeed I am<br>
> right and<br>
> > they are wrong? (assuming that I am)<br>
> ><br>
> > So the scenario is:<br>
> > image.png<br>
> ><br>
> > _______________________________________________<br>
> > Spce-user mailing list<br>
> > <a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a> <mailto:<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a>><br>
> > <a href="https://lists.sipwise.com/listinfo/spce-user" rel="noreferrer" target="_blank">https://lists.sipwise.com/listinfo/spce-user</a><br>
> ><br>
> _______________________________________________<br>
> Spce-user mailing list<br>
> <a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a> <mailto:<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a>><br>
> <a href="https://lists.sipwise.com/listinfo/spce-user" rel="noreferrer" target="_blank">https://lists.sipwise.com/listinfo/spce-user</a><br>
> <br>
</blockquote></div>
</blockquote></div>
</blockquote></div>