On 11/29/2016 10:36 AM, Nathan Ward wrote:
On 29/11/2016, at 9:26 PM, Răzvan Crainea <raz...@opensips.org> wrote:
On 11/29/2016 04:09 AM, Nathan Ward wrote:
On 29/11/2016, at 5:25 AM, Răzvan Crainea <raz...@opensips.org> wrote:
Hi, Nathan!
Have you tried calling b2b_init_request() with the "a" flag [1]?
[1] http://www.opensips.org/html/docs/modules/2.2.x/b2b_logic.html#id294010
Hi,
Yes I have. This passes through the authentication challenge headers in the
401/407, and then any subsequent response headers in the new INVITE.
b2b_logic/logic.c:1239 calls b2b_mark_todel, after forwarding the message -
because it is marked to_del, the ACK that the originator of the INVITE sends in
response to the 401/407 deletes the session.
I don’t understand how this flag is intended to be used, as there doesn’t seem to
be anything in the code to avoid setting to_del if the response is a 401/407 (or
anything >=300, actually) with auth challenge headers. All it does is pass
through the headers, but as it deletes the session, a new Call-ID is issued by
B2BUA when the authenticated invite is generated.
Hi, Nathan!
Yes, you are right, the flag simply passes the auth headers between the two
legs.
So you were saying that you were only using b2b for topology hiding? If so, why
not using directly the topology_hiding module[1]?
Sure that’s an option, however I would like to understand the B2BUA module
better.
What is the use case for passing authentication headers if the B2BUA instance
is shut down when a challenge (401/407) passes through?
Hi, Nathan!
From SIP perspective, the authentication mechanism is completely
independent from the message/call. That's why you can even use the same
credentials for different calls, as long as the nonce does not change.
So the auth server, does not have to map the credentials with a call-id.
Some servers might enforce this requirement - however, unfortunately
those will not work with opensips B2B.
From OpenSIPS perspective, when it receives the 401/407, the
transaction will be terminated, and the B2B will destroy the associated
entities. When the new INVITE comes in, it will create a completly new
entity, that will contain a different Callid (and will be seen as a new
leg). These two entities are not corelated at all in the current code.
That's why for now the current B2B implementation does not support your
scenario.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
