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
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="urn:uuid:fd0d970e-34fc-48aa-8007-4a9c64a1231a";audio;mobility="fixed";duplex="full";description="snom360";actor="principal";events="dialog";methods="INVITE,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
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it advertise the http location of the web configuration page. But if recall correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact validity before inserting into usrloc.
Best regards, Marian
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="urn:uuid:fd0d970e-34fc-48aa-8007-4a9c64a1231a";audio;mobility="fixed";duplex="full";description="snom360";actor="principal";events="dialog";methods="INVITE,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
On 02-03 10:32, Marian Dumitru wrote:
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it advertise the http location of the web configuration page. But if recall correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact validity before inserting into usrloc.
That's one interesting question. What is a valid contact ? A regular proxy would not be able to contact URI with http scheme, that's clear. But that does not mean yet that the contact is not valid, because RFC3261 allows any sort of URI to appear there.
On the other hand, a redirect server would just take this URI, put it into a 3xx response and send it back the the calling UA. If the calling UA is unable to reach the called party, it might display the contents of the HTTP URL or do some other magic.
For that reason I think that there should be no limitation of what gets into the user location database.
Jan.
Jan,
if any uri (according to RFC) is allowed in URI, then ser should not issue an error message on lookup("location"):
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / http://192.168.0.206:80 (23) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: http://192.168.0.206:80 Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / https://192.168.0.206:443 (25) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: https://192.168.0.206:443
Especially not a "bad_uri" error message, because it is not a bad uri indeed. Some debug-warning about ignoring this or that contact because it was not SIP/SIPS will do. What do you think?
Either way, I think there is need for some cleanup.
Regards, Martin
Jan Janak schrieb:
On 02-03 10:32, Marian Dumitru wrote:
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it advertise the http location of the web configuration page. But if recall correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact validity before inserting into usrloc.
That's one interesting question. What is a valid contact ? A regular proxy would not be able to contact URI with http scheme, that's clear. But that does not mean yet that the contact is not valid, because RFC3261 allows any sort of URI to appear there.
On the other hand, a redirect server would just take this URI, put it into a 3xx response and send it back the the calling UA. If the calling UA is unable to reach the called party, it might display the contents of the HTTP URL or do some other magic.
For that reason I think that there should be no limitation of what gets into the user location database.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
The error message is not issued by lookup("location"), it is issued by t_relay() when you try to forward the message to the HTTP URI.
It should be easy to write a function that would be called before t_relay (or after lookup) and that would filter out URI schemes unsupported by SER.
For the Request-URI you can do that from the script:
if (uri =~ "^http") { do something };
But that would not check additional branches used for parallel forking.
Jan.
On 02-03 13:08, Martin Koenig wrote:
Jan,
if any uri (according to RFC) is allowed in URI, then ser should not issue an error message on lookup("location"):
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / http://192.168.0.206:80 (23) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: http://192.168.0.206:80 Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / https://192.168.0.206:443 (25) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: https://192.168.0.206:443
Especially not a "bad_uri" error message, because it is not a bad uri indeed. Some debug-warning about ignoring this or that contact because it was not SIP/SIPS will do. What do you think?
Either way, I think there is need for some cleanup.
Regards, Martin
Jan Janak schrieb:
On 02-03 10:32, Marian Dumitru wrote:
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it advertise the http location of the web configuration page. But if recall correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact validity before inserting into usrloc.
That's one interesting question. What is a valid contact ? A regular proxy would not be able to contact URI with http scheme, that's clear. But that does not mean yet that the contact is not valid, because RFC3261 allows any sort of URI to appear there.
On the other hand, a redirect server would just take this URI, put it into a 3xx response and send it back the the calling UA. If the calling UA is unable to reach the called party, it might display the contents of the HTTP URL or do some other magic.
For that reason I think that there should be no limitation of what gets into the user location database.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Jan,
So some URI checking is required and indeed, if you want to allow clients to perform that magic you mentioned, the checking should be done after extracting the URIs from usrloc. But should be very clear if a contact URI can or cannot be involved in SIP signaling - used for forwarding. One note here - it's interesting what will be the impact on nathelper when it will start doing NAT ping to non-SIP URIs :-). Anyhow, the best place to do the checking is before t_relay(). If you do th filtering immediately after lookup(), you will loose the Redirect Server functionality.
Best regards, Marian
Jan Janak wrote:
The error message is not issued by lookup("location"), it is issued by t_relay() when you try to forward the message to the HTTP URI.
It should be easy to write a function that would be called before t_relay (or after lookup) and that would filter out URI schemes unsupported by SER.
For the Request-URI you can do that from the script:
if (uri =~ "^http") { do something };
But that would not check additional branches used for parallel forking.
Jan.
On 02-03 13:08, Martin Koenig wrote:
Jan,
if any uri (according to RFC) is allowed in URI, then ser should not issue an error message on lookup("location"):
Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / http://192.168.0.206:80 (23) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: http://192.168.0.206:80 Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / https://192.168.0.206:443 (25) Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: https://192.168.0.206:443
Especially not a "bad_uri" error message, because it is not a bad uri indeed. Some debug-warning about ignoring this or that contact because it was not SIP/SIPS will do. What do you think?
Either way, I think there is need for some cleanup.
Regards, Martin
Jan Janak schrieb:
On 02-03 10:32, Marian Dumitru wrote:
Hi Martin,
As far as I know it could be one of the new SNOM specific feature - it advertise the http location of the web configuration page. But if recall correctly, the header name should by WWW-Contact, not Contact.
Anyhow, it will be a good idea for register to check the contact validity before inserting into usrloc.
That's one interesting question. What is a valid contact ? A regular proxy would not be able to contact URI with http scheme, that's clear. But that does not mean yet that the contact is not valid, because RFC3261 allows any sort of URI to appear there.
On the other hand, a redirect server would just take this URI, put it into a 3xx response and send it back the the calling UA. If the calling UA is unable to reach the called party, it might display the contents of the HTTP URL or do some other magic.
For that reason I think that there should be no limitation of what gets into the user location database.
On 02-03 14:04, Marian Dumitru wrote:
Hi Jan,
So some URI checking is required and indeed, if you want to allow clients to perform that magic you mentioned, the checking should be done after extracting the URIs from usrloc. But should be very clear if a contact URI can or cannot be involved in SIP signaling - used for forwarding. One note here - it's interesting what will be the impact on nathelper when it will start doing NAT ping to non-SIP URIs :-).
When fix_nated_register is used then napinger will use the URI from received column of location table, that URI will be sip: so it should work fine.
If the received column is empty then NAT pinger will be given the real contact -- which would contain http scheme in this case -- and it would fail parsin the URI. nat_pinger would probably generate lots of error messages to syslog in this case :-).
Anyhow, the best place to do the checking is before t_relay(). If you do th filtering immediately after lookup(), you will loose the Redirect Server functionality.
Yes, unless there are some other functions in between which would need to parse the Request-URI (parsing would fail).
Jan.
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
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
On 02-03 23:28, Martin Koenig wrote:
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.
I would dare to disagree. Solving this problem outside usrloc is in my opinion better.
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.
What constitutes a "clean" usrloc database ? Is it just sip uris ? Should tel uris be included ? How about sips, pres which are widely used in existing RFCs and drafts ?
RFC3261 says that the registrar must either process all contacts in a REGISTER message or refuse all of them. To be compliant, shall we reject all REGISTER messages that include "unclean" contacts ?
As you can see there are many open questions and ignoring just http uris would be not enough.
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)?
Do you have any particular problem in mind ?
Also, I don't think that a ser setup with this restriction would be called non-RFC3261 compilant? What do you guys think?
If you want to be really strictly compliant, then you would need to reject a REGISTER message that contains a Contact which your proxy is not willing to process. If such a REGISTER message does not get rejected than even contacts having http scheme in URI must be included in 200 OK. In this case the UA would assume that the contact is stored in the user location database.
Jan.
-
Jan Janak -
Marian Dumitru -
Martin Koenig -
Nils Ohlmeier