sr-users February 2008

sr-users@lists.kamailio.org

146 participants
261 discussions

[OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK
by Eric Phetteplace 17 Feb '08

17 Feb '08

Hello, Here's the results of an ngrep command. It is showing a situation where I make a call on the PSTN to a DID, which terminates on my SIP Trunk. OpenSER receives the INVITE, etc. and I answer with my SIP phone, my phone OKs to OpenSER, OpenSER OKs to the SIP Trunk, but the SIP Trunk never ACKS. What causes this? Thanks, Eric interface: eth0 (192.168.2.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 8.21.8.24:5060 -> 192.168.2.10:5060 INVITE sip:1001@2.6.7.9 SIP/2.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 70. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 311. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 8.21.8.24. t=0 0. m=audio 15994 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. Server: OpenSER (1.3.0-notls (i386/linux)). Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 INVITE sip:1001@192.168.2.3 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 69. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 329. P-hint: usrloc applied. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 192.168.2.10. t=0 0. m=audio 35058 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 100 Trying. Content-Length: 0. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 8.21.8.24:5060 -> 192.168.2.10:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0;received=2.6.7.9. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . exit 18 received, 0 dropped

3 5

Re: [OpenSER-Users] Failover using NAPTR/SRV
by Douglas Garstang 17 Feb '08

17 Feb '08

Ok, so rfc3263 defines what the user agent should do when a 503 reply, or no reply is received. What about the rest of the possible SIP replies? We use several different ITSP's. I just checked the logs for our last 50,000 calls from all of them and there was a total of 19 different replies received. They are: 200,400,401,403,404,408,410,480,484,486,487,488,500,501,502,503,504,603 Some of these can occur under normal conditions, 486 is busy for example, or 487 is generated by a CANCEL. What about the rest? Most of the rest can be classified as error conditions. Are you saying that if another error condition besides 503 is received that you don't do failover? Why? Douglas. ----- Original Message ---- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: Douglas Garstang <dougmig33(a)yahoo.com>; users openser.org <users(a)openser.org> Sent: Friday, February 15, 2008 5:56:45 AM Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV Of course it is.....by IETF - see RFC3263. 4.3 Details of RFC 2782 Process Regards, Bogdan Douglas Garstang wrote: > Well that's weird. What do you mean by 'fail'? I thought dns_blacklist > was used when a 503 response was received? What if the connection > times out? What if another negative reply is received? Is this stuff > documented anywhere? > > ----- Original Message ---- > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > To: Tobias Lindgren <tobias.lindgren(a)ip-only.se> > Cc: users(a)openser.org > Sent: Thursday, February 14, 2008 3:25:33 AM > Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV > > Hi Tobias, > > if you have "dns_backlist=yes" in your config, if one of the destination > server fails (according to SIP definition), it's IP will be added to a > temporary blacklist (for 4 minutes) and not used. So, openser should do > dns-based failover and use the next entry provided by NAPTR/SRV/A lookup. > > Regards, > Bogdan > > Tobias Lindgren wrote: > > Hi all, > > > > I've been trying to find this information but I cannot find any exact > > specifications on how it really works. > > > > >From what I know using NAPTR/SRV records with OpenSER will allow > it to > > find and use servers behind those DNS-records. This works just fine. > > > > However, what I'm not sure about is what actually will happen in > OpenSER > > when one of two servers in this scenario would fail. > > > > For example, I have two servers as SRV where one is primary and one is > > secondary for SIP/UDP. What will happend in OpenSER when the primary > > server is down? Will OpenSER continue to send all request first towards > > that server or will it learn that one server is down and always send > > requests to the second server for a period of time and try the primary > > one just occassionally? > > > > Please direct me to any page where this is explained in detail, if such > > page exists. > > > > Br, > > /Tobias > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

1 0

Re: [OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK
by Eric Phetteplace 17 Feb '08

17 Feb '08

Thanks for the comments, I?aki and Robert. I have a tech support ticket open with the SIP Trunk provider. I'll let you know what we figure out. Their engineers won't be in for another 12 hours, so it might have to wait until then. Eric

1 0

[OpenSER-Users] Why OpenSer sends a "NOTIFY" when un-SUBSCRIBE for a contact?
by Iñaki Baz Castillo 16 Feb '08

16 Feb '08

Hi, if I send a un-SUBSCRIBE: ------------------------------------------------------------------ SUBSCRIBE sip:OPENSER_IP SIP/2.0 To: <sip:piru@domain.org>;tag=10.30692.1202986670.2 From: <sip:angel@domain.org>;tag=utxpu Accept: application/pidf+xml Event: presence Expires: 0 ------------------------------------------------------------------ then OpenSer replies with a 202 OK: ------------------------------------------------------------------ SIP/2.0 202 OK Expires: 0 ------------------------------------------------------------------ and later OpenSer sends me a NOTIFY: ------------------------------------------------------------------ NOTIFY sip:angel_aliax_net@212.121.235.18:5060 SIP/2.0 To: sip:angel@domain.org;tag=utxpu From: sip:piru@domain.org;tag=10.30692.1202986670.2 Event: presence Subscription-State: terminated;reason=timeout Content-Type: application/pidf+xml <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:piru@domain.org"> <tuple id="mzlben"> <status> <basic>open</basic> </status> </tuple> </presence> ------------------------------------------------------------------ My question is: why OpenSer sends the pidf+xml body in the NOTIFY? it's obvious that the user has no interest in the presence status of that contact. Maybe it's RFC mandatory? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 1

[OpenSER-Users] [CDRTool] BUG: Wrong price when multiple span
by Iñaki Baz Castillo 16 Feb '08

16 Feb '08

Hi, CDRTool can calculate the price of a call involving various spans (rates). But it does it wrongly since the start time for each span is set to the start time of the call, so the price is much higher than the correct one. An example: This is a call of more than 3 days of duration. Note that in spans 2, 3 and 4 the "StartTime" is 2008-02-16 15:57:05 in all (the start time of the call), and note also that the "Duration" of spans 2, 3 and 4 are the sum of each span and its previous spans: -- Span: 1 Duration: 28975 s StartTime: 2008-02-16 15:57:05 (Europe/Madrid) ProfileId: 01 Festivo for weekend RateId: Reducida for 0-24h Rate: 0.0100 / 60 s Price: 4.8292 -- Span: 2 Duration: 115375 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Festivo for weekend RateId: Reducida for 0-24h Rate: 0.0100 / 60 s Price: 19.2292 -- Span: 3 Duration: 144175 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Laboral for weekday RateId: Reducida for 0-8h Rate: 0.0100 / 60 s Price: 24.0292 -- Span: 4 Duration: 229878 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Laboral for weekday RateId: Normal for 8-22h Rate: 0.0300 / 60 s Price: 114.9390 -- Total: 163.0765 -- Iñaki Baz Castillo

1 0

[OpenSER-Users] OpenSerand RTPProxy, no RTP audio
by Eric Phetteplace 15 Feb '08

15 Feb '08

Hello, Following http://www.voip-info.org/wiki/index.php?page=OpenSER%20v1.2.x%20and%20RTPPro xy and cleaning up the errors in the log, I have OpenSER 1.3 and RTPProxy running in my local domain (192.168.2.10) I have two SIP phones in my local domain, on two machines. (2.5 and 2.3) I added an alias via openserctl ul add gail sip:192.168.2.5 Looking at the packets captured from a call between 2.5 and 2.3, 2.3 should start streaming RTP packets after it ACKs the 200 from 2.5 I call from 192.168.2.5 to gail(a)192.168.2.10 and the connection is established between the three, but no RTP streams ever begin. I expected to see 2.3 streaming RTP after it ACKs the 200 from 2.10. Any suggestions? Here's my cfg file: # # sample config file to be used with nathelper/rtpproxy # # start RTPProxy with: rtpproxy -l your_public_ip -s udp:localhost:8899 # # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 # --- module loading mpath="/usr/local/lib/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "textops.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "xlog.so" loadmodule "registrar.so" loadmodule "mi_fifo.so" loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "xcap_client.so" loadmodule "nathelper.so" # --- setting module parameters modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("auth_db","db_url","mysql://openser:secret@127.0.0.1/openser") modparam("registrar", "received_avp", "$avp(s:rcv)") modparam("xcap_client", "db_url", "mysql://openser:secret@127.0.0.1/openser") # -- usrloc params -- modparam("usrloc", "db_url", "mysql://openser:secret@127.0.0.1/openser") modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 3) # -- registrar params -- modparam("registrar", "received_avp", "$avp(s:rcv)") # -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:8899") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) #modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:pinger@openser.org") modparam("nathelper", "received_avp", "$avp(s:rcv)") # -- xlog modparam("xlog", "buf_size", 8192) # -- presence params -- modparam("presence|presence_xml|usrloc", "db_url", "mysql://openser:secret@127.0.0.1/openser") modparam("presence", "max_expires", 3600) modparam("presence_xml", "force_active", 1) modparam("presence", "server_address", "sip:127.0.0.1:5060" ) # --- main routing logic route{ xlog("***start***\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog("***end - Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); xlog("***end - Too big"); exit; }; # NAT detection route(2); if (!method=="REGISTER") { xlog("***route - recordroute\n"); record_route(); } if (loose_route()) { xlog("***route - looseroute\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { xlog("***route - not myself\n"); append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { xlog("***route - register"); if (!www_authorize("openser.org", "subscriber")) { xlog("***route - challenging"); www_challenge("openser.org", "0"); exit; }; if (isflagset(5)) { xlog("***route - isflagset(5)"); setflag(6); # if you want OPTIONS natpings uncomment next # setflag(7); }; save("location"); xlog("***route - registered"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("***route - 404, Not found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); xlog("***end***\n"); } route[1] { xlog("***route1***\n"); if (subst_uri('/(sip:.*);nat=yes/\1/')){ xlog("***route[1] - setflag(6)"); setflag(6); }; if (isflagset(5)||isflagset(6)) { xlog("***route[1] - route(3)"); route(3); } if (!t_relay()) { xlog("***route[1] - error"); sl_reply_error(); }; xlog("***end - route[1]"); exit; } route[2]{ xlog("***route2***\n"); force_rport(); if (nat_uac_test("19")) { xlog("***route2 - nat_uac_test(19)\n"); if (method=="REGISTER") { xlog("***route2 - register\n"); fix_nated_register(); } else { xlog("***route2 - contact\n"); fix_nated_contact(); }; setflag(5); }; } route[3] { xlog("***route3***\n"); if (is_method("BYE|CANCEL")) { xlog("***route3 - unforce\n"); unforce_rtp_proxy(); } else if (is_method("INVITE")){ xlog("***route3 - force\n"); force_rtp_proxy("i"); t_on_failure("1"); }; if (isflagset(5)) { xlog("***route3 - isflagset(5)\n"); search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); } t_on_reply("1"); } failure_route[1] { xlog("***failureroute1***\n"); if (isflagset(6) || isflagset(5)) { xlog("***failroute1 - unforce\n"); unforce_rtp_proxy(); } } onreply_route[1] { xlog("***onreplyroute1***\n"); if ((isflagset(5) || isflagset(6)) && status=~"(183)|(2[0-9][0-9])") { xlog("***onreplyroute1 - force\n"); force_rtp_proxy("i"); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isflagset(6)) { xlog("***onreplyroute1 - contact\n"); fix_nated_contact(); } xlog("***end - onreplyrout[1]"); exit; } Thanks, Eric

2 4

[OpenSER-Users] TM-module and ACK to 2xx (doesnt terminate txn?)
by Taisto Qvist 15 Feb '08

15 Feb '08

Oups, I seemed to have my maillist-subscription disabled so I never got the answers.... I seems like we dont agree on the interpretation of the txn handling for invite. Sure, there is a timer for handling retransmitted responses, but thats in earlier states than Terminated. Sure, there is nothing that says that the inner workings of your transactions must exactly behave as the statemachine diagrams in the rfc as long as the external behavior stays the same, but still, I think that the ACK for 2xx should not match the INVITE txn. (It probably boils down to how rfc-isch you want to be.) >The end-to-end ACK establish a separate transaction (RFC 3261) and these >ACKs are not match as part of the INVITE transactions, but correlated >with them. [TQ] Where does it say that ACKs establish a separate transaction? There is no defined ACK transaction, only INVITE/nonInvite, server and client. The ACK is either a part of the INVITE txn, or its a separate request, but I would never call it a standalone transaction. The real purpose of txn's (in my view), is to enable/simplify forking, and to handle retransmissions. Retransmissions of ACK and 2xx, are done by the UAC/UAS, so there is no need for a ack-txn. >but even describe the wait timer. So, there is no contradiction. [TQ] I'd say there is. Where does it describe that this wait-timer should be used for all responses, or for matching ALL acks? My two main reasons for saying that ACKs for 2xx should not be matched, come from the following two texts. (17.1.1.2, and 17.2.1) 17.1.1.2 (client invite txn) The client transaction MUST be destroyed the instant it enters the > "Terminated" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, > subsequent 2xx will find no match and therefore be passed to the core. [TQ] It even says "actually nessesary to guarantee...." Since the txn's are there to (among other things) absorb retransmissions, the receiving the 2xx MUST destroy the txn, so that when the next retransmission of 2xx is received, it is not consumed by the txn layer. This is what your txn-layer does for 3++ right? Any additional 3++ received on a txn while waiting for Timer D to expire, will just be consumed, and the proxy core will never have to process it. 17.2.1. (server invite txn) The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. ..snip... Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. [TQ] The Confirmed state is there to absorb retransmissions, not the terminated. When receiving 2xx you go directly to terminated bypassing confirmed. Also, in 18.2.1 the text explicitly says: .. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. Thats faily clear right? :-) The think that puzzles my a little bit though, is that you must have added "extra" code for this matching...? I mean, you're using the ;branch=z9xxxx for transaction matching right, if its there? And the ACK for 2xx doesnt have the same branch, indicating a "new txn". So matching ALL ACKs would imply that for any ACK that doesnt match a txn, your really checking up Call-Id's, tags and stuff, just to be able to match this ACK to the 2xx? Or are you checking callid's, cseq's, tags, and stuff, for ALL requests in your txn matching? Now, I been working on a sip-stack the last few years myself, and I naturally know that there is often a need to match the ACK, and the stack I've build has similar functions, it just doesnt do it on the txn layer, where we try to be as RFC-isch as possible. What I would like, is simply have some function-parameters to the t_check_trans(<param>), or even better in my little mind, a "modparam("tm", "ack_2xx_matching", 1)". I am looking forward to hearing your reply, and in the mean time, thanks to all of you developers for an extraordinary software :-) Regards Taisto Qvist > Hi guys, > > Just to bring some clarifications on the TM module. > > once a transaction is completed (negative or 2xx reply), it is put on > wait (wait timer - see RFC3261) for catching any potential > retransmissions of replies. > So, the transaction is completed, but not removed from memory - RFC does > not say that you need to trash immediately all the transaction > information, but even describe the wait timer. So, there is no > contradiction. > > The ACK (for 2xx)catching is done based on the completed INVITE > transaction (from wait timer) - nothing else. > > > Inaki, could you please detail what you mean by: > > <quote> > In my opinion OpenSer does a special treatment for ACK in tm mode, even if > they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE > (end-to-end ACK's). > > </quote> > > Maybe I can explain you more if I understand you question.... > > Regards, > Bogdan

3 2

[OpenSER-Users] How to account INVITEs and not "200 OK"s?
by Peter Lemenkov 15 Feb '08

15 Feb '08

Hello All! Right now OpenSER generates Acc-Session-Start when "200 OK" message arrives. I need to generate Acc-Session-Start exactly in that moment when INVITE received (I can't need to wait for answer from other side). So how can I do it? -- With best regards!

3 6

Re: [OpenSER-Users] Failover using NAPTR/SRV
by Bogdan-Andrei Iancu 15 Feb '08

15 Feb '08

Of course it is.....by IETF - see RFC3263. 4.3 Details of RFC 2782 Process Regards, Bogdan Douglas Garstang wrote: > Well that's weird. What do you mean by 'fail'? I thought dns_blacklist > was used when a 503 response was received? What if the connection > times out? What if another negative reply is received? Is this stuff > documented anywhere? > > ----- Original Message ---- > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > To: Tobias Lindgren <tobias.lindgren(a)ip-only.se> > Cc: users(a)openser.org > Sent: Thursday, February 14, 2008 3:25:33 AM > Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV > > Hi Tobias, > > if you have "dns_backlist=yes" in your config, if one of the destination > server fails (according to SIP definition), it's IP will be added to a > temporary blacklist (for 4 minutes) and not used. So, openser should do > dns-based failover and use the next entry provided by NAPTR/SRV/A lookup. > > Regards, > Bogdan > > Tobias Lindgren wrote: > > Hi all, > > > > I've been trying to find this information but I cannot find any exact > > specifications on how it really works. > > > > >From what I know using NAPTR/SRV records with OpenSER will allow > it to > > find and use servers behind those DNS-records. This works just fine. > > > > However, what I'm not sure about is what actually will happen in > OpenSER > > when one of two servers in this scenario would fail. > > > > For example, I have two servers as SRV where one is primary and one is > > secondary for SIP/UDP. What will happend in OpenSER when the primary > > server is down? Will OpenSER continue to send all request first towards > > that server or will it learn that one server is down and always send > > requests to the second server for a period of time and try the primary > > one just occassionally? > > > > Please direct me to any page where this is explained in detail, if such > > page exists. > > > > Br, > > /Tobias > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>

1 0

Re: [OpenSER-Users] Radius Acct Syntax Error?
by A.smith 15 Feb '08

15 Feb '08

>modparam("acc", "radius_config", "/usr/local/etc/radiusclient/ >radiusclient.conf"); I think you dont need the ";" as this isnt the last param you set for acc, other than that in theory this should be fine, i have had similar config working, it does need to be a single line of text of course and I dont know if its just the way it apears on the list but there seems to be white space between radiusclient/ and radiusclient.conf Also I´ve had issues with non-printable characters being in my config file from copying and pasting from web pages srewing up what looks like a properly formated cfg, maybe check this...?? cheers Andy. ________________________________________________ Message sent using UK Grid Webmail 2.7.9

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
27
Older →

Jump to page:

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 February 2008