IP Office SIP Registration
We are testing interoperability between Avaya IP Office 6.1 and telecom operator with Iskratel softswitch. During this testing we have noticed that IP Office is not able to register with appropriate user and password to the softswitch. On the other hand X-Lite can regitser to the softswitc with same user and password.
We have analyzed the Wireshark logs and come to following conclusion:
- After first Register message sent by IP Office, Iskratel is sending Unauthorized messaging, then IP Office is sending another Register message with authentication header, and then Iskratel responds with 403 Forbidden.
- In the Unauthorized message the Iskratel is giving the parameters for the authentication
WWW-Authenticate: Digest realm="172.16.17.10",nonce="4c8f2d45d72386701f74e1 1bd1fde8e015058cdd",opaque="bceb4d62d1578aec6de6e3 b3c71c8223",qop="auth"
Here the server is using nonce and opaque value for the authentication. The opaque value is parameter that user agent (IP Office) should return unchanged to the server in the second Register message.
- IP office in the second register message is sending
[truncated] Authorization: Digest username="5119013",realm="172.16.17.10",nonce="4c8 f2d45d72386701f74e11bd1fde8e015058cdd",response="9 7d36b28ea561216a52c884c4ca30b51",uri="sip:ssw.on.n et.mk",algorithm=MD5,qop=auth,nc=00000001,cnonce=" fc1f0
Here in this message Avaya is not repeating the opaque value
According the SIP draft, for opaque parameter:
The server can put anything it wants to into the value. The client MUST just return that value if present in the Authorization header.
Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information.
Note that any such use can also be accomplished more easily and safely by including the state in the nonce.
As I see IP Office hasn’t implemented opaque value in the authentication parameters.
We have the same problem with another softswitch, and we don't have with problem with for example Skype. But, Skype is using only nonce and not opaque in the Digest authorization parameters.
I need your opinion is my understanding correct. How we can solve this problem. Is there something that can be changed in the configuration?
We have analyzed the Wireshark logs and come to following conclusion:
- After first Register message sent by IP Office, Iskratel is sending Unauthorized messaging, then IP Office is sending another Register message with authentication header, and then Iskratel responds with 403 Forbidden.
- In the Unauthorized message the Iskratel is giving the parameters for the authentication
WWW-Authenticate: Digest realm="172.16.17.10",nonce="4c8f2d45d72386701f74e1 1bd1fde8e015058cdd",opaque="bceb4d62d1578aec6de6e3 b3c71c8223",qop="auth"
Here the server is using nonce and opaque value for the authentication. The opaque value is parameter that user agent (IP Office) should return unchanged to the server in the second Register message.
- IP office in the second register message is sending
[truncated] Authorization: Digest username="5119013",realm="172.16.17.10",nonce="4c8 f2d45d72386701f74e11bd1fde8e015058cdd",response="9 7d36b28ea561216a52c884c4ca30b51",uri="sip:ssw.on.n et.mk",algorithm=MD5,qop=auth,nc=00000001,cnonce=" fc1f0
Here in this message Avaya is not repeating the opaque value
According the SIP draft, for opaque parameter:
The server can put anything it wants to into the value. The client MUST just return that value if present in the Authorization header.
Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information.
Note that any such use can also be accomplished more easily and safely by including the state in the nonce.
As I see IP Office hasn’t implemented opaque value in the authentication parameters.
We have the same problem with another softswitch, and we don't have with problem with for example Skype. But, Skype is using only nonce and not opaque in the Digest authorization parameters.
I need your opinion is my understanding correct. How we can solve this problem. Is there something that can be changed in the configuration?
Comment