Send Serusers mailing list submissions to
serusers@lists.iptel.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.iptel.org/mailman/listinfo/serusers
or, via email, send a message with subject or body 'help' to
serusers-request@iptel.org

You can reach the person managing the list at
serusers-owner@lists.iptel.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Serusers digest..."


Today's Topics:

1. FREEBSD ser cvs adn 0.90 ERROR ( )
2. Re: http / https in Userloc db (Jan Janak)
3. Re: http / https in Userloc db (Martin Koenig)
4. Re: RTP Wiretapping (Java Rockx)
5. Re: http / https in Userloc db (Jan Janak)
6. Re: http / https in Userloc db (Marian Dumitru)
7. compiling LCR into 0.10-dev (Iqbal)
8. Re: http / https in Userloc db (Jan Janak)
9. serweb question (johnny Laura)
10. Problem with SER and RADIUS on the different machine (Alex Jeon)
11. Re: serweb question (Alistair Cunningham)
12. Re: RTP Wiretapping (Steve Blair)
13. Got Error in Nathelper "extract_mediaip: no `c=' in SDP"
(Markus Monka)
14. Re: username of from with avp_check (Marian Dumitru)
15. RE: Outbound proxy definition (Vitaly Nikolaev)
16. problem (soft phoe is onfigured with SIP Express Router)
(anil pal)
17. Re: rtpproxy must be located on the same machine with SIP
server?? (Mohammad Khan)
18. Claims of ser-0.9 RFC3261 Violation (Java Rockx)
19. RE: Claims of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)
20. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)
21. Mediaproxy error (Terry Mac Millan)
22. Re: Claims of ser-0.9 RFC3261 Violation (Klaus Darilion)
23. RE: Claims of ser-0.9 RFC3261 Violation (Linda Xiao)
24. SER+SERWEB+MSILO (harry gaillac)
25. log question (Mohammad Khan)
26. RE: Claims of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)
27. RE: log question (Vitaly Nikolaev)
28. Re: Mediaproxy error (Terry Mac Millan)
29. RE: Claims of ser-0.9 RFC3261 Violation (Jain, Rajnish)
30. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)
31. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)
32. compiling LCR into 0.10-dev (Juha Heinanen)
33. Re: compiling LCR into 0.10-dev (Iqbal)
34. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)
35. RE: Claims of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)
36. :-(( (Mohammad Khan)


----------------------------------------------------------------------

Message: 1
Date: Wed, 02 Mar 2005 14:03:08 +0800
From: " "
Subject: [Serusers] FREEBSD ser cvs adn 0.90 ERROR
To: serusers@lists.iptel.org
Message-ID: <20050302060308.CCE8F13D@mail.fivewall.com>
Content-Type: text/plain; charset=

Hi! all
FreeBSD 5.3,latest cvs and 0.90 have problem when /usr/local/sbin/serctl get


ser# ps -ax
PID TT STAT TIME COMMAND
0 ?? DLs 0:00.01 [swapper]
1 ?? SLs 0:00.07 /sbin/init --
2 ?? DL 0:00.03 [g_event]
3 ?? DL 0:00.12 [g_up]
4 ?? DL 0:00.30 [g_down]
5 ?? DL 0:00.00 [thread taskq]
6 ?? DL 0:00.00 [kqueue taskq]
7 ?? IL 0:00.00 [acpi_task0]
8 ?? IL 0:00.00 [acpi_task1]
9 ?? IL 0:00.00 [acpi_task2]
10 ?? DL 0:00.00 [ktrace]
11 ?? RL 6:47.97 [idle]
12 ?? WL 0:00.00 [irq1: atkbd0]
13 ?? WL 0:00.00 [irq3: sio1]
14 ?? WL 0:00.00 [irq4: sio0]
15 ?? WL 0:00.00 [irq5:]
16 ?? WL 0:00.00 [irq6: fdc0]
17 ?? WL 0:00.00 [irq7: ppc0]
18 ?? WL 0:00.00 [irq8: rtc]
19 ?? WL 0:00.00 [irq9: acpi0]
20 ?? WL 0:00.00 [irq10:]
21 ?? WL 0:00.00 [irq11:]
22 ?? WL 0:00.00 [irq12: psm0]
23 ?? WL 0:00.00 [irq13:]
24 ?? WL 0:00.06 [irq14: ata0]
25 ?? WL 0:00.00 [irq15: ata1]
26 ?? WL 0:00.00 [irq16:]
27 ?? WL 0:00.00 [irq17: bt0]
28 ?? WL 0:00.04 [irq18: lnc0]
29 ?? WL 0:00.00 [irq19: uhci0]
30 ?? WL 0:00.00 [irq20:]
31 ?? WL 0:00.00 [irq21:]
32 ?? WL 0:00.00 [irq22:]
33 ?? WL 0:00.00 [irq23:]
34 ?? WL 0:00.00 [irq0: clk]
35 ?? WL 0:00.63 [swi5: clock sio]
36 ?? WL 0:00.00 [swi4: vm]
37 ?? WL 0:00.03 [swi1: net]
38 ?? DL 0:00.04 [yarrow]
39 ?? WL 0:00.00 [swi6:+]
40 ?? WL 0:00.00 [swi2: camnet]
41 ?? WL 0:00.00 [swi3: cambio]
42 ?? WL 0:00.00 [swi6: acpitaskq]
43 ?? WL 0:00.00 [swi6: task queue]
44 ?? WL 0:00.06 [swi6:+]
45 ?? DL 0:00.00 [usb0]
46 ?? DL 0:00.00 [usbtask]
47 ?? WL 0:00.00 [swi0: sio]
48 ?? DL 0:00.00 [fdc0]
49 ?? DL 0:00.00 [pagedaemon]
50 ?? DL 0:00.00 [vmdaemon]
51 ?? DL 0:00.59 [pagezero]
52 ?? DL 0:00.00 [bufdaemon]
53 ?? DL 0:00.03 [syncer]
54 ?? DL 0:00.00 [vnlru]
55 ?? DL 0:00.01 [hpt_wt]
56 ?? IL 0:00.00 [nfsiod 0]
57 ?? IL 0:00.00 [nfsiod 1]
58 ?? IL 0:00.00 [nfsiod 2]
59 ?? IL 0:00.00 [nfsiod 3]
60 ?? DL 0:00.07 [schedcpu]
179 ?? Is 0:00.00 adjkerntz -i
245 ?? Ss 0:00.03 /sbin/dhclient lnc0
272 ?? Is 0:00.00 /sbin/devd
292 ?? Ss 0:00.04 /usr/sbin/syslogd -s
367 ?? Ss 0:00.01 /usr/sbin/usbd
403 ?? Ss 0:00.03 /usr/sbin/sshd
409 ?? Ss 0:00.04 sendmail: accepting connections (sendmail)
413 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for /var/spool/client
425 ?? Ss 0:00.02 /usr/sbin/cron -s
439 ?? Ss 0:00.18 /usr/local/sbin/httpd
471 ?? I 0:00.07 /usr/local/sbin/ser -P /var/run/ser.pid
472 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
473 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
474 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
475 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
476 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
477 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
478 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
479 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
480 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
481 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
482 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
483 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
484 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
485 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
486 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
487 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
488 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid
489 ?? S 0:00.08 /usr/local/sbin/ser -P /var/run/ser.pid
490 ?? S 0:00.04 /usr/local/sbin/ser -P /var/run/ser.pid
491 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid
492 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid
493 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid
494 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid
495 ?? S 0:00.04 /usr/local/sbin/ser -P /var/run/ser.pid
496 ?? S 0:00.02 /usr/local/sbin/ser -P /var/run/ser.pid
497 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid
498 ?? S 0:00.02 /usr/local/sbin/ser -P /var/run/ser.pid
499 ?? I 0:00.00 /usr/local/sbin/httpd
500 ?? I 0:00.00 /usr/local/sbin/httpd
501 ?? I 0:00.00 /usr/local/sbin/httpd
502 ?? I 0:00.00 /usr/local/sbin/httpd
503 ?? I 0:00.00 /usr/local/sbin/httpd
524 ?? Is 0:00.01 /usr/sbin/inetd -wW -C 60
583 ?? Ss 0:00.08 sshd: lynx [priv] (sshd)
586 ?? S 0:00.09 sshd: lynx@ttyp0 (sshd)
587 p0 Ss 0:00.04 -sh (sh)
588 p0 S 0:00.05 su
589 p0 S 0:00.08 _su (csh)
595 p0 R+ 0:00.03 ps -ax
536 v0 Is+ 0:00.01 /usr/libexec/getty Pc ttyv0
537 v1 Is+ 0:00.01 /usr/libexec/getty Pc ttyv1
538 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2
539 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3
540 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4
541 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5
542 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6
543 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7
443 con- I 0:00.04 /bin/sh /usr/local/bin/mysqld_safe --user=mysql --dat
468 con- S 0:01.00 /usr/local/libexec/mysqld --basedir=/usr/local --data
ser# serctl moni
[: unexpected operator
[: -ne: unexpected operator
ser#

----

ZhongShan Ether Network Security Inc
---------------------------------------------------------

------------------------------

Message: 2
Date: Wed, 2 Mar 2005 12:39:16 +0100
From: Jan Janak
Subject: Re: [Serusers] http / https in Userloc db
To: Marian Dumitru
Cc: serusers@lists.iptel.org, Martin Koenig

Message-ID: <20050302113916.GF3487@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-2

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.



------------------------------

Message: 3
Date: Wed, 02 Mar 2005 13:08:39 +0100
From: Martin Koenig
Subject: Re: [Serusers] http / https in Userloc db
To: Jan Janak
Cc: serusers@lists.iptel.org
Message-ID: <4225ACC7.8060500@toplink-plannet.de>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

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: (4) / (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: (4) / (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
>
>



------------------------------

Message: 4
Date: Wed, 2 Mar 2005 07:16:59 -0500
From: Java Rockx
Subject: Re: [Serusers] RTP Wiretapping
To: ser@cannes.f9.co.uk
Cc: serusers@lists.iptel.org
Message-ID: <359a65820503020416142a33c@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII

I was thinking about having a group called "spy" in the grp table and
anyone with this ACL would be sent to a modified mediaproxy that would
capture the RTP.

User that don't have the "spy" ACL would be handled normally and if
NAT traversal is needed then use an unmodified media proxy.

Regards,
Paul


On Wed, 2 Mar 2005 08:00:24 -0000, Chris wrote:
> Why not use a from/to etc detection in .cfg (using database...)
> to trigger a remote proxy through the requesting agency
> They then have the capture issue
> and you have no monitor or delivery issues?
> Might require conditions of their placement of a proxy?
> (but is their problem)
> Regards
> Chris
>
> -----Original Message-----
> From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On
> Behalf Of Java Rockx
> Sent: 26 February 2005 14:29
> To: serusers@lists.iptel.org
> Subject: [Serusers] RTP Wiretapping
>
> Hi All.
>
> I'm located in the US and would like to comply with the Communications
> Assistance for Law Enforcement Act (CALEA) that Congress passed which
> basically says that VoIP providers should have the ability to wiretap
> conversations for the FBI upon request.
>
> I use mediaproxy for NAT traversal. So my question is how can I be
> CALEA compliant? I assume I should be able to modify mediaproxy to
> write RTP streams to disk, but I'm unclear on how to "mix" both sides
> of the conversation.
>
> Can anyone help with a suggestion?
>
> Regards,
> Paul
>
> _______________________________________________
> Serusers mailing list
> serusers@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 25/02/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 28/02/2005
>
>



------------------------------

Message: 5
Date: Wed, 2 Mar 2005 13:42:03 +0100
From: Jan Janak
Subject: Re: [Serusers] http / https in Userloc db
To: Martin Koenig
Cc: serusers@lists.iptel.org
Message-ID: <20050302124203.GG3487@localhost.localdomain>
Content-Type: text/plain; charset=iso-8859-2

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: (4) / (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: (4) / (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
> >
> >
>



------------------------------

Message: 6
Date: Wed, 02 Mar 2005 14:04:12 +0100
From: Marian Dumitru
Subject: Re: [Serusers] http / https in Userloc db
To: Jan Janak
Cc: serusers@lists.iptel.org, Martin Koenig

Message-ID: <4225B9CC.304@voice-sistem.ro>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

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: (4) / (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: (4) / (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

=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com