[Spce-user] Upstream sends Bye instead of cancel
qabane me
qabaneitsolutions at gmail.com
Tue May 14 10:15:20 EDT 2019
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/20190514/3ff1b75a/attachment-0001.html>
More information about the Spce-user
mailing list