Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
On 11/29/2016 10:36 AM, Nathan Ward wrote: On 29/11/2016, at 9:26 PM, Răzvan Crainea wrote: On 11/29/2016 04:09 AM, Nathan Ward wrote: On 29/11/2016, at 5:25 AM, Răzvan Crainea 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
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
> On 29/11/2016, at 9:26 PM, Răzvan Crainea wrote: > > On 11/29/2016 04:09 AM, Nathan Ward wrote: >>> On 29/11/2016, at 5:25 AM, Răzvan Crainea 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? -- Nathan Ward ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
On 11/29/2016 04:09 AM, Nathan Ward wrote: On 29/11/2016, at 5:25 AM, Răzvan Crainea 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]? [1] http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html 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
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
> On 29/11/2016, at 5:25 AM, Răzvan Crainea 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. -- Nathan Ward ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
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 Best regards, Răzvan Crainea OpenSIPS Solutions www.opensips-solutions.com On 11/26/2016 06:04 AM, Nathan Ward wrote: Hi all, I am configuring an SBC with 3 legs - one to the core (i.e. to a registrar and routing server), one towards end users, and one towards a provider. My intent is to make he SBC fairly “dumb”, and not keep state of registrations etc. The provider requires registration and authentication for calls. I generate registrations from our core towards our provider for each line, through the SBC (forwarding these rather than B2BUA-ing). I also have users registering towards our core. Works great. When we forward an INVITE from our core, the B2BUA creates a new session and forwards it to the provider. The provider challenges (401), which is forwarded back towards the core. The core ACKs this challenge, and forwards the ACK to the provider. Then, the B2BUA deletes the dialog after saying "ACK for a negative reply”. This means that the subsequent authenticated INVITE generates a new instance on the B2BUA, and a new Call-ID - which causes the provider to reject this as the Call-ID is expected to be consistent across auth/unauth INVITEs. Worth noting that before we call b2b_init_request, I call “force_send_socket”, as we use loopback/virtual addresses for talking with our provider. - Is this expected behaviour? - Is there a way to tweak this so that ACK for a 401/407/etc. does not immediately tear down the B2BUA entity? - Can I avoid this by writing my own B2BUA scenario? We are using the built in “top hiding” for the moment. If code is required to permit this model I’m happy to work on this, but before I get my hands dirty I thought I’d ask around :-) We have the same behaviour from User->B2BUA->Core - however for the moment our Core doesn’t care about differing Call-ID, which is obviously a problem that I’ll be looking at next..! -- Nathan Ward ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"
Hi all, I am configuring an SBC with 3 legs - one to the core (i.e. to a registrar and routing server), one towards end users, and one towards a provider. My intent is to make he SBC fairly “dumb”, and not keep state of registrations etc. The provider requires registration and authentication for calls. I generate registrations from our core towards our provider for each line, through the SBC (forwarding these rather than B2BUA-ing). I also have users registering towards our core. Works great. When we forward an INVITE from our core, the B2BUA creates a new session and forwards it to the provider. The provider challenges (401), which is forwarded back towards the core. The core ACKs this challenge, and forwards the ACK to the provider. Then, the B2BUA deletes the dialog after saying "ACK for a negative reply”. This means that the subsequent authenticated INVITE generates a new instance on the B2BUA, and a new Call-ID - which causes the provider to reject this as the Call-ID is expected to be consistent across auth/unauth INVITEs. Worth noting that before we call b2b_init_request, I call “force_send_socket”, as we use loopback/virtual addresses for talking with our provider. - Is this expected behaviour? - Is there a way to tweak this so that ACK for a 401/407/etc. does not immediately tear down the B2BUA entity? - Can I avoid this by writing my own B2BUA scenario? We are using the built in “top hiding” for the moment. If code is required to permit this model I’m happy to work on this, but before I get my hands dirty I thought I’d ask around :-) We have the same behaviour from User->B2BUA->Core - however for the moment our Core doesn’t care about differing Call-ID, which is obviously a problem that I’ll be looking at next..! -- Nathan Ward ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
