[OpenSIPS-Users] Truncated Branch in Via

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Jul 7 10:43:21 CEST 2016


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/20160707/9dff6e5e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4709 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20160707/9dff6e5e/attachment-0001.png>


More information about the Users mailing list