<DIV>hi list..</DIV>
<DIV>i am winda </DIV>
<DIV>i make SER and it work well in local network. when i establish SER server in public network. it cannot run. i have read the milist and the solution are nethelper and mediaproxy/rtp proxy. i want ask how to start to make nathelper+rtp proxy? please explain me step by step?...</DIV>
<DIV>oh ya.. i also read about rtp proxy, maxim's rtp proxy and media proxy. can you explain me what is the different?</DIV>
<DIV>Thanks for help....:-)<BR><BR><B><I>serusers-request@lists.iptel.org</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Send Serusers mailing list submissions to<BR>serusers@lists.iptel.org<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>http://lists.iptel.org/mailman/listinfo/serusers<BR>or, via email, send a message with subject or body 'help' to<BR>serusers-request@iptel.org<BR><BR>You can reach the person managing the list at<BR>serusers-owner@lists.iptel.org<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of Serusers digest..."<BR><BR><BR>Today's Topics:<BR><BR>1. FREEBSD ser cvs adn 0.90 ERROR ( )<BR>2. Re: http / https in Userloc db (Jan Janak)<BR>3. Re: http / https in Userloc db (Martin Koenig)<BR>4. Re: RTP Wiretapping (Java Rockx)<BR>5. Re: http / https in Userloc db (Jan Janak)<BR>6. Re: http / https in Userloc db (Marian Dumitru)<BR>7. compiling LCR into 0.10-dev (Iqbal)<BR>8. Re: http / https in Userloc db (Jan Janak)<BR>9. serweb
question (johnny Laura)<BR>10. Problem with SER and RADIUS on the different machine (Alex Jeon)<BR>11. Re: serweb question (Alistair Cunningham)<BR>12. Re: RTP Wiretapping (Steve Blair)<BR>13. Got Error in Nathelper "extract_mediaip: no `c=' in SDP"<BR>(Markus Monka)<BR>14. Re: username of from with avp_check (Marian Dumitru)<BR>15. RE: Outbound proxy definition (Vitaly Nikolaev)<BR>16. problem (soft phoe is onfigured with SIP Express Router)<BR>(anil pal)<BR>17. Re: rtpproxy must be located on the same machine with SIP<BR>server?? (Mohammad Khan)<BR>18. Claims of ser-0.9 RFC3261 Violation (Java Rockx)<BR>19. RE: Claims of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)<BR>20. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)<BR>21. Mediaproxy error (Terry Mac Millan)<BR>22. Re: Claims of ser-0.9 RFC3261 Violation (Klaus Darilion)<BR>23. RE: Claims of ser-0.9 RFC3261 Violation (Linda Xiao)<BR>24. SER+SERWEB+MSILO (harry gaillac)<BR>25. log question (Mohammad Khan)<BR>26. RE: Claims
of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)<BR>27. RE: log question (Vitaly Nikolaev)<BR>28. Re: Mediaproxy error (Terry Mac Millan)<BR>29. RE: Claims of ser-0.9 RFC3261 Violation (Jain, Rajnish)<BR>30. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)<BR>31. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)<BR>32. compiling LCR into 0.10-dev (Juha Heinanen)<BR>33. Re: compiling LCR into 0.10-dev (Iqbal)<BR>34. Re: Claims of ser-0.9 RFC3261 Violation (Java Rockx)<BR>35. RE: Claims of ser-0.9 RFC3261 Violation (Vitaly Nikolaev)<BR>36. :-(( (Mohammad Khan)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Wed, 02 Mar 2005 14:03:08 +0800<BR>From: " " <SER@FIVEWALL.COM><BR>Subject: [Serusers] FREEBSD ser cvs adn 0.90 ERROR<BR>To: serusers@lists.iptel.org<BR>Message-ID: <20050302060308.CCE8F13D@mail.fivewall.com><BR>Content-Type: text/plain; charset=<BR><BR>Hi! all<BR>FreeBSD 5.3,latest cvs and 0.90 have problem when
/usr/local/sbin/serctl get<BR><BR><BR>ser# ps -ax<BR>PID TT STAT TIME COMMAND<BR>0 ?? DLs 0:00.01 [swapper]<BR>1 ?? SLs 0:00.07 /sbin/init --<BR>2 ?? DL 0:00.03 [g_event]<BR>3 ?? DL 0:00.12 [g_up]<BR>4 ?? DL 0:00.30 [g_down]<BR>5 ?? DL 0:00.00 [thread taskq]<BR>6 ?? DL 0:00.00 [kqueue taskq]<BR>7 ?? IL 0:00.00 [acpi_task0]<BR>8 ?? IL 0:00.00 [acpi_task1]<BR>9 ?? IL 0:00.00 [acpi_task2]<BR>10 ?? DL 0:00.00 [ktrace]<BR>11 ?? RL 6:47.97 [idle]<BR>12 ?? WL 0:00.00 [irq1: atkbd0]<BR>13 ?? WL 0:00.00 [irq3: sio1]<BR>14 ?? WL 0:00.00 [irq4: sio0]<BR>15 ?? WL 0:00.00 [irq5:]<BR>16 ?? WL 0:00.00 [irq6: fdc0]<BR>17 ?? WL 0:00.00 [irq7: ppc0]<BR>18 ?? WL 0:00.00 [irq8: rtc]<BR>19 ?? WL 0:00.00 [irq9: acpi0]<BR>20 ?? WL 0:00.00 [irq10:]<BR>21 ?? WL 0:00.00 [irq11:]<BR>22 ?? WL 0:00.00 [irq12: psm0]<BR>23 ?? WL 0:00.00 [irq13:]<BR>24 ?? WL 0:00.06 [irq14: ata0]<BR>25 ?? WL 0:00.00 [irq15: ata1]<BR>26 ?? WL 0:00.00 [irq16:]<BR>27 ?? WL 0:00.00 [irq17: bt0]<BR>28 ?? WL 0:00.04 [irq18: lnc0]<BR>29
?? WL 0:00.00 [irq19: uhci0]<BR>30 ?? WL 0:00.00 [irq20:]<BR>31 ?? WL 0:00.00 [irq21:]<BR>32 ?? WL 0:00.00 [irq22:]<BR>33 ?? WL 0:00.00 [irq23:]<BR>34 ?? WL 0:00.00 [irq0: clk]<BR>35 ?? WL 0:00.63 [swi5: clock sio]<BR>36 ?? WL 0:00.00 [swi4: vm]<BR>37 ?? WL 0:00.03 [swi1: net]<BR>38 ?? DL 0:00.04 [yarrow]<BR>39 ?? WL 0:00.00 [swi6:+]<BR>40 ?? WL 0:00.00 [swi2: camnet]<BR>41 ?? WL 0:00.00 [swi3: cambio]<BR>42 ?? WL 0:00.00 [swi6: acpitaskq]<BR>43 ?? WL 0:00.00 [swi6: task queue]<BR>44 ?? WL 0:00.06 [swi6:+]<BR>45 ?? DL 0:00.00 [usb0]<BR>46 ?? DL 0:00.00 [usbtask]<BR>47 ?? WL 0:00.00 [swi0: sio]<BR>48 ?? DL 0:00.00 [fdc0]<BR>49 ?? DL 0:00.00 [pagedaemon]<BR>50 ?? DL 0:00.00 [vmdaemon]<BR>51 ?? DL 0:00.59 [pagezero]<BR>52 ?? DL 0:00.00 [bufdaemon]<BR>53 ?? DL 0:00.03 [syncer]<BR>54 ?? DL 0:00.00 [vnlru]<BR>55 ?? DL 0:00.01 [hpt_wt]<BR>56 ?? IL 0:00.00 [nfsiod 0]<BR>57 ?? IL 0:00.00 [nfsiod 1]<BR>58 ?? IL 0:00.00 [nfsiod 2]<BR>59 ?? IL 0:00.00 [nfsiod 3]<BR>60 ?? DL 0:00.07
[schedcpu]<BR>179 ?? Is 0:00.00 adjkerntz -i<BR>245 ?? Ss 0:00.03 /sbin/dhclient lnc0<BR>272 ?? Is 0:00.00 /sbin/devd<BR>292 ?? Ss 0:00.04 /usr/sbin/syslogd -s<BR>367 ?? Ss 0:00.01 /usr/sbin/usbd<BR>403 ?? Ss 0:00.03 /usr/sbin/sshd<BR>409 ?? Ss 0:00.04 sendmail: accepting connections (sendmail)<BR>413 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for /var/spool/client<BR>425 ?? Ss 0:00.02 /usr/sbin/cron -s<BR>439 ?? Ss 0:00.18 /usr/local/sbin/httpd<BR>471 ?? I 0:00.07 /usr/local/sbin/ser -P /var/run/ser.pid<BR>472 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>473 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>474 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>475 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>476 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>477 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>478 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>479 ?? I 0:00.00 /usr/local/sbin/ser -P
/var/run/ser.pid<BR>480 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>481 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>482 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>483 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>484 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>485 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>486 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>487 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>488 ?? I 0:00.00 /usr/local/sbin/ser -P /var/run/ser.pid<BR>489 ?? S 0:00.08 /usr/local/sbin/ser -P /var/run/ser.pid<BR>490 ?? S 0:00.04 /usr/local/sbin/ser -P /var/run/ser.pid<BR>491 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid<BR>492 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid<BR>493 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid<BR>494 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid<BR>495 ?? S 0:00.04 /usr/local/sbin/ser -P /var/run/ser.pid<BR>496 ?? S 0:00.02
/usr/local/sbin/ser -P /var/run/ser.pid<BR>497 ?? S 0:00.03 /usr/local/sbin/ser -P /var/run/ser.pid<BR>498 ?? S 0:00.02 /usr/local/sbin/ser -P /var/run/ser.pid<BR>499 ?? I 0:00.00 /usr/local/sbin/httpd<BR>500 ?? I 0:00.00 /usr/local/sbin/httpd<BR>501 ?? I 0:00.00 /usr/local/sbin/httpd<BR>502 ?? I 0:00.00 /usr/local/sbin/httpd<BR>503 ?? I 0:00.00 /usr/local/sbin/httpd<BR>524 ?? Is 0:00.01 /usr/sbin/inetd -wW -C 60<BR>583 ?? Ss 0:00.08 sshd: lynx [priv] (sshd)<BR>586 ?? S 0:00.09 sshd: lynx@ttyp0 (sshd)<BR>587 p0 Ss 0:00.04 -sh (sh)<BR>588 p0 S 0:00.05 su<BR>589 p0 S 0:00.08 _su (csh)<BR>595 p0 R+ 0:00.03 ps -ax<BR>536 v0 Is+ 0:00.01 /usr/libexec/getty Pc ttyv0<BR>537 v1 Is+ 0:00.01 /usr/libexec/getty Pc ttyv1<BR>538 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2<BR>539 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3<BR>540 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4<BR>541 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5<BR>542 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6<BR>543 v7 Is+ 0:00.01
/usr/libexec/getty Pc ttyv7<BR>443 con- I 0:00.04 /bin/sh /usr/local/bin/mysqld_safe --user=mysql --dat<BR>468 con- S 0:01.00 /usr/local/libexec/mysqld --basedir=/usr/local --data<BR>ser# serctl moni<BR>[: unexpected operator<BR>[: -ne: unexpected operator<BR>ser#<BR><BR>----<BR><BR>ZhongShan Ether Network Security Inc <BR>---------------------------------------------------------<BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Wed, 2 Mar 2005 12:39:16 +0100<BR>From: Jan Janak <JAN@IPTEL.ORG><BR>Subject: Re: [Serusers] http / https in Userloc db<BR>To: Marian Dumitru <MARIAN.DUMITRU@VOICE-SISTEM.RO><BR>Cc: serusers@lists.iptel.org, Martin Koenig<BR><MARTIN.KOENIG@TOPLINK-PLANNET.DE><BR>Message-ID: <20050302113916.GF3487@localhost.localdomain><BR>Content-Type: text/plain; charset=iso-8859-2<BR><BR>On 02-03 10:32, Marian Dumitru wrote:<BR>> Hi Martin,<BR>> <BR>> As far as I know it could be one of the new SNOM specific feature - it <BR>> advertise the http
location of the web configuration page. But if recall <BR>> correctly, the header name should by WWW-Contact, not Contact.<BR>> <BR>> Anyhow, it will be a good idea for register to check the contact <BR>> validity before inserting into usrloc.<BR><BR>That's one interesting question. What is a valid contact ? A regular<BR>proxy would not be able to contact URI with http scheme, that's clear.<BR>But that does not mean yet that the contact is not valid, because<BR>RFC3261 allows any sort of URI to appear there.<BR><BR>On the other hand, a redirect server would just take this URI, put it<BR>into a 3xx response and send it back the the calling UA. If the calling<BR>UA is unable to reach the called party, it might display the contents<BR>of the HTTP URL or do some other magic.<BR><BR>For that reason I think that there should be no limitation of what<BR>gets into the user location database.<BR><BR>Jan.<BR><BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date:
Wed, 02 Mar 2005 13:08:39 +0100<BR>From: Martin Koenig <MARTIN.KOENIG@TOPLINK-PLANNET.DE><BR>Subject: Re: [Serusers] http / https in Userloc db<BR>To: Jan Janak <JAN@IPTEL.ORG><BR>Cc: serusers@lists.iptel.org<BR>Message-ID: <4225ACC7.8060500@toplink-plannet.de><BR>Content-Type: text/plain; charset=ISO-8859-2; format=flowed<BR><BR>Jan,<BR><BR>if any uri (according to RFC) is allowed in URI, then ser should not <BR>issue an error message on lookup("location"):<BR><BR>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>parsed: <HTTP>(4) / <HTTP: 192.168.0.206:80>(23)<BR>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>http://192.168.0.206:80<BR>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>parsed: <HTTP>(4) / <HTTPS: 192.168.0.206:443>(25)<BR>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>https://192.168.0.206:443<BR><BR>Especially not a "bad_uri" error message, because it is not a bad uri <BR>indeed. Some
debug-warning about ignoring this or that contact because <BR>it was not SIP/SIPS will do. What do you think?<BR><BR>Either way, I think there is need for some cleanup.<BR><BR>Regards,<BR>Martin<BR><BR>Jan Janak schrieb:<BR><BR>>On 02-03 10:32, Marian Dumitru wrote:<BR>> <BR>><BR>>>Hi Martin,<BR>>><BR>>>As far as I know it could be one of the new SNOM specific feature - it <BR>>>advertise the http location of the web configuration page. But if recall <BR>>>correctly, the header name should by WWW-Contact, not Contact.<BR>>><BR>>>Anyhow, it will be a good idea for register to check the contact <BR>>>validity before inserting into usrloc.<BR>>> <BR>>><BR>><BR>> That's one interesting question. What is a valid contact ? A regular<BR>> proxy would not be able to contact URI with http scheme, that's clear.<BR>> But that does not mean yet that the contact is not valid, because<BR>> RFC3261 allows any sort
of URI to appear there.<BR>><BR>> On the other hand, a redirect server would just take this URI, put it<BR>> into a 3xx response and send it back the the calling UA. If the calling<BR>> UA is unable to reach the called party, it might display the contents<BR>> of the HTTP URL or do some other magic.<BR>><BR>> For that reason I think that there should be no limitation of what<BR>> gets into the user location database.<BR>><BR>> Jan.<BR>><BR>>_______________________________________________<BR>>Serusers mailing list<BR>>serusers@lists.iptel.org<BR>>http://lists.iptel.org/mailman/listinfo/serusers<BR>> <BR>><BR><BR><BR><BR>------------------------------<BR><BR>Message: 4<BR>Date: Wed, 2 Mar 2005 07:16:59 -0500<BR>From: Java Rockx <JAVAROCKX@GMAIL.COM><BR>Subject: Re: [Serusers] RTP Wiretapping<BR>To: ser@cannes.f9.co.uk<BR>Cc: serusers@lists.iptel.org<BR>Message-ID: <359a65820503020416142a33c@mail.gmail.com><BR>Content-Type: text/plain;
charset=US-ASCII<BR><BR>I was thinking about having a group called "spy" in the grp table and<BR>anyone with this ACL would be sent to a modified mediaproxy that would<BR>capture the RTP.<BR><BR>User that don't have the "spy" ACL would be handled normally and if<BR>NAT traversal is needed then use an unmodified media proxy.<BR><BR>Regards,<BR>Paul<BR><BR><BR>On Wed, 2 Mar 2005 08:00:24 -0000, Chris <SER@CANNES.F9.CO.UK>wrote:<BR>> Why not use a from/to etc detection in .cfg (using database...)<BR>> to trigger a remote proxy through the requesting agency<BR>> They then have the capture issue<BR>> and you have no monitor or delivery issues?<BR>> Might require conditions of their placement of a proxy?<BR>> (but is their problem)<BR>> Regards<BR>> Chris<BR>> <BR>> -----Original Message-----<BR>> From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On<BR>> Behalf Of Java Rockx<BR>> Sent: 26 February 2005 14:29<BR>> To:
serusers@lists.iptel.org<BR>> Subject: [Serusers] RTP Wiretapping<BR>> <BR>> Hi All.<BR>> <BR>> I'm located in the US and would like to comply with the Communications<BR>> Assistance for Law Enforcement Act (CALEA) that Congress passed which<BR>> basically says that VoIP providers should have the ability to wiretap<BR>> conversations for the FBI upon request.<BR>> <BR>> I use mediaproxy for NAT traversal. So my question is how can I be<BR>> CALEA compliant? I assume I should be able to modify mediaproxy to<BR>> write RTP streams to disk, but I'm unclear on how to "mix" both sides<BR>> of the conversation.<BR>> <BR>> Can anyone help with a suggestion?<BR>> <BR>> Regards,<BR>> Paul<BR>> <BR>> _______________________________________________<BR>> Serusers mailing list<BR>> serusers@lists.iptel.org<BR>> http://lists.iptel.org/mailman/listinfo/serusers<BR>> <BR>> --<BR>> No virus found in this incoming message.<BR>>
Checked by AVG Anti-Virus.<BR>> Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 25/02/2005<BR>> <BR>> --<BR>> No virus found in this outgoing message.<BR>> Checked by AVG Anti-Virus.<BR>> Version: 7.0.300 / Virus Database: 266.5.2 - Release Date: 28/02/2005<BR>> <BR>><BR><BR><BR><BR>------------------------------<BR><BR>Message: 5<BR>Date: Wed, 2 Mar 2005 13:42:03 +0100<BR>From: Jan Janak <JAN@IPTEL.ORG><BR>Subject: Re: [Serusers] http / https in Userloc db<BR>To: Martin Koenig <MARTIN.KOENIG@TOPLINK-PLANNET.DE><BR>Cc: serusers@lists.iptel.org<BR>Message-ID: <20050302124203.GG3487@localhost.localdomain><BR>Content-Type: text/plain; charset=iso-8859-2<BR><BR>The error message is not issued by lookup("location"), it is issued by<BR>t_relay() when you try to forward the message to the HTTP URI.<BR><BR>It should be easy to write a function that would be called before<BR>t_relay (or after lookup) and that would filter out URI schemes<BR>unsupported by
SER.<BR><BR>For the Request-URI you can do that from the script:<BR><BR>if (uri =~ "^http") {<BR>do something<BR>};<BR><BR>But that would not check additional branches used for parallel forking.<BR><BR>Jan.<BR><BR>On 02-03 13:08, Martin Koenig wrote:<BR>> Jan,<BR>> <BR>> if any uri (according to RFC) is allowed in URI, then ser should not <BR>> issue an error message on lookup("location"):<BR>> <BR>> Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>> parsed: <HTTP>(4) / <HTTP: 192.168.0.206:80>(23)<BR>> Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>> http://192.168.0.206:80<BR>> Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>> parsed: <HTTP>(4) / <HTTPS: 192.168.0.206:443>(25)<BR>> Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>> https://192.168.0.206:443<BR>> <BR>> Especially not a "bad_uri" error message, because it is not a bad uri <BR>> indeed. Some
debug-warning about ignoring this or that contact because <BR>> it was not SIP/SIPS will do. What do you think?<BR>> <BR>> Either way, I think there is need for some cleanup.<BR>> <BR>> Regards,<BR>> Martin<BR>> <BR>> Jan Janak schrieb:<BR>> <BR>> >On 02-03 10:32, Marian Dumitru wrote:<BR>> > <BR>> ><BR>> >>Hi Martin,<BR>> >><BR>> >>As far as I know it could be one of the new SNOM specific feature - it <BR>> >>advertise the http location of the web configuration page. But if recall <BR>> >>correctly, the header name should by WWW-Contact, not Contact.<BR>> >><BR>> >>Anyhow, it will be a good idea for register to check the contact <BR>> >>validity before inserting into usrloc.<BR>> >> <BR>> >><BR>> ><BR>> > That's one interesting question. What is a valid contact ? A regular<BR>> > proxy would not be able to contact URI with http
scheme, that's clear.<BR>> > But that does not mean yet that the contact is not valid, because<BR>> > RFC3261 allows any sort of URI to appear there.<BR>> ><BR>> > On the other hand, a redirect server would just take this URI, put it<BR>> > into a 3xx response and send it back the the calling UA. If the calling<BR>> > UA is unable to reach the called party, it might display the contents<BR>> > of the HTTP URL or do some other magic.<BR>> ><BR>> > For that reason I think that there should be no limitation of what<BR>> > gets into the user location database.<BR>> ><BR>> > Jan.<BR>> ><BR>> >_______________________________________________<BR>> >Serusers mailing list<BR>> >serusers@lists.iptel.org<BR>> >http://lists.iptel.org/mailman/listinfo/serusers<BR>> > <BR>> ><BR>> <BR><BR><BR><BR>------------------------------<BR><BR>Message: 6<BR>Date: Wed, 02 Mar 2005 14:04:12
+0100<BR>From: Marian Dumitru <MARIAN.DUMITRU@VOICE-SISTEM.RO><BR>Subject: Re: [Serusers] http / https in Userloc db<BR>To: Jan Janak <JAN@IPTEL.ORG><BR>Cc: serusers@lists.iptel.org, Martin Koenig<BR><MARTIN.KOENIG@TOPLINK-PLANNET.DE><BR>Message-ID: <4225B9CC.304@voice-sistem.ro><BR>Content-Type: text/plain; charset=ISO-8859-2; format=flowed<BR><BR>Hi Jan,<BR><BR>So some URI checking is required and indeed, if you want to allow <BR>clients to perform that magic you mentioned, the checking should be done <BR>after extracting the URIs from usrloc.<BR>But should be very clear if a contact URI can or cannot be involved in <BR>SIP signaling - used for forwarding. One note here - it's interesting <BR>what will be the impact on nathelper when it will start doing NAT ping <BR>to non-SIP URIs :-).<BR>Anyhow, the best place to do the checking is before t_relay(). If you do <BR>th filtering immediately after lookup(), you will loose the Redirect <BR>Server functionality.<BR><BR>Best
regards,<BR>Marian<BR><BR><BR>Jan Janak wrote:<BR>> The error message is not issued by lookup("location"), it is issued by<BR>> t_relay() when you try to forward the message to the HTTP URI.<BR>> <BR>> It should be easy to write a function that would be called before<BR>> t_relay (or after lookup) and that would filter out URI schemes<BR>> unsupported by SER.<BR>> <BR>> For the Request-URI you can do that from the script:<BR>> <BR>> if (uri =~ "^http") {<BR>> do something<BR>> };<BR>> <BR>> But that would not check additional branches used for parallel forking.<BR>> <BR>> Jan.<BR>> <BR>> On 02-03 13:08, Martin Koenig wrote:<BR>> <BR>>>Jan,<BR>>><BR>>>if any uri (according to RFC) is allowed in URI, then ser should not <BR>>>issue an error message on lookup("location"):<BR>>><BR>>>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>>>parsed: <HTTP>(4) / <HTTP:
192.168.0.206:80>(23)<BR>>>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>>>http://192.168.0.206:80<BR>>>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: parse_uri: bad uri, state 0 <BR>>>parsed: <HTTP>(4) / <HTTPS: 192.168.0.206:443>(25)<BR>>>Mar 2 12:58:17 s-p1 ser[1711]: ERROR: uri2proxy: bad_uri: <BR>>>https://192.168.0.206:443<BR>>><BR>>>Especially not a "bad_uri" error message, because it is not a bad uri <BR>>>indeed. Some debug-warning about ignoring this or that contact because <BR>>>it was not SIP/SIPS will do. What do you think?<BR>>><BR>>>Either way, I think there is need for some cleanup.<BR>>><BR>>>Regards,<BR>>>Martin<BR>>><BR>>>Jan Janak schrieb:<BR>>><BR>>><BR>>>>On 02-03 10:32, Marian Dumitru wrote:<BR>>>><BR>>>><BR>>>><BR>>>>>Hi Martin,<BR>>>>><BR>>>>>As far as I know it could
be one of the new SNOM specific feature - it <BR><BR>=== message truncated ===</BLOCKQUOTE><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam? Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com