[OpenSIPS-Users] SIP-I and CANCEL

[Bogdan-Andrei Iancu]

Hi Giovanni,

The CANCEL is hop-by-hop, which means each SIP hop will generate a 
completely new CANCEL (to be sent further) - there is not proxying, so 
the changes you do over the incoming CANCEL will not propagate into the 
outgoing CANCEL.

I cannot recall it, but is there a standard case of pushing ISUP into 
CANCEL ?

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
OpenSIPS Summit 2019
   https://www.opensips.org/events/Summit-2019Amsterdam/

On 12/07/2018 02:00 PM, Giovanni Maruzzelli wrote:
> Hi all,
>
> using 2.4
>
> I am trying to add_isup_part("Release"); to a CANCEL
>
> It does not give errors (I use same isup_param(s) as per BYE), but the 
> CANCEL that is being sent out does not have the isup part.
> Eg, it does not even have a body, and Content-Length is 0.
>
> I suspect t_relay, when it recreate the CANCEL from the original 
> INVITE, does not care about what add_isup_part added to the CANCEL (it 
> makes sense, t_relay creates the CANCEL anew, from original INVITE).
>
> Any known workaround?
>
> Using forward instead of t_relay sends a CANCEL with the isup part, 
> but remote reject it with 481 (call/transaction does not exists), 
> probably because is not routed exactly like the initial INVITE, a 
> branch parameter in a via header is different...
>
> -giovanni
>
>
> -- 
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181207/89bbc1cd/attachment.html>