Hi,
Nils, you are very correct :)
As a result of the discussion, I'd suggest implementing an Usrloc configuration parameter to enable ignoration of non sip URIs on save("location"). My guess is that the vast majority of all users does not need any other form of contact in their usrloc db than sip. Those that need it for redirection servers could enable it by configuration parameter.
The huge advantage of such solution would be that a "clean" usrloc database for all other ser modules (nathelper, mediaproxy, who knows what else) could be implemented by just one change to the usrloc module. I am not really sure that all errors and itches caused by non-sip contacts in usrloc result only in a syslog error, maybe rather unpredictable behaviour might be the case (e.g. buffer problems)? Also, I don't think that a ser setup with this restriction would be called non-RFC3261 compilant? What do you guys think?
With best regards, Martin
Nils Ohlmeier schrieb:
Hello Martin,
a small hint for your customer(s) (as you probably do not have direct access to this snom phone): if you set the option "Reigster http contact" to off, then there will be no http Contacts, but an WWW-Contact instead. But as provider you should be prepared to receive any valid (and even in-valid) URI's :-)
Regards Nils Ohlmeier
On Wednesday 02 March 2005 10:19, Martin Koenig wrote:
Here is the according REGISTER request:
REGISTER sip:toplink-voice.de SIP/2.0. Via: SIP/2.0/UDP 192.168.0.206:2051;branch=z9hG4bK-nl2lqphgqhwx;rport. From: "Toplink" sip:D1089081000@toplink-voice.de;tag=tcxf5l3ttk. To: "Toplink" sip:D1089081000@toplink-voice.de. Call-ID: 3c267009b239-jdcz81xdwoag@snom360. CSeq: 549 REGISTER. Max-Forwards: 70. Contact: sip:D1089081000@192.168.0.206:2051;line=syp6dded;q=1.0;+sip.instance="<ur n:uuid:fd0d970e-34fc-48aa-8007-4a9c64a1231a>";audio;mobility="fixed";duplex= "full";description="snom360";actor="principal";events="dialog";methods="INVI TE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO". Contact: http://192.168.0.206:80. Contact: https://192.168.0.206:443 User-Agent: snom360-3.57t. P-NAT-Refresh: 15;method="crlf,stun". Supported: gruu. Allow-Events: dialog. X-Real-IP: 192.168.0.206. Authorization: Digest username="xxx",realm="toplink-voice.de",nonce="xxx",uri="sip:toplink-voice. de",qop=auth,nc=00000001,cnonce="xxx",response="xxx",algorithm=md5. Expires: 3600. Content-Length: 0. .
See the strange Contact Header field. This is probably a Bug in the SNOM hardphone. Nevertheless, the contacts should not end up in UserLoc?
Regards, Martin
Martin Koenig schrieb:
Hello,
how can something like this happen:
domain : 'location' aor : 'd1089081000' Contact : 'http://192.168.0.206:80' Expires : 2981 q : 0.00 Call-ID : '3c267009b239-jdcz81xdwoag@snom360' CSeq : 547 replic : 0 User-Agent: 'snom360-3.57t' State : CS_NEW Flags : 1 next : 0x422c04d0 prev : 0x422bf330 ~~~/Contact~~~~ ~~~Contact(0x422c04d0)~~~ domain : 'location' aor : 'd1089081000' Contact : 'https://192.168.0.206:443' Expires : 2981 q : 0.00 Call-ID : '3c267009b239-jdcz81xdwoag@snom360' CSeq : 547 replic : 0 User-Agent: 'snom360-3.57t' State : CS_NEW Flags : 1 next : (nil) prev : 0x422be558 ~~~/Contact~~~~ HTTP/HTTPS contacts in userloc? Causes the following error, besides that calls to that contact will probably fail: Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / <http://192.168.0.206:80> (23) Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: error: mediaproxy/pingClients(): can't parse contact uri Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / <https://192.168.0.206:443> (25) Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: error: mediaproxy/pingClients(): can't parse contact uri How can this uri get into Usrloc in the first place? With best regards, Martin _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers