[OpenSIPS-Users] Truncated Branch in Via

Bogdan-Andrei Iancu bogdan at opensips.org
Fri Jul 15 11:25:30 CEST 2016


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* rahul.gupta at ipc.com <mailto:rahul.gupta at ipc.com>
>
> cid:image006.jpg at 01D1940F.3E021840
>
> *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
> *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* rahul.gupta at ipc.com
>         <mailto:rahul.gupta at ipc.com>
>
>         cid:image006.jpg at 01D1940F.3E021840
>
>         *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
>         *Sent:* Thursday, July 07, 2016 4:43 AM
>         *To:* Gupta, Rahul
>         *Cc:* Elliott, Ray; users at lists.opensips.org
>         <mailto:users at lists.opensips.org>
>         *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* rahul.gupta at ipc.com
>             <mailto:rahul.gupta at ipc.com>
>
>             cid:image006.jpg at 01D1940F.3E021840
>
>             *From:*Bogdan-Andrei Iancu [mailto:bogdan at opensips.org]
>             *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
>
>                 Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>
>                 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>     _______________________________________________
>
>     Users mailing list
>
>     Users at lists.opensips.org <mailto: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/20160715/30513876/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2905 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20160715/30513876/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6175 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20160715/30513876/attachment-0001.png>


More information about the Users mailing list