Milan Rukavina wrote:
> Also I found this article:
> Also RFC 3261 says:
> 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. This does not mean a user cannot hang up before
> receipt of the ACK, it just means that the software in his phone
> needs to maintain state for a short while in order to clean up
> properly. If the particular UI allows for the user to reject a
> call before its answered, a 403 (Forbidden) is a good way to
> express that. As per the rules above, a BYE can't be sent
> So, after all, seems like all devices send CANCEL during ringing, but
> not this switch. Should I argue with them or this is still an issue on
> yate side, should yate forward this BYE event?
I think it is a yate issue. When the incoming call leg is terminated by
the remote side, yate must take care to also terminate the outgoing call
leg. Either by "forwarding" this BYE, or by issuing a CANCEL (when
>> It's a little bit difficult since it's a production server and it might
>> not be clean log with this call isolated. Will tcpdump be good for
>> Here is what they say:
>> It is inside
>> RFC3261 (Chapter 15 Terminating session, page 89:
>> "The BYE request is used to terminate a specific session or
>> attempted session."
>> "The caller's UA MAY send a
>> BYE for either confirmed or early dialogs, and the callee's UA MAY send a
>> BYE on confirmed dialogs, but MUST NOT send a BYE on early
>> So it seems regular to send BYE on 183 from caller's side. Anyway, I
>> guess in most cases CANCEL is sent as well, but not in these case. So
>> we need a way to make Yate send this BYE as well.
>> We're stuck between a rock and a hard place :(
>>> Can you send you yate.log?
>>> On Fri, Oct 15, 2010 at 11:15 AM, Milan Rukavina
>>>> Hi All,
>>>> We're trying to connect our Yate server to a new SIP provider. All
>>>> tests are
>>>> OK except for "calling party clears before answer". Calling party
>>>> hangs up,
>>>> but called party's phone still rings.
>>>> After sniffing SIP traffic I found that BYE event is not forwarder
>>>> by Yate.
>>>> Here's attached wireshark graph, you can see incoming side which
>>>> sends BYE,
>>>> but it's not present in outgoing channel.
>>>> Comparing to other links, ex. when traffic is sent from Yate, it emits
>>>> CANCEL and then BYE when call is progressing, which seems to be
>>>> correctly. In this case our provider says it's correct to send just
>>>> BYE, but
>>>> we're not forwarding that further.
>>>> Is there anything we can do from our side, like configure Yate or
>>>> Milan Rukavina,
>>>> Horisen GmbH
First Telecom GmbH
Lyoner Str. 15
Tel. +49 69 65006577
Fax. +49 69 65006579
Sitz der Gesellschaft: Frankfurt am Main
Handelsregister: Amtsgericht Frankfurt am Main, HRB 56145
Geschäftsführer: Frank Hartmann, Dieter Plassmann