[SR-Users] Handling of CANCEL in case of no matching INVITE
Vassilis Radis
radisb at gmail.com
Fri May 3 14:59:05 CEST 2013
Yes, I used the term proxy to include statefullness and dialog awareness,
which makes me think: What is the point of being transaction-aware without
being dialog-aware? I am trying to find a use for it, but I cant.
On Fri, May 3, 2013 at 3:34 PM, Jiri Kuthan <jiri at iptel.org> wrote:
> Hi Bill,
>
> plain-kamailio cannot send BYEs (not sure if some module can). The point
> is the proxy is
> sort of "passive element" and doesn't initiate transactions on its own.
>
> Why isn't it enough to have the BYEs sent by UAC? I mean sometimes there
> can be some
> confusing situations (say forking downstream) and it is eventually the UAC
> that's in
> the best position to know what to BYE or CANCEL.
>
> The point is this all seems a UAS business to me, for which a proxy can
> only do some
> approximiations risking it will be wrong. Like in the case 2, you may not
> even notice
> the ACK is already on its way (because you didn't record-route)... Getting
> control
> of this would really mean using the dialog module and running in B2BUA
> mode rather
> than proxy.
>
> -jiri
>
>
> On 5/3/13 11:59 AM, Vassilis Radis wrote:
>
>> Thank you jiri,
>>
>> I totally agree, but I have a question that occured to me now and I cant
>> find answer:
>>
>> If Kamailio receives a CANCEL from a UAC after kamailio has responded
>> with a 200 to the corresponding INVITE, what does t_relay_cancel() do in
>> the following 2
>> cases:
>>
>> 1. CANCEL received before the ACK from UAC. This is legal from the side
>> of the UAC, since the UAC may have sent the CANCEL before it receives the
>> 200 to the
>> INVITE that kamailio sent.
>> 2. CANCEL received after the ACK . This is illegal, but anyway, kamailio
>> must do something. I can't find in the RFC if it should respond 200 to the
>> CANCEL and
>> drop it, or 481(Call/Transaction Does Not Exist). Although 481 seems more
>> resonable, 16.10 section of RFC says: "... If a matching response context
>> is found,
>> the element MUST immediately return a 200 (OK) response to the CANCEL
>> request.". It does not discriminate if the corresponding INVITE has been
>> 200ed or not. Any
>> insights?
>>
>> In the spirit of what you wrote in your reply, could I configure it
>> somehow, to take initiative and translate the CANCEL to a BYE downstream,
>> no matter whether
>> CANCEL is received before or after the ACK?
>>
>> Bill
>>
>>
>> On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan <jiri at iptel.org <mailto:
>> jiri at iptel.org>> wrote:
>>
>> On 5/3/13 11:04 AM, Vassilis Radis wrote:
>>
>> Hello all,
>>
>> In the documentation of the t_relay_cancel() (TM module) there is
>> an example that reads:
>>
>> if (method == CANCEL) {
>> if (!t_relay_cancel()) { # implicit drop if relaying was
>> successful,
>> # nothing to do
>>
>> # corresponding INVITE transaction found but error occurred
>> sl_reply("500", "Internal Server Error");
>> drop;
>> }
>> # bad luck, corresponding INVITE transaction is missing,
>> # do the same as for INVITEs
>> }
>>
>> What bothers me is the phrase#do the same as or INVITEs, because
>> in RFC(http://tools.ietf.org/__**html/rfc3261#section-16.10<http://tools.ietf.org/__html/rfc3261#section-16.10>
>>
>> <http://tools.ietf.org/html/**rfc3261#section-16.10<http://tools.ietf.org/html/rfc3261#section-16.10>>
>> ) it says:
>>
>> If a response context is not found, the element does not have any
>> knowledge of the request to apply the CANCEL to. It
>> MUST*statelessly*
>>
>> forward the CANCEL request (it may have statelessly forwarded the
>> associated request previously).
>>
>>
>> So aren't we supposed to immediately statelessly forward the
>> CANCEL if t_relay_cancel() did not find the INVITE transaction, instead of
>> doing the same
>> as INVITEs, which could be t_relay() (not stateless)?. Like below:
>>
>>
>> if (method == CANCEL) {
>> if (!t_relay_cancel()) { # implicit drop if relaying was
>> successful,
>>
>> # nothing to do
>>
>> # corresponding INVITE transaction found but error occurred
>> sl_reply("500", "Internal Server Error");
>> drop;
>>
>> }
>> # bad luck, corresponding INVITE transaction is missing,
>>
>> forward();
>> }
>>
>> Am I correct or am i missing something?
>>
>>
>>
>> It could be even more standardized this way indeed. Aparts
>> from standards, measured by common sense I cannot realize
>> that either way would break something. The CANCEL should
>> not be appearing there at all. Perhaps it would make a difference
>> when SER is restarted and one after it went alive again,
>> UAC sent a CANCEL. Then what you suggest would perform better.
>> If you want to make sure you have captured this case, also make
>> sure that branch ids are configured to be produced statelessly.
>> Otherwise SER-proxied CANCEL won't match the previous INVITE anyhow.
>>
>> other than that, SER is much better than RFC3261. Its
>> registrar is stateless (in departure from the RFC, otherwise
>> it would be more vulnerable to DoS attacks), INVITE transaction
>> is hold after a 200 passes through (otherwise it would not
>> absorb retransmissions, create another transaction and
>> cause interop issues), and probably more.
>>
>> I just wanted to say it is really important to look first
>> at what interop issues one may have or not, as SER the
>> way it is is likely to produce better interop than
>> consequent standard compliance. In most cases you
>> can achieve it by configuration changes, I just think
>> you don't want to :)
>>
>> -jiri
>>
>>
>>
>> Thank you in advance,
>> Bill
>>
>>
>>
>> ______________________________**___________________
>>
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> mailing list
>> sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-**
>> router.org <sr-users at lists.sip-router.org>>
>> http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__**
>> users <http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users><
>> http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130503/5d0aba20/attachment.html>
More information about the sr-users
mailing list