Hi Folks, I'm guessing no replies mean no-one has had this problem before.
I don't have much more info to add to what's below. Further testing has just verified what we observed originally. We did manage to get a succsessful registration but it involved making undesirable configuration changes. We have tried testing with no digest authentication required and still encounter the same problems. The request URI and AOR use the proxy address rather than domain during registration and the 200 OK from the server is ignored. The problem definitely appears to be related to how QuteCom is handling URIs. We can set-up two identical configurations with the only difference being whether localhost or the external IP address is used for the SIP proxy address in QuteCom. The latter works the former doesn't and the issue seems to be 200 OK messages being ignored by QuteCom when the domain and contact address don't match. Note: this means we did get a successful registration but only when: - Digest authentication disabled on the server - All config for a co-located softphone and server had conflicting ports changed - All QuteCom config used the external Ip addr rather than the loopback - The server was configured to ignore qutecom using host name rather than domain for registration requests. The problem isn't that QuteCom can't authenticate the server, as mentioned in the mail below it can reply with the correct challenge response, but the way it handles request URIs means the sequence never completes. All these configuration tweaks we're making are very non-standard and we haven't had the same issue with other soft-phones. Any ideas where we're going wrong? Any help would be much appreciated. Cheers, Ivan On 5 Jun 2009, at 17:01, Ivan McShane wrote: > Hi, > > First time posting here, hopefully this is a trivial problem. We're > currently evaluating which SIP clients we'll recommend for users as > part of our SIP application product. We'd like to include QuteCom > but we're having issues integrating it with our SIP application > server. The same set-up has been tested and worked with several > other clients. > > The email below is longer than I expected, so in summary my > questions are primarily: > - Why is the proxy setting used rather than domain setting for the > domain during registration? > - Why are authentication challenges ignored if the proxy setting > doesn't match the challenge domain? > - Is there a known issue why the REGISTER->200 OK sequence would get > stuck in a loop? > > Longer version, with more info ..... > > The problems we've encountered stem from authentication during > registration. Our registrar requires digest-authentication and the > QuteCom client does not perform in a similar manner to other soft- > phones we've tested against. > > A secondary problem is testing client and server on a single machine > which is a development requirement. > > We're confident that the QuteCom client does support the > authentication mechanism as it will authenticate under certain > circumstances so it's probably a configuration/environment issue. > > Problem: > - The "SIP Domain / Realm" configuration setting seems to be ignored > in preference to the "Proxy" setting. Unless proxy name matches the > realm the client uses the wrong Request-URI on registration. It is > very unlikely our proxy address will match the domain name on most > deployments so this is a blocking issue for us. > - As above, when the authentication challenge domain matches the > configured client domain it is ignored unless the proxy also > matches. The client is receiving the 401 because the rport response > is being added to the contact header on subsequent registration > requests. > - If the proxy matches the domain it will authenticate but then it > seems to get stuck in a loop of resending the challenge response and > ignoring the 200 OK. On the UI it states the login has timed out. > > Environment Summary: > OS - OS X 10.5.6 > Client - QuteCom 2.2 > Sip Server - Sailfin b60 > Proxy and client on same machine. > > I've pasted a capture of the SIP dialogue below. You'll notice to > run on a single machine I had to change the QuteCom sip port from > 5060 to another value (5069 in this case). I also had to alias > "vennetics.com" to 192.168.0.2 (my local ip) or the client didn't > work due to the proxy issues mentioned above. > > If anyone can assist with this issue it would be much appreciated. > At this point in time we've not managed to successfully register. > > Regards, > Ivan McShane > > ....... > > SIP Capture ............... > > interface: lo0 (127.0.0.0/255.0.0.0) > filter: (ip) and ( port 5060 ) > > U 2009/06/05 16:25:29.553758 192.168.0.2:5069 -> 192.168.0.2:5060 > REGISTER sip:vennetics.com SIP/2.0. > Via: SIP/2.0/UDP 192.168.0.2:5069;rport;branch=1110365530. > Route: <sip:vennetics.com;lr>. > From: nobody <sip:[email protected]>;tag=1439047492. > To: <sip:[email protected]>. > Call-ID: 1413129095. > Contact: <sip:[email protected]>. > CSeq: 1482125064 REGISTER. > X-Wengo-Ping: network test. > Content-Length: 0. > . > > > U 2009/06/05 16:25:29.556531 192.168.0.2:5060 -> 192.168.0.2:5069 > SIP/2.0 401 Unauthorized. > Content-Length: 0. > Www-Authenticate: Digest realm="vennetics.com", qop="auth", > nonce="2e2d252205022f2a0a270d29032f0526", > opaque="2e2d252205022f2a0a270d29032f0526",stale=false. > To: <sip:[email protected]>;tag=fvl1suvn-au. > Cseq: 1482125064 REGISTER. > Via: SIP/2.0/UDP > 192.168.0.2:5069;rport=5069;branch=1110365530;received=192.168.0.2. > Call-Id: 1413129095. > From: "nobody"<sip:[email protected]>;tag=1439047492. > Server: Glassfish_SIP_1.0.0. > . > > > U 2009/06/05 16:25:29.582647 192.168.0.2:5069 -> 192.168.0.2:5060 > REGISTER sip:vennetics.com SIP/2.0. > Via: SIP/2.0/UDP 192.168.0.2:5069;rport;branch=z9hG4bK2075023583. > From: <sip:[email protected]>;tag=1005059434. > To: <sip:[email protected]>. > Call-ID: [email protected]. > CSeq: 1 REGISTER. > Contact: <sip:[email protected]:5069>. > Max-Forwards: 70. > User-Agent: wengo/v1/wengophoneng/wengo/rev49cd2a2682c9/trunk/. > Expires: 2940. > Content-Length: 0. > . > > > U 2009/06/05 16:25:29.585916 192.168.0.2:5060 -> 192.168.0.2:5069 > SIP/2.0 401 Unauthorized. > Content-Length: 0. > Www-Authenticate: Digest realm="vennetics.com", qop="auth", > nonce="0107052e052b250b050a21272909240e", > opaque="0107052e052b250b050a21272909240e",stale=false. > To: <sip:[email protected]>;tag=fvl1suwg-av. > Cseq: 1 REGISTER. > Via: SIP/2.0/UDP > 192.168.0.2 > :5069;rport=5069;branch=z9hG4bK2075023583;received=192.168.0.2. > Call-Id: [email protected]. > From: <sip:[email protected]>;tag=1005059434. > Server: Glassfish_SIP_1.0.0. > . > > > U 2009/06/05 16:25:29.587122 192.168.0.2:5069 -> 192.168.0.2:5060 > REGISTER sip:vennetics.com SIP/2.0. > Via: SIP/2.0/UDP 192.168.0.2:5069;rport;branch=z9hG4bK1934415848. > From: <sip:[email protected]>;tag=1005059434. > To: <sip:[email protected]>. > Call-ID: [email protected]. > CSeq: 2 REGISTER. > Contact: <sip:[email protected]:5069>. > Authorization: Digest username="bob", realm="vennetics.com", > nonce="0107052e052b250b050a21272909240e", uri="sip:vennetics.com", > response="6e86c78924b39299648e4768fa501b23", algorithm=MD5, > opaque="0107052e052b250b050a21272909240e". > Max-Forwards: 70. > User-Agent: wengo/v1/wengophoneng/wengo/rev49cd2a2682c9/trunk/. > Expires: 2940. > Content-Length: 0. > . > > > U 2009/06/05 16:25:29.631334 192.168.0.2:5060 -> 192.168.0.2:5069 > SIP/2.0 200 OK. > Authentication-Info: > nextnonce="0c20042d05292b0e24012d29242d0d2f",qop="auth",nc=null. > Date: Fri, 5 Jun 2009 16:25:29 BST. > Content-Length: 0. > To: <sip:[email protected]>;tag=fvl1suxp-aw. > Contact: <sip:[email protected]:5069>;expires=2939. > Cseq: 2 REGISTER. > Via: SIP/2.0/UDP > 192.168.0.2 > :5069;rport=5069;branch=z9hG4bK1934415848;received=192.168.0.2. > Call-Id: [email protected]. > From: <sip:[email protected]>;tag=1005059434. > Server: Glassfish_SIP_1.0.0. > . > > > U 2009/06/05 16:25:30.087436 192.168.0.2:5069 -> 192.168.0.2:5060 > REGISTER sip:vennetics.com SIP/2.0. > Via: SIP/2.0/UDP 192.168.0.2:5069;rport;branch=z9hG4bK1934415848. > From: <sip:[email protected]>;tag=1005059434. > To: <sip:[email protected]>. > Call-ID: [email protected]. > CSeq: 2 REGISTER. > Contact: <sip:[email protected]:5069>. > Authorization: Digest username="bob", realm="vennetics.com", > nonce="0107052e052b250b050a21272909240e", uri="sip:vennetics.com", > response="6e86c78924b39299648e4768fa501b23", algorithm=MD5, > opaque="0107052e052b250b050a21272909240e". > Max-Forwards: 70. > User-Agent: wengo/v1/wengophoneng/wengo/rev49cd2a2682c9/trunk/. > Expires: 2940. > Content-Length: 0. > . > > > U 2009/06/05 16:25:30.088993 192.168.0.2:5060 -> 192.168.0.2:5069 > SIP/2.0 200 OK. > Authentication-Info: > nextnonce="0c20042d05292b0e24012d29242d0d2f",qop="auth",nc=null. > Date: Fri, 5 Jun 2009 16:25:29 BST. > Content-Length: 0. > To: <sip:[email protected]>;tag=fvl1suxp-aw. > Contact: <sip:[email protected]:5069>;expires=2939. > Cseq: 2 REGISTER. > Via: SIP/2.0/UDP > 192.168.0.2 > :5069;rport=5069;branch=z9hG4bK1934415848;received=192.168.0.2. > Call-Id: [email protected]. > > > .... repeats forever .... _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
