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* [email protected]
<mailto:[email protected]>
Follow us on twitter: @ipc_Systems_Inc www.ipc.com <http://www.ipc.com/>
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]
*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]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
