[OpenSIPS-Users] Truncated Branch in Via
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Jul 11 18:42:19 CEST 2016
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 pointhere, 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
>> *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
> 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/bb28b54e/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/20160711/bb28b54e/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/20160711/bb28b54e/attachment-0001.png>
More information about the Users
mailing list