[Spce-user] Upstream sends Bye instead of cancel
qabane me
qabaneitsolutions at gmail.com
Tue May 28 03:13:36 EDT 2019
Hi
Ok the word is final from our interconnect partner that they are unable to
change this. The advice from their vendor is:
- 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.
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?
Regards
Theo
On Fri, May 17, 2019 at 1:06 PM qabane me <qabaneitsolutions at gmail.com>
wrote:
> Hi
>
> 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:
>
> "This only happens when the call is not answered. Based on the RFC we are
> not out of specification"
> and
> " 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."
>
> 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.
>
> 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?
>
> Is my reasoning correct?
>
> Regards
> Theo
>
>
> On Tue, May 14, 2019 at 4:15 PM qabane me <qabaneitsolutions at gmail.com>
> wrote:
>
>> Hi
>>
>> I agree but that's not possible. This is the NATIONAL carrier, like a
>> Vodafone in the UK.
>>
>> On Tue, May 14, 2019 at 4:10 PM Daniel Grotti <dgrotti at sipwise.com>
>> wrote:
>>
>>> Hi,
>>> you should better change your carrier then in this case.
>>> Nobody is using BYE to cancel early state calls in SIP.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Daniel Grotti
>>>
>>> Head of Customer Support Sipwise GmbH
>>> e: dgrotti at sipwise.com Europaring F15
>>> t: +43(0)130120332 A-2345 Brunn Am Gebirge
>>> w: www.sipwise.com FN: 305595f FG: LG Wiener Neustadt
>>>
>>> On 5/14/19 4:02 PM, qabane me wrote:
>>> > Hi
>>> >
>>> > The carrier in question is not very helpful and while we are still
>>> > trying to get them to change this, for the moment they are refusing,
>>> citing:
>>> >
>>> > 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)
>>> >
>>> > This is causing phones to keep on ringing upon the bye. If they really
>>> > will not change their behaviour, how do I change ours so that we don't
>>> > have that issue?
>>> >
>>> >
>>> > On Fri, May 10, 2019 at 4:46 PM qabane me <qabaneitsolutions at gmail.com
>>> > <mailto:qabaneitsolutions at gmail.com>> wrote:
>>> >
>>> > Thanks Daniel!
>>> >
>>> > On Fri, May 10, 2019 at 4:16 PM Daniel Grotti <dgrotti at sipwise.com
>>> > <mailto:dgrotti at sipwise.com>> wrote:
>>> >
>>> > Hi,
>>> > in general chapter 15 of RF3261, here an extract:
>>> >
>>> >
>>> > "The notion of "hanging up" is not well defined within SIP.
>>> It is
>>> > specific to a particular, albeit common, user
>>> interface.
>>> > Typically, when the user hangs up, it indicates a
>>> desire to
>>> > terminate the attempt to establish a session, and to
>>> > terminate any
>>> > sessions already created. For the caller's UA, this
>>> > would imply a
>>> > CANCEL request if the initial INVITE has not generated
>>> a
>>> > final
>>> > response, and a BYE to all confirmed dialogs after a
>>> final
>>> > response. For the callee's UA, it would typically
>>> imply
>>> > a BYE;
>>> > presumably, when the user picked up the phone, a 2xx
>>> was
>>> > generated, and so hanging up would result in a BYE
>>> after
>>> > the ACK
>>> > is received."
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Daniel Grotti
>>> >
>>> > Head of Customer Support Sipwise GmbH
>>> > e: dgrotti at sipwise.com <mailto:dgrotti at sipwise.com>
>>>
>>> > Europaring F15
>>> > t: +43(0)130120332 A-2345 Brunn Am Gebirge
>>> > w: www.sipwise.com <http://www.sipwise.com> FN: 305595f
>>> FG:
>>> > LG Wiener Neustadt
>>> >
>>> > On 5/10/19 3:34 PM, qabane me wrote:
>>> > > Hi
>>> > >
>>> > > On of our interconnects sends calls to us. When the caller
>>> > cancels the
>>> > > call before a session is established, they send us a BYE.
>>> > That should be
>>> > > a CANCEL as far as I know. This is causing issues with the
>>> > callee's
>>> > > phone continuing to ring. I am trying to argue with them but
>>> > they are
>>> > > saying it's allowed. I am trying to check the RFCs but am
>>> not
>>> > finding
>>> > > ammunition. Does any one have a link to show that indeed I
>>> am
>>> > right and
>>> > > they are wrong? (assuming that I am)
>>> > >
>>> > > So the scenario is:
>>> > > image.png
>>> > >
>>> > > _______________________________________________
>>> > > Spce-user mailing list
>>> > > Spce-user at lists.sipwise.com <mailto:
>>> Spce-user at lists.sipwise.com>
>>> > > https://lists.sipwise.com/listinfo/spce-user
>>> > >
>>> > _______________________________________________
>>> > Spce-user mailing list
>>> > Spce-user at lists.sipwise.com <mailto:
>>> Spce-user at lists.sipwise.com>
>>> > https://lists.sipwise.com/listinfo/spce-user
>>> >
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20190528/599a1511/attachment-0001.html>
More information about the Spce-user
mailing list