Hi Rahul,
It will not just a tough job to have a global param controlling the
inheritance of some hdr in cancel requests. are you willing to open a
feature request on the github tracker ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 08.05.2015 19:38, Gupta, Rahul wrote:
Hi Bogdan, thanks for clarifying the behavior. In our implementation,
we need those user defined headers to make it through the proxy, is
there any way to populate the stateful CANCEL with the incoming
user-defined headers ?
Thanks
Rahul
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Thursday, May 07, 2015 1:17 PM
*To:* Gupta, Rahul; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding
user defined Headers
Rahul,
As per RFC, in stateless mode there is no branch (for the newly added
VIA) - as branch is transaction oriented. And the RFC3261 recommends
to reuse the previous VIA hdr (if exists).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.05.2015 20:01, Gupta, Rahul wrote:
Hi Bogdan,
I want to use opensips as stateless proxy that’s why I tried
forward() which is causing the branch issue as shown below, the
branch in both the Via headers are same.
CANCEL sip:XXXX@IP:PORT <sip:XXXX@IP:PORT> SIP/2.0
From: "Alan
Altman[3004]"<sip:YYYY@IP:PORT>;tag=389cc678-0-13c4-65014-16288-3d1c9b70-16288
To: <sip:XXXX@IP:PORT>
Call-ID: 10589b68-0-13c4-65014-16288-156334b2-16288
CSeq: 1 CANCEL
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Via: SIP/2.0/UDP IP:PORT;branch=z9hG4bK-16288-568e507-60d8e02-38903830
Reason: SIP;cause=200;text="User Release"
Max-Forwards: 69
Supported:
timer,replaces,from-change,histinfo,answermode,eventlist,recipient-list-subscribe
User-Agent: test user agent
Content-Length: 0
X-testHeader: RAHUL
If we use t_relay(), I want to forward X-testHeader to the endpoint.
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Thursday, May 07, 2015 12:39 PM
*To:* OpenSIPS users mailling list; Gupta, Rahul
*Subject:* Re: [OpenSIPS-Users] CANCEL in t_relay() not forwarding
user defined Headers
Hi Rahul,
As per RFC3261, the stateful CANCELs are hop-by-hop - which means
each hop consumes the incoming CANCEL and generates a new one for
the next hop.
This is why the headers do not propagate.
What kind of headers are looking to be passed further ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 06.05.2015 20:45, Gupta, Rahul wrote:
I am using opensips as a proxy, when a CANCEL to an INVITE
comes in, its processed as follows
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
in t_relay() seems like its creating new transaction for
CANCEL and forwarding to the destination. However its not
copying user-defined Headers which comes as a part of CANCEL.
Is there a way to forward the other Headers ?
I also tried using forward(). In this case, all the headers
are getting forwarded, however, the branch in Via header is
getting duplicated from the incoming VIA header which is
causing issues with the endpoint.
Question 1) If I use t_realy() for CANCEL, then how do I
forward user defined Headers ?
Question 2) If I use forward() for CANCEL, then how do I get
the Via Header with proper branch as created in INVITE ?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DISCLAIMER: This e-mail may contain information that is
confidential, privileged or otherwise protected from
disclosure. If you are not an intended recipient of this
e-mail, do not duplicate or redistribute it by any means.
Please delete it and any attachments and notify the sender
that you have received it in error. Unintended recipients are
prohibited from taking action on the basis of information in
this e-mail.E-mail messages may contain computer viruses or
other defects, may not be accurately replicated on other
systems, or may be intercepted, deleted or interfered with
without the knowledge of the sender or the intended recipient.
If you are not comfortable with the risks associated with
e-mail messages, you may decide not to use e-mail to
communicate with IPC. IPC reserves the right, to the extent
and under circumstances permitted by applicable law, to
retain, monitor and intercept e-mail messages to and from its
systems.
_______________________________________________
Users mailing list
[email protected] <mailto:[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
