Ivan, If you could create an account for me and send me the credentials, i'll try to look into it.
Thanks Vadim Ivan McShane wrote: > 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 > > >
_______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
