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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
