September 2007 - sr-users

Re: [OpenSER-Users] Missing RTP stream
by Morten Isaksen 20 Sep '07

20 Sep '07

Hi! I can see in the mediaproxy log the it is initialized to proxy the call, but I newer get a "session xxxxx: called signed in from xxx" from Asterisk. session.py shows that the the connection between mediaproxy and Asterisk is missing. I will try to take a look at the sip debug from asterisk and try to change the NAT settings in Asterisk. Thanks for your input. On 9/20/07, Norman Brandinger <norm(a)goes.com> wrote: > You stated that you've forced every call through mediaproxy. Are you > positive ? > > Have you taken a look at the mediaproxy logs (and/or sessions.py when > the call is up) ? They might provide some useful information to you. > > Ditto for Asterisk "sip set debug on" (note that the sip debug command > format is a moving target). > > Have you looked at the "nat=" settings in sip.conf as well ? At times, > they tie closely with "canreinvite=". > > Norm > > > Morten Isaksen wrote: > > Hi! > > > > canreinvite is set to no and the OpenSER/mediaproxy is "hiding" the > > clients IP-addresses from Asterisk, so I am pretty sure that this is > > not the issue. > > > > On 9/20/07, Norman Brandinger <norm(a)goes.com> wrote: > > > >> Hi Morten, > >> > >> Admittedly, I haven't looked closely at your trace. However, based on > >> the description you gave, the first place to look is at the "canrevite" > >> setting in Asterisk sip.conf. You might want to try "canreinvite=no" > >> after reading up on this particular setting. > >> > >> Regards, > >> Norm > >> > >> > >> Morten Isaksen wrote: > >> > >>> Hi! > >>> > >>> I have a strange problem with a missing RTP stream between OpenSER and > >>> Asterisk. I am not sure if it is OpenSER og Asterisk related. > >>> > >>> I have this setup > >>> > >>> Phone A (172.17.96.17) -- > >>> \ Openser -- Asterisk > >>> -- PSTN > >>> / (192.168.0.6) (192.168.0.3) > >>> Phone B (172.17.96.10) -- (172.17.64.1) > >>> > >>> I also have a Mediaproxy running on OpenSER and I force every call to > >>> use the Mediaproxy. > >>> > >>> I call from Phone A or B to the PSTN works fine and from PSTN to Phone > >>> A or B it also works. > >>> > >>> I have the dialplan logic on my Asterisk server so I want calls from > >>> Phone A to Phone B to pass the Asterisk server. And this is were I > >>> have the problem. When the call is established the RTP stream is > >>> missing between Mediaproxy and Asterisk. I only have a RTP stream > >>> between the phones and Mediaproxy. As far as I can see the SIP > >>> signalling is correct. > >>> > >>> The SIP traces is listed below. Can you spot the problem in this? > >>> > >>> I will buy a beer (or 5) at OpenSER training in Rome to anyone who can > >>> help me solve this problem. > >>> > >>> SIP trace between the phones and OpenSER: > >>> > >>> > > > > > > > > -- Morten Isaksen http://www.misak.dk/blog/

1 0

[OpenSER-Users] Missing RTP stream
by Morten Isaksen 20 Sep '07

20 Sep '07

Hi! I have a strange problem with a missing RTP stream between OpenSER and Asterisk. I am not sure if it is OpenSER og Asterisk related. I have this setup Phone A (172.17.96.17) -- \ Openser -- Asterisk -- PSTN / (192.168.0.6) (192.168.0.3) Phone B (172.17.96.10) -- (172.17.64.1) I also have a Mediaproxy running on OpenSER and I force every call to use the Mediaproxy. I call from Phone A or B to the PSTN works fine and from PSTN to Phone A or B it also works. I have the dialplan logic on my Asterisk server so I want calls from Phone A to Phone B to pass the Asterisk server. And this is were I have the problem. When the call is established the RTP stream is missing between Mediaproxy and Asterisk. I only have a RTP stream between the phones and Mediaproxy. As far as I can see the SIP signalling is correct. The SIP traces is listed below. Can you spot the problem in this? I will buy a beer (or 5) at OpenSER training in Rome to anyone who can help me solve this problem. SIP trace between the phones and OpenSER: U 172.17.96.17:5060 -> 172.17.64.1:5060 INVITE sip:43336000@172.17.64.1:5060;transport=UDP SIP/2.0. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 1 INVITE. Via: SIP/2.0/UDP 172.17.96.17:5060;rport;branch=z9hG4bK-3e125d63-77bccac7-4b008a75. Max-Forwards: 70. Supported: replaces,100rel. Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 366. . v=0. o=081701 1041391881 1041391881 IN IP4 172.17.96.17. s=-. c=IN IP4 172.17.96.17. t=0 0. m=audio 10000 RTP/AVP 8 8 18 4 98 2 101. a=rtpmap:8 PCMA/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=rtpmap:4 g723/8000. a=rtpmap:98 g726-16/8000. a=rtpmap:2 g726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:18 annexb=no. a=fmtp:4 annexa=no. a=fmtp:101 0-15. # U 172.17.64.1:5060 -> 172.17.96.17:5060 SIP/2.0 407 Proxy Authentication Required. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=e7a9ec63e83496804ae077e38a2ef69c.8352. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 1 INVITE. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccac7-4b008a75. Proxy-Authenticate: Digest realm="172.17.96.17", nonce="46f2861ed3a501550cd33c28b12936d24c42199c". Server: OpenSer (1.1.0-notls (i386/linux)). Content-Length: 0. Warning: 392 172.17.64.1:5060 "Noisy feedback tells: pid=15649 req_src_ip=172.17.96.17 req_src_port=5060 in_uri=sip:43336000@172.17.64.1:5060;transport=UDP out_uri=sip:43336000@172.17.64.1:5060;transport=UDP via_cnt==1". . # U 172.17.96.17:5060 -> 172.17.64.1:5060 ACK sip:43336000@172.17.64.1:5060;transport=UDP SIP/2.0. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=e7a9ec63e83496804ae077e38a2ef69c.8352. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 1 ACK. Via: SIP/2.0/UDP 172.17.96.17:5060;rport;branch=z9hG4bK-3e125d63-77bccac7-4b008a75. Max-Forwards: 70. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Content-Length: 0. . # U 172.17.96.17:5060 -> 172.17.64.1:5060 INVITE sip:43336000@172.17.64.1:5060;transport=UDP SIP/2.0. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. Via: SIP/2.0/UDP 172.17.96.17:5060;rport;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. Max-Forwards: 70. Supported: replaces,100rel. Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Proxy-Authorization: Digest username="081701",realm="172.17.96.17",nonce="46f2861ed3a501550cd33c28b12936d24c42199c",uri="sip:43336000@172.17.64.1:5060;transport=UDP",response="4bf0194044fb4a759ec6134d68bef752",algorithm=MD5. Content-Type: application/sdp. Content-Length: 366. . v=0. o=081701 1041391881 1041391881 IN IP4 172.17.96.17. s=-. c=IN IP4 172.17.96.17. t=0 0. m=audio 10000 RTP/AVP 8 8 18 4 98 2 101. a=rtpmap:8 PCMA/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=rtpmap:4 g723/8000. a=rtpmap:98 g726-16/8000. a=rtpmap:2 g726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:18 annexb=no. a=fmtp:4 annexa=no. a=fmtp:101 0-15. # U 172.17.64.1:5060 -> 172.17.96.17:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3:5060>. Content-Length: 0. . # U 172.17.64.1:5060 -> 172.17.96.10:5060 INVITE sip:081700@172.17.96.10:5060;transport=UDP SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=as28ccd5e9>. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bKcf8.161cb842.1. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>. Contact: <sip:43336999@192.168.0.3:1265>. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 69. Date: Thu, 20 Sep 2007 14:34:26 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Content-Type: application/sdp. Content-Length: 182. . v=0. o=root 21472 21472 IN IP4 192.168.0.3. s=session. c=IN IP4 172.17.64.1. t=0 0. m=audio 60024 RTP/AVP 8 0. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=silenceSupp:off - - - -. # U 172.17.64.1:5060 -> 172.17.96.17:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3:5060>. Content-Length: 0. . # U 172.17.96.10:5060 -> 172.17.64.1:5060 SIP/2.0 180 Ringing. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bKcf8.161cb842.1,SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: 081701 <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Supported: 100rel,replaces,timer. Content-Length: 0. . # U 172.17.96.10:5060 -> 172.17.64.1:5060 SIP/2.0 200 OK. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bKcf8.161cb842.1,SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: 081701 <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Supported: 100rel,replaces,timer. Record-Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. Contact: <sip:081700@172.17.96.10:5060;transport=UDP>. Content-Length: 171. Content-Type: application/sdp. . v=0. o=- 926679040 1 IN IP4 172.17.96.10. s=ATI-SIP Call. c=IN IP4 172.17.96.10. t=0 0. m=audio 50600 RTP/AVP 8 13. a=rtpmap:8 PCMA/8000. a=ptime:10. a=rtpmap:13 CN/8000. # U 172.17.64.1:5060 -> 172.17.96.12:5060 CANCEL sip:081700@172.17.96.12:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bKcf8.161cb842.0. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. To: <sip:081700@172.17.64.1>. CSeq: 102 CANCEL. User-Agent: OpenSer (1.1.0-notls (i386/linux)). Content-Length: 0. . # U 172.17.64.1:5060 -> 172.17.96.10:5060 ACK sip:081700@172.17.96.10:5060;transport=UDP SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=as28ccd5e9>. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bKcf8.161cb842.3. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK78618ac6;rport=1265. Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Contact: <sip:43336999@192.168.0.3>. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 69. Content-Length: 0. . # U 172.17.64.1:5060 -> 172.17.96.17:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. Record-Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3:5060>. Content-Type: application/sdp. Content-Length: 238. . v=0. o=root 21472 21472 IN IP4 192.168.0.3. s=session. c=IN IP4 172.17.64.1. t=0 0. m=audio 60022 RTP/AVP 8 0 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. # U 172.17.96.17:5060 -> 172.17.64.1:5060 ACK sip:43336000@192.168.0.3:5060 SIP/2.0. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 ACK. Via: SIP/2.0/UDP 172.17.96.17:5060;rport;branch=z9hG4bK-3e125d66-77bcd96f-26ad0a63. Max-Forwards: 70. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Route: <sip:172.17.64.1;lr;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. Proxy-Authorization: Digest username="081701",realm="172.17.96.17",nonce="46f2861ed3a501550cd33c28b12936d24c42199c",uri="sip:43336000@172.17.64.1:5060;transport=UDP",response="4bf0194044fb4a759ec6134d68bef752",algorithm=MD5. Content-Length: 0. . # U 172.17.96.10:5060 -> 172.17.64.1:5060 BYE sip:43336999@192.168.0.3:1265 SIP/2.0. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. Max-Forwards: 70. Supported: 100rel,replaces,timer. Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. Content-Length: 0. . # U 172.17.64.1:5060 -> 172.17.96.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336999@192.168.0.3:5060>. Content-Length: 0. X-Asterisk-HangupCause: Normal Clearing. . # U 172.17.64.1:5060 -> 172.17.96.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336999@192.168.0.3:1265>. Content-Length: 0. X-Asterisk-HangupCause: Normal Clearing. . # U 172.17.64.1:5060 -> 172.17.96.17:5060 BYE sip:081701@172.17.96.17:5060 SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=as119e7abe>. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bK4aff.f48c6cd7.0. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK0716a581;rport=5060. Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. To: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. Contact: <sip:43336000@192.168.0.3>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 102 BYE. User-Agent: Asterisk PBX. Max-Forwards: 69. Content-Length: 0. . # U 172.17.96.17:5060 -> 172.17.64.1:5060 SIP/2.0 200 OK. From: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. To: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 102 BYE. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bK4aff.f48c6cd7.0. Via: SIP/2.0/UDP 192.168.0.3:5060;rport=5060;branch=z9hG4bK0716a581. Supported: replaces,100rel. Content-Length: 0. . And the SIP trace between OpenSER and Asterisk: # U 192.168.0.6:5060 -> 192.168.0.3:5060 INVITE sip:43336000@172.17.64.1:5060;transport=UDP SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. Via: SIP/2.0/UDP 172.17.64.1;branch=0. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. Max-Forwards: 69. Supported: replaces,100rel. Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Proxy-Authorization: Digest username="081701",realm="172.17.96.17",nonce="46f2861ed3a501550cd33c28b12936d24c42199c",uri="sip:43336000@172.17.64.1:5060;transport=UDP",response="4bf0194044fb4a759ec6134d68bef752",algorithm=MD5. Content-Type: application/sdp. Content-Length: 365. . v=0. o=081701 1041391881 1041391881 IN IP4 172.17.96.17. s=-. c=IN IP4 172.17.64.1. t=0 0. m=audio 60022 RTP/AVP 8 8 18 4 98 2 101. a=rtpmap:8 PCMA/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=rtpmap:4 g723/8000. a=rtpmap:98 g726-16/8000. a=rtpmap:2 g726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:18 annexb=no. a=fmtp:4 annexa=no. a=fmtp:101 0-15. # U 192.168.0.3:5060 -> 192.168.0.6:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 172.17.64.1;branch=0;received=192.168.0.6. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3>. Content-Length: 0. . # U 192.168.0.3:5060 -> 172.17.64.1:5060 INVITE sip:081700@172.17.64.1 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>. Contact: <sip:43336999@192.168.0.3>. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 70. Date: Thu, 20 Sep 2007 14:34:26 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Content-Type: application/sdp. Content-Length: 182. . v=0. o=root 21472 21472 IN IP4 192.168.0.3. s=session. c=IN IP4 192.168.0.3. t=0 0. m=audio 10810 RTP/AVP 8 0. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=silenceSupp:off - - - -. # U 172.17.64.1:5060 -> 192.168.0.3:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Server: OpenSer (1.1.0-notls (i386/linux)). Content-Length: 0. Warning: 392 172.17.64.1:5060 "Noisy feedback tells: pid=15647 req_src_ip=192.168.0.3 req_src_port=1265 in_uri=sip:081700@172.17.64.1 out_uri=sip:081700@172.17.96.12:5060;transport=UDP via_cnt==1". . # U 192.168.0.3:5060 -> 192.168.0.6:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 172.17.64.1;branch=0;received=192.168.0.6. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3>. Content-Length: 0. . # U 172.17.64.1:5060 -> 192.168.0.3:5060 SIP/2.0 180 Ringing. User-Agent: ATI-RG613TX/2-3_59. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: 081701 <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAAGNwAN2gAZewxx. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Supported: 100rel,replaces,timer. Content-Length: 0. . # U 172.17.64.1:5060 -> 192.168.0.3:5060 SIP/2.0 180 Ringing. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: 081701 <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Supported: 100rel,replaces,timer. Content-Length: 0. . # U 172.17.64.1:5060 -> 192.168.0.3:5060 SIP/2.0 200 OK. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK6ab42128;rport=1265. From: 081701 <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 INVITE. Supported: 100rel,replaces,timer. Record-Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. Contact: <sip:081700@172.17.96.10:5060;transport=UDP>. Content-Length: 170. Content-Type: application/sdp. . v=0. o=- 926679040 1 IN IP4 172.17.96.10. s=ATI-SIP Call. c=IN IP4 172.17.64.1. t=0 0. m=audio 60024 RTP/AVP 8 13. a=rtpmap:8 PCMA/8000. a=ptime:10. a=rtpmap:13 CN/8000. # U 192.168.0.3:5060 -> 172.17.64.1:5060 ACK sip:081700@172.17.96.10:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK78618ac6;rport. Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. From: "081701" <sip:43336999@192.168.0.3>;tag=as28ccd5e9. To: <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. Contact: <sip:43336999@192.168.0.3>. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . # U 192.168.0.3:5060 -> 192.168.0.6:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.64.1;branch=0;received=192.168.0.6. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d63-77bccb03-1bf1c302. Record-Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336000@192.168.0.3>. Content-Type: application/sdp. Content-Length: 238. . v=0. o=root 21472 21472 IN IP4 192.168.0.3. s=session. c=IN IP4 192.168.0.3. t=0 0. m=audio 12684 RTP/AVP 8 0 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. # U 192.168.0.6:5060 -> 192.168.0.3:5060 ACK sip:43336000@192.168.0.3:5060 SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. To: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 2 ACK. Via: SIP/2.0/UDP 172.17.64.1;branch=0. Via: SIP/2.0/UDP 172.17.96.17:5060;rport=5060;branch=z9hG4bK-3e125d66-77bcd96f-26ad0a63. Max-Forwards: 69. Contact: <sip:081701@172.17.96.17:5060;transport=UDP>. Route: <sip:172.17.64.1;lr;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. Proxy-Authorization: Digest username="081701",realm="172.17.96.17",nonce="46f2861ed3a501550cd33c28b12936d24c42199c",uri="sip:43336000@172.17.64.1:5060;transport=UDP",response="4bf0194044fb4a759ec6134d68bef752",algorithm=MD5. Content-Length: 0. . # U 192.168.0.6:5060 -> 192.168.0.3:5060 BYE sip:43336999@192.168.0.3:1265 SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 172.17.64.1;branch=0. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. Max-Forwards: 69. Supported: 100rel,replaces,timer. Route: <sip:172.17.64.1;lr;ftag=as28ccd5e9>. Content-Length: 0. . # U 172.17.64.1:5060 -> 192.168.0.3:5060 BYE sip:43336999@192.168.0.3:1265 SIP/2.0. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. User-Agent: ATI-iMG616RF+/3-5_78. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bK26ae.adc1e03.0. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. Max-Forwards: 69. Supported: 100rel,replaces,timer. Content-Length: 0. P-hint: rr-enforced. . # U 192.168.0.3:5060 -> 192.168.0.6:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.64.1;branch=0;received=192.168.0.6. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336999@192.168.0.3>. Content-Length: 0. X-Asterisk-HangupCause: Normal Clearing. . # U 192.168.0.3:5060 -> 172.17.64.1:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.17.64.1;branch=z9hG4bK26ae.adc1e03.0;received=172.17.64.1. Via: SIP/2.0/UDP 172.17.96.10:5060;branch=z9hG4bKAABFNwxx. Record-Route: <sip:172.17.64.1;lr=on;ftag=AAA5NwAN2ggCmwxx>. From: 081700 <sip:081700@172.17.64.1>;tag=AAA5NwAN2ggCmwxx. To: <sip:43336999@192.168.0.3>;tag=as28ccd5e9. Call-ID: 473e63475049c3e6481c39555040cf75(a)192.168.0.3. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Max-Forwards: 70. Contact: <sip:43336999@192.168.0.3>. Content-Length: 0. X-Asterisk-HangupCause: Normal Clearing. . # U 192.168.0.3:5060 -> 192.168.0.6:5060 BYE sip:081701@172.17.96.17:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK0716a581;rport. Route: <sip:172.17.64.1;lr=on;ftag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63>. From: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. To: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. Contact: <sip:43336000@192.168.0.3>. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 102 BYE. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . # U 192.168.0.6:5060 -> 192.168.0.3:5060 SIP/2.0 200 OK. From: "43336000"<sip:43336000@172.17.64.1:5060>;tag=as119e7abe. To: "081701"<sip:081701@172.17.96.17>;tag=100c3d98-116011ac-13c4-3e125d63-6075d01c-3e125d63. Call-ID: 100c7470-116011ac-13c4-3e125d63-539dcd67-3e125d63(a)172.17.96.17. CSeq: 102 BYE. Via: SIP/2.0/UDP 192.168.0.3:5060;rport=5060;branch=z9hG4bK0716a581. Supported: replaces,100rel. Content-Length: 0. . -- Morten Isaksen http://www.misak.dk/blog/

2 2

[OpenSER-Users] Forward REGISTER to Asterisk
by Halomoan Chow 20 Sep '07

20 Sep '07

Dear All I want user who register with my openser also register with my asterisk for later lookup. I tried t_replicate function from TM module but no luck. I end up with Unauthorized message. Could any help me how to make this work? What do I miss ? Thank so much Regards, Halomoan Zhou

4 4

Re: [OpenSER-Users] test operator]
by Klaus Darilion 20 Sep '07

20 Sep '07

Bogdan-Andrei Iancu schrieb: > Hi Klaus, > > the [..] operator is used to convert generic numerical value (maybe > result of arithmetic ops to logical value. > > in your example, the == is already a logical operator, so no need to any > conversion. Does ($rd == "mydomain") works too? is this somewhere documented? The corebook only describes assignments, but not conditions/comparisons. regards klaus

2 1

[OpenSER-Users] tcp receiver with tcp socket?
by Klaus Darilion 20 Sep '07

20 Sep '07

Hi! I have configured openser 1.2 to only listen to udp: Starting Open SIP Router: Listening on udp: 1.2.3.4 [1.2.3.4]:5060 Aliases: *: mydomain.at:* $ openser-1.2-SVN/scripts/openserctl ps Process:: ID=0 PID=29582 Type=attendant Process:: ID=1 PID=29583 Type=receiver child=0 sock= 1.2.3.4:5060 Process:: ID=2 PID=29585 Type=receiver child=1 sock= 1.2.3.4:5060 Process:: ID=3 PID=29586 Type=receiver child=2 sock= 1.2.3.4:5060 Process:: ID=4 PID=29587 Type=receiver child=3 sock= 1.2.3.4:5060 Process:: ID=5 PID=29588 Type=receiver child=4 sock= 1.2.3.4:5060 Process:: ID=6 PID=29589 Type=receiver child=5 sock= 1.2.3.4:5060 Process:: ID=7 PID=29590 Type=receiver child=6 sock= 1.2.3.4:5060 Process:: ID=8 PID=29591 Type=receiver child=7 sock= 1.2.3.4:5060 Process:: ID=9 PID=29592 Type=timer Process:: ID=10 PID=29593 Type=tcp receiver Process:: ID=11 PID=29594 Type=tcp receiver Process:: ID=12 PID=29595 Type=tcp receiver Process:: ID=13 PID=29596 Type=tcp receiver Process:: ID=14 PID=29597 Type=tcp receiver Process:: ID=15 PID=29598 Type=tcp receiver Process:: ID=16 PID=29599 Type=tcp receiver Process:: ID=17 PID=29600 Type=tcp receiver Process:: ID=18 PID=29601 Type=tcp main process So, where does all the "tcp receiver" come from? If they are DB related maybe we should change the "Type". This proxy uses mysql for presence - this I guess all the TCP connections are for presence. But why do I have 19 mysql connections? $ netstat -anp|grep openser tcp 0 0 1.2.3.4:48896 1.2.3.68:3306 ESTABLISHED 29598/openser tcp 0 0 1.2.3.4:48897 1.2.3.68:3306 ESTABLISHED 29599/openser tcp 0 0 1.2.3.4:48898 1.2.3.68:3306 ESTABLISHED 29600/openser tcp 0 0 1.2.3.4:48899 1.2.3.68:3306 ESTABLISHED 29601/openser tcp 0 0 1.2.3.4:48900 1.2.3.68:3306 ESTABLISHED 29582/openser tcp 0 0 1.2.3.4:48889 1.2.3.68:3306 ESTABLISHED 29591/openser tcp 0 0 1.2.3.4:48888 1.2.3.68:3306 ESTABLISHED 29590/openser tcp 0 0 1.2.3.4:48891 1.2.3.68:3306 ESTABLISHED 29593/openser tcp 0 0 1.2.3.4:48890 1.2.3.68:3306 ESTABLISHED 29592/openser tcp 0 0 1.2.3.4:48893 1.2.3.68:3306 ESTABLISHED 29595/openser tcp 0 0 1.2.3.4:48892 1.2.3.68:3306 ESTABLISHED 29594/openser tcp 0 0 1.2.3.4:48895 1.2.3.68:3306 ESTABLISHED 29597/openser tcp 0 0 1.2.3.4:48894 1.2.3.68:3306 ESTABLISHED 29596/openser tcp 0 0 1.2.3.4:48883 1.2.3.68:3306 ESTABLISHED 29585/openser tcp 0 0 1.2.3.4:48882 1.2.3.68:3306 ESTABLISHED 29583/openser tcp 0 0 1.2.3.4:48885 1.2.3.68:3306 ESTABLISHED 29587/openser tcp 0 0 1.2.3.4:48884 1.2.3.68:3306 ESTABLISHED 29586/openser tcp 0 0 1.2.3.4:48887 1.2.3.68:3306 ESTABLISHED 29589/openser tcp 0 0 1.2.3.4:48886 1.2.3.68:3306 ESTABLISHED 29588/openser udp 0 0 1.2.3.4:5060 0.0.0.0:* 29582/openser Thus, why 19 DB connections for 8 UDP childrens? Why 8 tcp receivers in "openserctl ps"? thanks klaus

2 2

[OpenSER-Users] test operator
by Klaus Darilion 20 Sep '07

20 Sep '07

Hi! from the core cookbook of 1.2: > If you want to evaluate arithmetic operations and test the value in > conditions, use the test operator ' [ ... ] ' . This is required to > convert the result to internal convention for drop, true and false. > > if ( [ $var(a)&4 ] ) { > xlog("bit 3 is set in var a"); > } Is there somewhere a detailed description of the test operator? Can it only be used to test for 0/1 or can I also do comparison like e.g. if ([ $rd == "mydomain.at" ]) ? regards klaus

2 1

[OpenSER-Users] Unregister a user when not responding to SIP pings
by Iñaki Baz Castillo 20 Sep '07

20 Sep '07

Hi, many times a softphone or PC crashes without sending the un-REGISTER, so the user remains in location table. OpenSer allows sending SIP ping to users, is not possible to delete the location entry for a user who has left responding to those SIP pings? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

4 10

[Serusers] Ser web configuration
by Tuhin 20 Sep '07

20 Sep '07

Please help me to configure serweb by telling me the procedure.

1 0

[OpenSER-Users] Do we like the same books?
by rizwan_hisham 20 Sep '07

20 Sep '07

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=16332510&InvitationCode=3d… rizwan_hisham Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. -------- You have received this email because rizwan_hisham (rizwanhasham(a)gmail.com) directly invited you to join his/her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/emailoptout.aspx?email=Users@openser.org&ac…) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/rizwan_hisham) his/her Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104

1 0

[Serusers] Mediaproxy in public IP e two client behind same Nat
by pistara_bros＠tin.it 20 Sep '07

20 Sep '07

Hi, I want add others information about my test, providing also the log of MediaProxy WEB GUI. Windows Client used : X-Lite Version 3.0 build 29712 First scenarious : Client_A and Client_B running on Windows XP in the same LAN behind same NAT. Client_A call Client_B and During the conversation MediaProxy WEB GUI (http://smile.ing.uniroma1. it/serweb/mediaproxy/) show me following dump: Call | Caller |Called |Via address |status |Duration|.... ------------------------------|---------------- |---------------------------|-------------------| F:j2me@151. 100.122.144 | - | - |151.100.122.144:60012|inactive| 0'59'' |.... To:enzo@151.100.122.144| - | - | | | | And after 60 seconds the session expired and MediaProxy WEB GUI don't show it. Result: the RTP packet dont' pass through the Mediaproxy, but the packet go directly from one computer to another of my Lan. Second scenarious: Windows Client used : X-Lite Version 3.0 build 29712 Linux Client used : X-Lite Version 2.0 build 1105d Client_A runnning on WindowsXP and Client_B running on Linux Fedora in the same LAN behind same NAT. Client_A call Client_B and During the conversation MediaProxy WEB GUI (http://smile.ing.uniroma1.it/serweb/mediaproxy/) show me following dump: Call | Caller |Called --------------------------------|-------------------------- |--------------------------- F:j2me@151.100.122.144 | 85.39.206.210: 62969 |85.39.206.210:62947 To: enzo(a)151.100.122.144 | | |Via address |status |Duration|.... |151.100.122.144:60010 |active | 1'25'' |.... Result: the RTP packet pass through the Mediaproxy, that acts as "man in the middle" anf forward RTP packet versus clients of my Lan. Why MediaProxy, in windowz -> windowz client communications doesn't work????? Orazio >Hi to All, >I'm investigating again about Mediaproxy and SER , but in >this test i'm using the >the testbed of smile.ing.uniroma1.it whic use >SER and Mediaproxy in a public ip 151.100.122.144 >I'm using Client_A (X- >lite) running on WindowsXP 192.168.123.10 >and Client_B (X-lite) running >on WindowsXP 192.168.123.168 >My Lan use a router with a public ip >83.211.41.253 >So the clients are behind the same Nat. >Using ethereal i >see that during the conversation the RTP packet dont' pass through the >Mediaproxy in public ip (151.100.122.144) but the packet go directly >from one computer to another of my Lan. >So the question is : >what SER >architecture (with Mediaproxy or with SEMS or other..) i have to use in >order to >have a proxy RTP that work as man in the middle and manage all >RTP Traffic between the two clients? >Please help me. >thanks.

1 0

[OpenSER-Users] Free BSD 6.0 and SEAS problem.
by Kuddusi 20 Sep '07

20 Sep '07

Hi, I am using default seas configuration. When I tried to start openser seas module can not be loaded althoug module is compiled without problem. I tried 1.2.0 and 1.2.2 and the same problem occurred. It seems that it could not find "dprintf" function. How can I solve this problem? root@~: openser -ddddddddddd 0(43499) loading module /usr/local/lib/openser/modules/tm.so 0(43499) DEBUG: register_pv: tm 0(43499) xl_add_extra_spec: extra items list is not initialized 0(43499) xl_add_extra_spec: inserting extra item [T_branch_idx] at [0] 0(43499) xl_add_extra_spec: inserting extra item [T_reply_code] at [1] 0(43499) loading module /usr/local/lib/openser/modules/seas.so 0(43499) ERROR: load_module: could not open module </usr/local/lib/openser/modules/seas.so>: /usr/local/lib/openser/modules/seas.so: Undefined symbol "dprintf" and config is below Thanks, Kuddusi CIFTCIBASI. # ----------- global configuration parameters ------------------------ debug=9 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E) children=4 # Uncomment these lines to enter debugging mode fork=no log_stderror=yes # reply_to_via=1 listen = tcp:84.51.32.24:5060 listen = udp:84.51.32.24:5060 port=5060 # ------------------ module loading ---------------------------------- #set module path #mpath="/usr/local/lib/openser/modules/" loadmodule "/usr/local/lib/openser/modules/tm.so" loadmodule "/usr/local/lib/openser/modules/seas.so" modparam("seas", "listen_sockets","84.51.32.24:5080") modparam("seas", "stats_socket","84.51.32.24:5088") #modparam("rr", "enable_full_lr", 1) # ------------------------- request routing logic ------------------- # main routing logic route{ if(!as_relay_t("app_server_one")){ t_reply("500","No App Server"); } }

2 2

[OpenSER-Users] Do we like the same books?
by voipexpert 20 Sep '07

20 Sep '07

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=16229378&InvitationCode=84… voipexpert Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. -------- You have received this email because voipexpert (sunkara.raviprakash.feb14(a)gmail.com) directly invited you to join his/her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/emailoptout.aspx?email=Users@openser.org&ac…) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/voipexpert) his/her Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104

1 0

[Serusers] Creating a test scenario to test NATing..
by Piyush.Bansal＠relianceada.com 20 Sep '07

20 Sep '07

hi all, I wanna simulate a test scenario in which the sip clients are behind NAT (whether same or different NAT, in some private network), and the SER and MediaProxy are running on some public IP. My question is, in this case the client is not able to communicate with the server through the Firewall / NAT. My SIP messages are being dropped at the Firewall itself. Can anybody tell me, what could be the reason behind that????? I'm totally stuck at this point..... plz revert asap... thanx in advance.. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

1 0

[OpenSER-Users] openser + freeradius + cdrtool in freebsd
by Sam Wun 20 Sep '07

20 Sep '07

Hi, I found openser and freeradius in the freebsd ports tree, but the cdrtools is a tool for CD ISO in freebsd. Is this the right cdrtools for freesradius? In the CDRtools website, it said: http://download.dns-hosting.info/CDRTool/ "CDRTool provides mediation, accounting and tracing for Call Detail Records generated by OpenSER by using RADIUS protocol and OpenSER siptrace facility. " It seems that the CDrtools in freebsd ports tree is not the one for freeradius. Thanks W

1 0

Re: [OpenSER-Users] OpenSER with MySQL Cluster
by Christian Schlatter 19 Sep '07

19 Sep '07

Kerker Staffan wrote: > hi > ok, thanks for the update. i kind of dropped that > track as i had all those errors. > > with your experience, is that a better solution than > using the t_replicate? i'm only synchronizing two servers. Well, there is a trade-off between the complexity of a mysql cluster deployment and the possible inconsistencies introduced by t_replicate. With mysql cluster, you can always be sure that both of your proxies have the same, consistent view of the registration state. This comes at the prize of deploying and maintaining the db cluster. t_replicate is a lightweight replication mechanism that doesn't ensure registration state consistency. I like the simplicity of this approach. Personally, I prefer having a consistent registration state. I also think that the mysql guys have done a great job in making the cluster deployment and management as easy as possible. /Christian > > best regards, > /staffan > > >> -----Original Message----- >> From: Christian Schlatter [mailto:cs@unc.edu] >> Sent: den 19 september 2007 15:42 >> To: Kerker Staffan >> Cc: Juha Heinanen; users(a)openser.org >> Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster >> >> >> Kerker Staffan wrote: >>> hi >>> i'm curious about this one. we used to run a dual Openser >> installation >>> with MySQL cluster, but this proved to very unstable (on >> the cluster >>> side). >>> is this working fine now? >>> >>> for instance, if one of the mysql cluster nodes was >> disconnected, this >>> could lead to complete cluster shut down, and nodes didn't handle >>> reconnect very good. >>> >>> so, we actually switched to the register replication instead... >> We're running a mysql 5.0.22 cluster for our two redundant >> openser proxies. This setup works very stable for about a year now. >> >> In the beginning our cluster was shutting down itself quite >> regularly e.g. after a network failure. Since then we >> >> - are running the management nodes on hosts that are >> connected to the data nodes through different network paths >> (this is essential, a cluster node needs to be able to solve >> the splitbrain problem) >> >> - have added 'StopOnError = 0' to the data node settings >> (this causes a data nodes to try to reconnect after it lost >> communication to its neighbors, per default, a data node just >> shuts itself down) >> >> - added enough DataMemory and IndexMemory for the data nodes >> (DataMemory = 1024M, IndexMemory = 64M) >> >> >> Overall I'm quite pleased with our mysql cluster solution, >> although I'd >> prefer a solution where the UAs do register with both of our >> proxies, so >> that there is no need to replicate registration state between >> the proxies. >> >> Our mysql cluster basically only contains the 'location' >> table since we >> store all account data on redundant LDAP/H350 directories. >> >> >> /Christian >> >> >> >>> best regards >>> /Staffan >>> >>> >>>> -----Original Message----- >>>> From: users-bounces(a)openser.org >>>> [mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter >>>> Sent: den 18 september 2007 23:37 >>>> To: Juha Heinanen >>>> Cc: users(a)openser.org >>>> Subject: Re: [OpenSER-Users] OpenSER with MySQL Cluster >>>> >>>> >>>> Juha Heinanen wrote: >>>> ... >>>>> unfortunately you then cannot support presence. using >>>> another proxy >>>>> for presence is not a solution either, because same users >> need both >>>>> presence and other sip methods. >>>> What exactly prevents me from using a dedicated presence >>>> server? And why can't I support presence with db_mode=3? >>>> >>>> E.g. if I just want to deploy a simple PA using the PRESENCE >>>> module, I don't see any dependencies on USRLOC. >>>> >>>> I'm not sure if PUA_USRLOC depends on db_mode<3, but at least >>>> the documentation doesn't mention it. And it looks to me like >>>> I could use >>>> pua_set_publish() from PUA_USRLOC to send a PUBLISH to my >>>> dedicated presence server ;-) ... I haven't tried that though. >>>> >>>>> by the way, looks like presence related requests are by >> far the most >>>>> common ones if all sip UAs have presence turned on. it means that >>>>> presence would also create biggest db activity. >>>> Yes, I know, SIP presence is very chatty. >>>> >>>> >>>> /Christian >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)openser.org >>>> http://openser.org/cgi-bin/mailman/listinfo/users >>>> >>

1 0

[Serusers] Mediaproxy in public IP e two client behind same Nat
by pistara_bros＠tin.it 19 Sep '07

19 Sep '07

Hi to All, I'm investigating again about Mediaproxy and SER , but in this test i'm using the the testbed of smile.ing.uniroma1.it whic use SER and Mediaproxy in a public ip 151.100.122.144 I'm using Client_A (X- lite) running on WindowsXP 192.168.123.10 and Client_B (X-lite) running on WindowsXP 192.168.123.168 My Lan use a router with a public ip 83.211.41.253 So the clients are behind the same Nat. Using ethereal i see that during the conversation the RTP packet dont' pass through the Mediaproxy in public ip (151.100.122.144) but the packet go directly from one computer to another of my Lan. So the question is : what SER architecture (with Mediaproxy or with SEMS or other..) i have to use in order to have a proxy RTP that work as man in the middle and manage all RTP Traffic between the two clients? Please help me. thanks.

1 0

[OpenSER-Users] UAC module with Asterisk
by Halomoan Chow 19 Sep '07

19 Sep '07

Dear All Now I want to try UAC module to solve the proxy authentication to Asterisk. Until now it still fail even the username/password and realm are already correct 100% Then I found this statement "For sending authentication credentials to the termination provider openser has the "uac" module. But be aware that this module does not always works as it does not increase the cseq when sending the INVITE with credentials (search the archive for details). E.g. the uac module wont work if the termination providers uses Asterisk (as Asterisk checks the cseq)" Actually why UAC module has this limitation and why this does not get solved until now? Thanks Regards Halomoan Zhou

1 0

[Serusers] MeadiaProxy + SER + X-lite in the same Lan.
by pistara_bros＠tin.it 19 Sep '07

19 Sep '07

I want correct my previous posted sentences : "My guess is mediaproxy makes a test on the IPs (they are 192.168.147.2 and 192.168.147.3) and refuses to proxy the call." with "My guess is mediaproxy makes a test on the IPs (they are 192.168.123.168 and 192.168.123.10) and refuses to proxy the call." Does Anyone encounter this problem? could you share your opinion, with me?. Thanks. Orazio

1 0

[OpenSER-Users] memory allocation issue
by Benko 19 Sep '07

19 Sep '07

Hello! I wanted to upgrade a server from 1.1.0 to 1.2.2 today but despite extensive testing beforehand i have some trouble: After starting with the new openser-binary, it didn't allow any registrations and answered with "500 server error occured". Logging said: Sep 18 17:23:12 [/sbin/openser] ERROR: sip_msg_cloner: cannot allocate \ memory_ Sep 18 17:23:12 [/sbin/openser] ERROR: new_t: out of mem:_ Sep 18 17:23:12 [/sbin/openser] ERROR: t_newtran: new_t failed_Sep 18 and 17:23:12 [/sbin/openser] ERROR: sip_msg_cloner: cannot allocate memory_ Sep 18 17:23:12 [/sbin/openser] ERROR: store_reply: can't alloc' clone \ memory_ after restarting it with "-m 128"(according to the faq) these errors are gone, but it still doesn't accept registrations and prints: Sep 18 17:24:16 [/sbin/openser] ERROR:tm:print_uac_request: no shmem_ Sep 18 17:24:16 [/sbin/openser] ERROR:tm:t_forward_nonack: failure to \ add branches_ Sep 18 17:24:16 [/sbin/openser] ERROR:tm:w_t_relay: t_forward_nonack \ failed_ [update] - after several restarts, the first error-messages appeared again. When i run the new version on port 5061(old production server 1.1.0 is running parallel on port 5060) i can register with the new server(on port 5061) without problems. I have the vague impression that the new instance can't free memory, but why does it work when i run it on a different port? Any clues? Regards Christian

2 3

[OpenSER-Users] OpenSER with MySQL Cluster
by Vasile Zaharia 19 Sep '07

19 Sep '07

Hi *, Normally, OpenSER should work just fine with a MySQL Cluster, but I would like to know if anyone has tried this configuration yet. Are there any configuration settings I should be aware of? Thanks, Sica. ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

8 16

[OpenSER-Users] Configuration of Permissions module
by Sergio Gutierrez 19 Sep '07

19 Sep '07

Hi everybody. Does anybody has any example about how to configure the permissions module to use address validation from database configuration tables? In our setup, we observe an inconsistent behaviour when defining subnets; fifo command subnet_dump does not show the expected subnet. The only case wich works well is wehn mask is set to 32. Thanks in advance for your attention. Sergio Gutierrez EPM Telecomunicaciones Medellin - Colombia

1 0

[OpenSER-Users] example web_im send_im.html/php within openser 1.2.1 doensn't work
by CHEN XUEQIN 19 Sep '07

19 Sep '07

Hi all: I put example script file send_im.html/send_im.php in example/web_im direcotry into apache webroot. Then I launch firefox, fill in SIP Address and Message, click to send. But firefox don't response. The status bar indicated wait something. The fact is: 1. openser load mi_fifo.so correctly 2. the fifo file /tmp/openser_fifo, with the permission 0666, everyone can read and write 3. LOG message " DEBUG:mi_fifo:mi_fifo_server: entered consume", missing log "**** done consume" 4. SIP Address was user registered on openser. From Header was another user who registered on openser. 5. when I restart openser, replace fifo cmd with ":get_statistics:", send_im.php works Anyone know why? How to send message via fifo, pelease let me know Thanks in advance. Regards, Chen Xueqin

2 5

Re: [OpenSER-Users] OpenSER with MySQL Cluster
by Helge Waastad 19 Sep '07

19 Sep '07

Hi My experiences with MySQL clusters is that you have to expand the index memory etc as far as you dear to enable adding new tables/columns etc. I guess yopu would not like to do that in a production evnvironment anyway... br hw

1 0

[OpenSER-Users] user meeting (beer drinking in Vienna)
by Klaus Darilion 19 Sep '07

19 Sep '07

Hi! I proudly announce the first ser/openser/asterisk beer drinking evening in Vienna. When: Thursday (thirsty day) 20. September 2007, 19:00 CEST Where: Vienna, a bar in an inner district - exact location to be announced If you want to join please send a short reply so that I know for how many people I have to arrange a table. cu Klaus

6 6

[Serusers] help needed in configuring ENUM with ENUM module
by geethanjali.csg＠wipro.com 19 Sep '07

19 Sep '07

Hi, I am trying to configure ser to use enum module. But I am getting the following error. 0(6192) get_record: lookup(5.6.7.8.e164.arpa, 35) failed 0(6192) enum_query(): No NAPTR record found for 5.6.7.8.e164.arpa. Can someone kindly give me some pointers to fix this error. I am trying this from past few days. Thanks, Geethanjali C S Wipro Technologies The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users September 2007