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

Reply via email to