[OpenSIPS-Users] Truncated Branch in Via

Bogdan-Andrei Iancu bogdan at opensips.org
Mon Jul 11 12:11:44 CEST 2016


Hi Elliott,

1) regarding the uniqueness - it is across time and space ,per server! 
The transaction IDs are per server, so there is not problem if 2 servers 
do use the same ID for a transaction - each server will look into the 
branch ID belonging to its VIA hdr.
So, I do not see any conflict here

2) I never statethat the idea to reuse any previous branch param (to 
build our own VIA branch) comes from RFC - this approach was the result 
of a discussion on the mailing list between developers.

Let me know if I manage to answer to your questions.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 09.07.2016 16:47, Elliott, Ray wrote:
>
> Hi Bogdan,
>
> I’m a bit confused.
>
> From RFC 3261 states in Section 16.11 Stateless Proxy
>
> */The requirement for unique branch IDs across space and time applies 
> to stateless proxies as well. /*
>
> /However, a stateless proxy cannot simply use a random number 
> generator to compute the first component of the branch ID, as 
> described in Section 16.6 bullet 8. This is because retransmissions of 
> a request need to have the same value, and a stateless proxy cannot 
> tell a retransmission from the original request./
>
> */Therefore, the component of the branch parameter that makes it 
> unique MUST be the same each time a retransmitted request is forwarded./*
>
> /Thus for a stateless proxy, the branch parameter MUST be computed as 
> a combinatoric function of message parameters which are invariant on 
> retransmission./
>
> //
>
> We are using the stateless implementation of opensips. As such we MUST 
> not use the statefull  t_replay() function.
>
> Copying the TOP most Via header branch will meet the requirement since 
> that branch value MUST also be “unique branch IDs across space and time.”
>
> However, just copying apart of that  destroys the “unique branch IDs 
> across space and time “ requirement.
>
> I’m confused because I can not find the requirement that you specified 
> below in RFC 3261.
>
> Thanks for your response.
>
> Ray
>
> *Ray Elliott*
>
> Principal Scientist
>
> 777, Commerce Dr., Fairfield, CT 06825
>
> *T *+1 203 339 7052  M +1 203 848 4550 *E* ray.elliott at ipc.com 
> <mailto:ray.elliott at ipc.com>
>
> Follow us on twitter: @ipc_Systems_Inc www.ipc.com <http://www.ipc.com/>
>
> cid:image001.jpg at 01D19553.88C2B160
>
> *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
> *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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160711/e2f505fe/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3068 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20160711/e2f505fe/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6149 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20160711/e2f505fe/attachment-0001.png>


More information about the Users mailing list