[Serusers] Problem with cancel a invite

Klaus Darilion klaus.mailinglists at pernau.at
Fri Jun 17 09:55:30 CEST 2005


Hi Anders!

The CANCEL is sent by the caller. Thus, if A hangs up the call before B 
has answered, A is sending CANCEL to B.

regards,
klaus

Anders Hansson wrote:
> Hi all,
> The problem is that I don´t see a CANCEL coming from phone B when 
> pressing the "hang-up" button. (A is calling B).
> I´ve used etheral to trace the messaging between clients and proxy and I 
> never see the CANCEL from user B even though I´m pressing the "hang-up" 
> button...
> Any idea why the CANCEL is never occuring? (The INVITEs, ACKs and BYEs 
> are there.)
> Thanks,
> Anders
> 
> Greger V. Teigre skrev:
> 
>> Marian Dumitru wrote:
>>
>>> I know that the RFC doesn't specify if CANCEL is or not allows within
>>> the dialog - there were also some discussions on the sip-implementors
>>> mailing list about how to handle a CANCEL within the dialog.
>>> Anyhow, IMHO, even if allowed, CANCEL within the dialog makes less
>>> sense - to be honest I saw no implementation doing something like
>>> this.
>>
>>
>>
>> To be honest, I don't allow myself to have an opinion on that.  :-) 
>> Being a practitioner and not an implementor I try to pick up what the 
>> implementors are saying. I thought CANCEL within dialog was (although 
>> not common) at least occuring.
>>
>>> Now, back to the original subject: as Anders describe his problem, is
>>> definitely not the case of a within the dialog CANCEL and we should
>>> come up with some hints relevant to his case and avoid confusing the
>>>  guy more than necessary ;).
>>
>>
>>
>> You're definitely right about that ;-)  Sorry, Anders!
>>
>>> And regarding the t_relay() and CANCEL - there is no need to apply
>>> same RURI transformations as for INVITE - TM saves the INVITE
>>> outgoing RURI; when CANCEL comes, it is matched with an INVITE and
>>> the RURI for CANCEL is automatically taken from the INVITE
>>> transaction.
>>
>>
>>
>> THAT I was not aware of. Thank you for telling me, it means that we 
>> can simplify the ONsip.org reference config files.  :-D
>> Excellent and thanks,
>> Greger
>>
>>
>>> regards,
>>> Marian
>>>
>>> Greger V. Teigre wrote:
>>>
>>>> Hi Marian!
>>>>
>>>> Marian Dumitru wrote:
>>>>
>>>>> CANCEL has nothing to do with loose route - and it will never hit he
>>>>> loose route. The Route ser is set only when the dialog is
>>>>> established (200 ok); and CANCEL happens *before* the dialog
>>>>> completion. The big idea with CANCEL is to take care to route it 
>>>>> *exactly* as
>>>>> its INVITE.
>>>>
>>>>
>>>>
>>>>
>>>> AFAIK, CANCEL can happen both in-dialog and outside a dialog.  This
>>>> was a part of the verification we did when developing the ONsip.org
>>>> reference config filers. I'm not sure if the discussion was on
>>>> serusers or not, but as far as I remember, there is situation where
>>>> CANCEL will be in-dialog and thus can take the loose route path,
>>>> i.e. reINVITEs. As you will see in the ONsip.org config files, 
>>>> CANCEL is handled as
>>>> an INVITE, but loose route test is done *before* the test on CANCEL
>>>> to make sure that any in-dialog CANCELs are handled properly.
>>>>
>>>>> As a hint, if you use TM, t_relay() all the time will take care to
>>>>> send the CANCEL to same destination as INVITE.
>>>>
>>>>
>>>>
>>>>
>>>> ... as long as you have done the same r-uri transformations as with
>>>> the INVITE.
>>>> g-)
>>>>
>>>>> regards,
>>>>> Marian
>>>>>
>>>>> Greger V. Teigre wrote:
>>>>>
>>>>>> Most likely you don't handle the CANCEL messages correctly. May be
>>>>>> that you don't do proper loose route handling.  Take a look at the
>>>>>> example configs (and the Getting Started document) at
>>>>>> http://onsip.org/  You gain much be following the logic found
>>>>>> there, they have been verified for all kinds of situations...
>>>>>> g-)
>>>>>>
>>>>>> Anders Hansson wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>> I´ve got a problem when trying to cancel an invite.
>>>>>>> The situation: A makes a call to B (INVITE). B press the "hang up"
>>>>>>> button. An here comes the problem.
>>>>>>> From As side, everything is OK, but from Bs side, the phone is
>>>>>>> still ringing...
>>>>>>> How can a solve this problem? Anyone?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anders 
>>>>>>
>>>>>>
>>
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 




More information about the sr-users mailing list