2 Mar
2005
2 Mar
'05
11:28 p.m.
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:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Hello,
how can something like this happen:
~~~Contact(0x422be558)~~~
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers