Hi Rahul,
I just did the backport to all maintained versions. For the moment the
fix will be present in all all nightly builds / rpms, until the next
minor releases.
Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 14.07.2016 21:17, Gupta, Rahul wrote:
Hi Bogdan, thanks for the prompt response and providing the fix. We
have tested it and it works fine. Are you going to put this in any build ?
*Thanks*
*Rahul Gupta***
Systems Architect
*T*+1 732-690-3845 |*E* [email protected] <mailto:[email protected]>
cid:[email protected]
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Monday, July 11, 2016 12:42 PM
*To:* OpenSIPS users mailling list; Gupta, Rahul
*Subject:* Re: [OpenSIPS-Users] Truncated Branch in Via
Hi Rahul,
There is a fix available for extra testing - see :
https://github.com/OpenSIPS/opensips/commit/482e643469b351d12418ff54c96beee7b27dca94
please give it a try and let me know if it is solving the problem for
you too.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 08.07.2016 17:30, Bogdan-Andrei Iancu wrote:
Hi Rahul,
Indeed, that is a good point here, thanks for bring it up. Let me
investigate the code a bit and I will update you.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.07.2016 22:01, Gupta, Rahul wrote:
Hi Bogdan, so the problem we are facing is the endpoint has a
new branch however the difference in the branch value is
*AFTER* the MAX_BRANCH_PARAM_LEN, the highlighted text.Since
opensips is copying the partial branch which is same as the
previous Via and thus our SIP stack (OCCAS) is sending back
401 Unauthorized for both thinking it’s a retransmit.
This is also in line with RFC3261. Shouldn’t it copy the
entire Via to make sure it’s different from previous Message ?
*REGISTER 1*
Via: SIP/2.0/UDP
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ
*REGISTER 2*
Via: SIP/2.0/UDP
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915656050004_MTAuMTIuMy4xMQ
*Thanks*
*Rahul Gupta*
Systems Architect
*T*+1 732-690-3845 |*E* [email protected]
<mailto:[email protected]>
cid:[email protected]
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Thursday, July 07, 2016 4:43 AM
*To:* Gupta, Rahul
*Cc:* Elliott, Ray; [email protected]
<mailto:[email protected]>
*Subject:* Re: [OpenSIPS-Users] Truncated Branch in Via
Hi Rahul,
The received VIA hdr (with the .44 IP) is properly preserved
when forwarding (in the outbound message).
The VIA hdr added by OpenSIPS ( .156 IP) is a completely new
VIA and its branch value is completely independent from the
branch of other VIA hdrs.
Why do they look the same ? The RFC3261 says that for
stateless fwd (when basically there is no transaction, so no
branch value), to avoid populating its VIA with ";branch=0" ,
the proxy may "copy" and use a branch value from an older VIA
(a received VIA) - keep in mind it does not say to copy it
entirely or part. So, OpenSIPS copies a MAX_BRANCH_PARAM_LEN
length string from the previous branch param.
Everything is correct and legal (from RFC perspective).
PS: if you would use t_relay() instead of forward() - doing
statefull proxy -, you will see that the branch in the VIA
added by OpenSIPS will be completly different from the value
in the previous VIA.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.07.2016 03:42, Gupta, Rahul wrote:
Hi Bogdan,
Here is a Ethernet trace (pcap) file that has a successful
and an unsuccessful registration.
Frames 1-8 illustrate the successful case with Frames 2
and 6 show how opensips adds an extra VIA header that has
a full VIA;branch
Frame:2
Via: SIP/2.0/UDP
10.204.70.156:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8
Via: SIP/2.0/UDP
10.204.45.122:5060;branch=z9hG4bK-c45d6-2ff0ce63-4583dc45-6bd144f8
Frames 9-16 illustrate the unsuccessful case where Frames
10 and 14 show how opensips adds an extra VIA header that
has a truncated branch.
Frame 10:
Via: SIP/2.0/UDP
10.204.70.156:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_11391
Via: SIP/2.0/UDP
10.205.236.44:5060;branch=z9hG4bK1c68e33e-848e-412a-9137-4fb065a7b7eb_0efbfc5e_113915620064228_MTAuMTIuMy4xMQ
*Thanks*
*Rahul Gupta*
Systems Architect
*T*+1 732-690-3845 |*E* [email protected]
<mailto:[email protected]>
cid:[email protected]
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Wednesday, July 06, 2016 5:38 AM
*To:* OpenSIPS users mailling list
*Cc:* Elliott, Ray; Gupta, Rahul
*Subject:* Re: [OpenSIPS-Users] Truncated Branch in Via
Hi Rahul,
That define is used to calculate the the max VIA len when
OpenSIPS is generating its own VIA headers. That max len
does not impact the VIA headers which were received.
I do not understand exactly (in your example) what's the
flow of that VIA header. If you want, send me off-list the
pcap/ngrep showing the SIP package (before and after
OpenSIPS) and how it is affected.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05.07.2016 20:57, Gupta, Rahul wrote:
We are using opensips 1.11.5 as a stateless proxy and
seeing a truncated Branch in Via for my REGISTER
message. After some code digging, the MAX length is
calculated using the following formula and seems like
its truncating the branch after 55 characters. This is
causing the REGISTER to fail in our case. Is there a
config level solution to this ?
*#define MAX_BRANCH_PARAM_LEN (MCOOKIE_LEN+8
/*!<int2hex*/ + 1 /*sep*/ + \*
*MD5_LEN + 1 /*!<sep*/ + 8 /*int2hex*/ + \*
*1 /*extra space, needed by t_calc_branch*/)*
truncated from opensips àVia: SIP/2.0/UDP
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbfc5e_11160
Via from EndPoint àVia: SIP/2.0/UDP
XX.XX.XX.XX:5060;branch=z9hG4bK0fddbbc9-1487-4755-a0b3-0c319155b8c3_0efbfc5e_1116078308924346_MTAuMTIuMy4xMQ
*Thanks*
*Rahul Gupta*
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] <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
