Hi Ivan, It seems that we're managing to register (i'm getting back 200 OK from your sup server) but our sip message parse somehow chokes on your Athentication-Info header... I'm digging into it.
Thanks Vadim Ivan McShane wrote: > Hi Vadim, > > Did you get a chance to look at this issue? > > Thanks, > Ivan > > On 26 Jun 2009, at 10:37, Ivan McShane wrote: > >> Hi again Vadim, >> >> Our firewall issue has been resolved. >> >> You can log into our registrar with the following details: >> ....... >> Cheers, >> Ivan >> >> On 23 Jun 2009, at 13:42, Ivan McShane wrote: >> >>> Hi Vadim, >>> >>> Captures attached. I ran three different use cases. One with the >>> loopback ip address, and two with the lan IP address used for the >>> proxy server setting. One of the lan IP addresses had authentication >>> enabled, the other didn't. Of the three cases the only one that >>> worked was when authentication was disabled. >>> >>> SIP listener port for the server is 5065 and it's running on the >>> same machine as the QuteCom client. >>> >>> As per my mail to the distro I also had to configure the server to >>> ignore the request-uri domain in the REGISTER message as it's using >>> the proxy IP rather than the aor domain. >>> >>> If you need anything else let me know. >>> >>> Best regards, >>> Ivan >>> >>> <qutecom_no_auth_loopback_addr.snoop> >>> <qutecom_noauth_lan_addr.snoop> >>> <qutecom_withauth_lan_addr.snoop> >>> >>> <Picture 1.png> >>> >>> <Picture 2.png> >>> >>> On 22 Jun 2009, at 19:45, Vadim Lebedev wrote: >>> >>>> Ok... >>>> You can try and post wireshark traces... >>>> >>>> Thanks >>>> Vadim >>>> Le 22 juin 09 à 10:52, Ivan McShane a écrit : >>>> >>>>> Hi Vadim, >>>>> >>>>> Apologies but I won't be able to set this up for you today. A >>>>> firewall issue outside my control means I can't provide external >>>>> access at present. >>>>> >>>>> Your offer of assistance is very much appreciated and I'll get >>>>> back to you on this as soon as I can. >>>>> >>>>> Thanks, >>>>> Ivan >>>>> >>>>> On 20 Jun 2009, at 13:37, Ivan McShane wrote: >>>>> >>>>>> Thanks Vadim. >>>>>> >>>>>> I'll arrange this on Monday and get back to you with the details. >>>>>> >>>>>> Cheers, >>>>>> Ivan >>>>>> >>>>>> On 19 Jun 2009, at 14:04, Vadim Lebedev wrote: >>>>>> >>>>>>> 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
