On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul
wrote:
> On Oct 07, 2010 at 15:52, Juha Heinanen wrote:
>> Andrei Pelinescu-Onciul writes:
>>
>> > > if proxy is processing all invites statefully, why anything needs to be
>> > > done when invite transaction corresponding the to cancel is m
Juha,
On Thu, Oct 7, 2010 at 8:52 AM, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
>> > if proxy is processing all invites statefully, why anything needs to be
>> > done when invite transaction corresponding the to cancel is missing?
>> > isn't it a case of unmatched cancel and the ca
On Oct 07, 2010 at 15:52, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > > if proxy is processing all invites statefully, why anything needs to be
> > > done when invite transaction corresponding the to cancel is missing?
> > > isn't it a case of unmatched cancel and the cancel coul
Andrei Pelinescu-Onciul writes:
> > if proxy is processing all invites statefully, why anything needs to be
> > done when invite transaction corresponding the to cancel is missing?
> > isn't it a case of unmatched cancel and the cancel could just be
> > dropped?
>
> Well, IMHO it should be forwar
On Oct 07, 2010 at 13:52, Juha Heinanen wrote:
> in tm readme there is this kind of example regarding use of
> t_relay_cancel:
>
> if (method == CANCEL) {
> if (!t_relay_cancel()) { # implicit drop if relaying was successful,
> # nothing to do
>
>
