When making a call, if we get 401, we should handle it same way as 407 and provide credentials

[ocarriles]

Registration deals with 401/407 responses in order to re-authenticate

Invites just deal with 407.

My use case is returning 401 Unauthorized

[atsakiridis]

@ocarriles can you elaborate more on your scenario? You are using webrtcomm sdk to make a call and the server returns 401? What happens then, the call fails?

[ocarriles]

@atsakiridis
Call fails.
Adding also 401 return status to INVITE processing solves my issue, just like it is done in the REGISTER code space.

[atsakiridis]

@ocarriles, great, so you patched webrtcomm to handle 401 like a 407 for the INVITE, right? Would you like to contribute that back to the codebase? Seems the right thing to do

[ocarriles]

@atsakiridis , yep, but as I do not want to pollute your code, I am wondering if the this use-case is RFC compliant, Perharphs the SBC has to deal with 401 and convert to 407 in same cases. :)

[atsakiridis]

I see your point actually it's a little foggy on how the client should handle the following responses from server which seem relevant:

• 401 Unauthorized
• 403 Forbidden
• 407 Proxy Authentication Required

So far I think we 're mostly answering with auth information to 407. In my mind 403 is more like an auth error that doesn't solicit further client requests. But I think we could answer to 401 as well in the same manner

@deruelle what do you think?

[deruelle]

@atsakiridis right. Let's handle it for 401 in a similar way than for 407. Please note 401 and 407 doesn't use the same header name (Authentication vs Proxy-Authenticate SIP Header IIRC)

[atsakiridis]

Great, in that case, @ocarriles can you create a Pull Request with your changes, so that we can review and move it forward?

Also, from wikipedia the header names are as I pasted above: 401 Unauthorized and 407 Proxy Authentication Required.

[atsakiridis]

Hello @ocarriles do you think you 'll be able to create the Pull Request with your solution?

[ocarriles]

Hi @atsakiridis
find patched on WebRTComm

need to remove:

https://github.com/RestComm/sbc/blob/master/application/src/main/webapp/webrtc/phone/scripts/WebRTComm.js#L14

https://github.com/RestComm/sbc/blob/master/application/src/main/webapp/webrtc/phone/scripts/WebRTComm.js#L3506
https://github.com/RestComm/sbc/blob/master/application/src/main/webapp/webrtc/phone/scripts/WebRTComm.js#L3507

and the whole method "forcePublicCandidate"

[atsakiridis]

@ocarriles I'm lost a bit. Why are you editing sbc code and not webrtcomm code? Aren't the changes you suggest webrtcomm ones?

Also you can do a Pull Request that is easier both for you to generate and for us to merge. Do you think you can do that?

[ocarriles]

@atsakiridis
I am the SBC author.
As the RestComm/sbc injects a proof of concept webrtc client dependecy, I decided to bundle my own webrtcomm code.
Hope it helps.

[atsakiridis]

I see. Thanks @ocarriles will try to fix the webrtcomm code so that when inviting if we get 401, we handle it same way as 407.

Let me also update the title to make a little bit more explanatory