sr-users

sr-users@lists.kamailio.org

50 participants
37556 discussions

[Users] Not Hung Up when i Keep the Server in Router_firewall( NETGEAR)
by raviprakash sunkara 08 Nov '06

08 Nov '06

Hello User, A small Question , When I My Sip Server without any firewall_ Router .. Hung up is working Fine,,,,,, But I Keep Sip Server with in a Firewall_router, it not Hung upping , When i saw logs from X-lite in Bye method it Changing the uri into Private IP, But should it public IP( THis is not happening ) Please help me............. -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 O:+91 40 23114549 F:+91 40 40208727 ravi.sunkara(a)… [View More]

2 1

[Serusers] mediaproxy and ser ottendorf incompatible right now
by samuel 08 Nov '06

08 Nov '06

I was trying to use mediaproxy module with SER ottendorf and got next error: error: mediaproxy/mod_init(): can't find is_from_local and/or is_uri_host_local functions. Check if domain.so is loaded domain.so is effectively loaded BUT these functions have been replaced by is_local,lookup_domain, and get_did in new SER version Is AG Projects taking care of this issue?!? Can someone shed dome light on this issue!??!?!? Thanks a lot, Samuel.

1 0

Re: [Users] TM : retransmission timers
by Rao Ramaratnamma 08 Nov '06

08 Nov '06

Greg, The email from you and others is giving me the type of most direct fair insights I am looking for . You know, just some practical "what is all this about" type of things for my selforientation. Just that openser link you are attaching unfortunately looks too much like openser marketing material. It is saying that ser was discontinued but actually the information I'm getting from others telling me that it has some features which are very important and openser do not have. With all … [View More]respect, it is understandable that openser people write nicely about themselves and less nicely about others but it remains so confusing that I do not have confidence to move with this particular material. The openser info just appears too little credible for me. I think I am beginning to get the bottom line and I hope I will create my mind soon and if people have other information for me pls send it. Especially, objective technical information including this timer discussion is helping me. You know, better understanding what is the difference in "what they think is important". That would surely help me beyound the filosophical "cats or dogs, who is a better friend of man" information aqusition phase people surely like to be engaged in :-) Thank you all guys for keeping helping me a lot, rr ----- Original Message ---- From: Greg Fausak <lgfausak(a)gmail.com> To: Rao Ramaratnamma <raramarat(a)yahoo.com> Cc: Christian Schlatter <cs(a)unc.edu>; users(a)openser.org Sent: Wednesday, November 8, 2006 5:21:41 AM Subject: Re: [Users] TM : retransmission timers You can go to openser.org's website and read about howhow openser and ser are related. http://www.openser.org/index.php?option=com_content&task=view&id=40&Itemid=… They are now two separate bodies of code, maintained by two different groups. Each one has gone off and implemented and support what they think is important. Both projects are open source projects, anyone is certainly welcome to contribute to either. -g On Nov 7, 2006, at 4:15 PM, Rao Ramaratnamma wrote: the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter! Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer. thank you in advance! rr ----- Original Message ---- From: Christian Schlatter <cs(a)unc.edu> To: users(a)openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers Greg Fausak wrote: > Hello, > > I believe this is a well known bug. > Granularity of timers is 1 second. So, if you sign up for a timer to > be fired in 1 second it will happen anywhere between 0 seconds and 1 > second. > 2 seconds will happen between 1 and 2 seconds. I usually set up my > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > sticky about > the first 500ms. If you are using one of them you're out of luck. Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times. Christian > > I believe SER has made timer changes to support more exact timer > intervals. They are a completely different camp, with a different feature > set (although they share the same roots). > > -g > > > On 11/7/06, Jean-François SMIGIELSKI <jf-smig(a)ibelgique.com> wrote: >> Hello, >> >> I made strange observations about the intervals between >> retransmissions with the TM module. >> In my experiments, I used the default parameters for the TM module >> timers, and I sent an INVITE that cannot receive answers (it has a >> well known R-URI pattern that is forwarded to a place and port that >> nobody listen). >> >> When reading RFC3261, I expected to see intervals between >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. >> >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s >> are spent (9 sendings). The first interval is sometomes very short >> (40ms). >> >> Altough I like the sequence of 4s separated transmissions, I do not >> know why the first interval is so short, and why there is no sending >> after 1s. >> >> Did anybody observed such behaviours? Are they normal? >> >> Thanks in advance! >> >> JF Smigielski. >> >> >> ________________________________________________________________________ >> iBELGIQUE, exprimez-vous ! >> http://web.ibelgique.com/ >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users [View Less]

1 0

[Users] TM : retransmission timers
by Jean-François SMIGIELSKI 08 Nov '06

08 Nov '06

Hello, I made strange observations about the intervals between retransmissions with the TM module. In my experiments, I used the default parameters for the TM module timers, and I sent an INVITE that cannot receive answers (it has a well known R-URI pattern that is forwarded to a place and port that nobody listen). When reading RFC3261, I expected to see intervals between retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. But with OpenSER, (I have tested with the … [View More]

5 6

[Serusers] grandstream configuration -- help
by Ravi ***** 08 Nov '06

08 Nov '06

Hi users , I am using ser-0.96 , and every thing seems to work fine . but when I make calls from grandstream ATA .. its is working properly but the problem is when the other party hung the phone SER cannot send BYE packets to grandstream NAT ip . It is sending to grandstream private-ip which inturns delayed for acct.stop packet unless grandstream hung the phone x-lite, is O.K and its sending to SER as tel.no@Nat-ip-address but grandstream is sending to SER as tel.no@… [View More]

2 1

[Serusers] Problem with CANCEL messages and Cisco 7905
by Kristian Larsson 08 Nov '06

08 Nov '06

Hey! This is my first time posting to the list, although I'm a long time reader :) I have searched the archives as well as the internet and found no solution or answer to this so far. Perhaps my Google Kung Fu isn't what it should be. Anyhow, I have a cisco 7905 phone working together with a SER machine. When dialing to the 7905 phone from another phone and hanging up on the caller phone before answering the 7905, ie CANCEL before the call has actually been setup, I get a "SIP/2.0 481 Call … [View More]

2 2

[Users] pstn-to-openser, 403 Forbiden
by Ion Minzu 08 Nov '06

08 Nov '06

Hello , I have connected openser with pstn through cisco. when I make a call from voip network to pstn it's ok. but from pstn to voip I have a problem:openser answers 403 forbiden. in openser I do the authorisation on mysql, I have disabled authorisation on sip gateway: if (src_ip!=X.X.X.X) { if (!www_authorize("DOMAIN.COM","subscriber")) { www_challenge("DOMAIN.COM","0"); exit; } }; What is the problem? X.X.X.X is cisco U X.X.X.X:54177 -> 172.… [View More]17.6.2:5060 INVITE sip:820022@172.17.6.2:5060 SIP/2.0..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.1 7.6.2>..Date: Wed, 08 Nov 2006 11:03:14 GMT..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..Supported: timer,100rel..Min-SE: 1800..Cisco-Guid : 2422905184-1850675675-2419190351-3917593119..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBS CRIBE, NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards: 6..Remote-Party-ID: <sip:022250699@X.X.X.X>;party=calling;screen=yes;privacy=off..Timestamp: 116 2983794..Contact: <sip:022250699@X.X.X.X:5060>..Expires: 180..Allow-Events: telephone-event..Content-Type: application/sdp..Content-Length: 235....v= 0..o=CiscoSystemsSIP-GW-UserAgent 1226 5023 IN IP4 X.X.X.X..s=SIP Call..c=IN IP4 X.X.X.X..t=0 0..m=audio 16642 RTP/AVP 18 19..c=IN IP4 X.X.X.X..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a=rtpmap:19 CN/8000..a=ptime:20.. # U 172.17.6.2:5060 -> X.X.X.X:5060 SIP/2.0 403 Use From=ID..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.17.6.2>;tag=329cfeaa6ded039da25ff8cbb8668bd2.13ec..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..CSeq: 101 INVITE..Server: OpenSer (1.1.0-tls (x86_64/linux))..C ontent-Length: 0..Warning: 392 172.17.6.2:5060 "Noisy feedback tells: pid=32240 req_src_ip=X.X.X.X req_src_port=54177 in_uri=sip:820022@172.17.6.2:5 060 out_uri=sip:820022@172.17.6.2:5060 via_cnt==1".... # U X.X.X.X:54177 -> 172.17.6.2:5060 ACK sip:820022@172.17.6.2:5060 SIP/2.0..Via: SIP/2.0/UDP X.X.X.X:5060..From: <sip:022250699@X.X.X.X>;tag=1A0FBC30-1472..To: <sip:820022@172.17.6 .2>;tag=329cfeaa6ded039da25ff8cbb8668bd2.13ec..Date: Wed, 08 Nov 2006 11:03:14 GMT..Call-ID: 906DA628-6E4F11DB-9034EA4F-E981BA1F@X.X.X.X..Max-Forward s: 6..Content-Length: 0..CSeq: 101 ACK.... Best regards, Ion Minzu, Specialist Tehnologii Informationale, Administrator de sistem al Centrului de certificare, Administrator VoIP, I.S."Centrul de Telecomunicatii Speciale", tel:250-517 (office), 069501208 (mob), 382869185 (ICQ) mailto:ion.minzu@cts.md [View Less]

3 2

[Users] OpenSER + SEMS + Nat?
by Brandon Armstead 08 Nov '06

08 Nov '06

Hello, I currently have an openser server running on port 5060, and a second that handles voicemail / stateful transaction stuff on port 5070. So, I am having proxy A forward to proxy B to do the handling which are both on the same server, although there seems to be a problem with NAT'ing, when I call 'voicemail' or something I can not hear anything. It seems to be because it is sending the RTP data to the wrong location? It should be sending it back to public-ip-addr-1 when it is … [View More]sending to an internal ip address 192.168.1.* Here is the log from sems: 101 44811:1466724767 <sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on> sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on P-MsgFlags: 0 UA: Linksys/PAP2-3.1.9(LSa) P-Email-Address: test(a)test.com . v=0 o=- 9200357 9200357 IN IP4 192.168.1.241 s=- c=IN IP4 192.168.1.241 t=0 0 m=audio 16420 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: execute (AmInterfaceHandler.cpp:99): req.method = <INVITE> (7856) DEBUG: execute (AmInterfaceHandler.cpp:100): req.user = <115> (7856) DEBUG: execute (AmInterfaceHandler.cpp:101): req.domain = <public-ip-addr-1> (7856) DEBUG: execute (AmInterfaceHandler.cpp:102): req.dstip = <public-ip-addr-1> (7856) DEBUG: execute (AmInterfaceHandler.cpp:103): req.port = <5070> (7856) DEBUG: execute (AmInterfaceHandler.cpp:104): req.r_uri = < sip:115@public-ip-addr-1:5070> (7856) DEBUG: execute (AmInterfaceHandler.cpp:105): req.from_uri = < sip:1000@192.168.1.241:5060> (7856) DEBUG: execute (AmInterfaceHandler.cpp:106): req.from = <Brandon1 < sip:1000@test.mydomain.com>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:107): req.to = << sip:115@test.mydomain.com>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:108): req.callid = < 81e2d596-978fccc6(a)192.168.1.241> (7856) DEBUG: execute (AmInterfaceHandler.cpp:109): req.from_tag = <dd9bbf561d35ee06o0> (7856) DEBUG: execute (AmInterfaceHandler.cpp:110): req.to_tag = <> (7856) DEBUG: execute (AmInterfaceHandler.cpp:113): cseq_str = <101> (7856) DEBUG: execute (AmInterfaceHandler.cpp:119): cseq = <101>(101) (7856) DEBUG: execute (AmInterfaceHandler.cpp:121): req.key = <44811:1466724767> (7856) DEBUG: execute (AmInterfaceHandler.cpp:122): req.route = <<sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on>> (7856) DEBUG: execute (AmInterfaceHandler.cpp:123): req.next_hop = <sip:public-ip-addr-1:5060;nat=yes;ftag=dd9bbf561d35ee06o0;lr=on> (7856) DEBUG: execute (AmInterfaceHandler.cpp:128): hdrs = <P-MsgFlags: 0 UA: Linksys/PAP2-3.1.9(LSa) P-Email-Address: test(a)test.com > (7856) DEBUG: execute (AmInterfaceHandler.cpp:133): body = <v=0 o=- 9200357 9200357 IN IP4 192.168.1.241 s=- c=IN IP4 192.168.1.241 t=0 0 m=audio 16420 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: execute (AmInterfaceHandler.cpp:144): Request OK: dispatch it! (7856) DEBUG: postEvent (AmEventQueue.cpp:48): AmEventQueue: trying to post event (7856) DEBUG: postEvent (AmEventQueue.cpp:56): AmEventQueue: event posted (7856) DEBUG: processEvents (AmEventQueue.cpp:69): before processing event (7856) DEBUG: process (AmSession.cpp:421): AmSession::process (7856) DEBUG: process (AmSession.cpp:425): Session received SIP Event (7856) DEBUG: onSipRequest (AmSession.cpp:472): onSipRequest: method = INVITE (7856) DEBUG: parse_sdp_media (AmSdp.cpp:632): next_line=<a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:0 PCMU/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=0; enc=PCMU; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:2 G726-32/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=2; enc=G726-32; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:4 G723/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=4; enc=G723; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:8 PCMA/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=8; enc=PCMA; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:18 G729a/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=18; enc=G729a; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:96 G726-40/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=96; enc=G726-40; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:97 G726-24/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=97; enc=G726-24; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:98 G726-16/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=98; enc=G726-16; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:100 NSE/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=100; enc=NSE; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:101 telephone-event/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=101; enc=telephone-event; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=fmtp:101 0-15 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=ptime:30 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:740): unknown attribute definition 'ptime:30' (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=sendrecv (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:745): flag definition is not yet supported (sendrecv) (7856) DEBUG: parse_sdp_media (AmSdp.cpp:651): ret=0; next_line=<> (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:341): payload found: 0/PCMU/8000 (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:344): using global address: 192.168.1.241 (7856) DEBUG: negotiate (AmSession.cpp:247): remote party supports telephone events (pt=101) (7856) DEBUG: setRAddr (AmRtpStream.cpp:346): RTP remote address set to 192.168.1.241:16420 (7856) DEBUG: init (AmRtpAudio.cpp:146): AmRtpAudio::init(...) (7856) DEBUG: acceptAudio (AmSession.cpp:607): Sending Rtp data to 192.168.1.241/16420 (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:86): reply: transaction found! (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:125): req.method = INVITE; t.method = INVITE (7856) DEBUG: init (AmCtrlInterface.cpp:231): AmUnixCtrlInterface::init @ /tmp/5D08F0A1-4552226600080041-08108600 (7856) DEBUG: write_to_socket (AmUtils.cpp:588): sending: <:t_reply:/tmp/5D08F0A1-4552226600080041-08108600 200 OK 44811:1466724766 193812C5-45522256000F0C97-08103000 Contact: <sip:115@public-ip-addr-1:5070> Content-Type: application/sdp . v=0 o=username 0 0 IN IP4 public-ip-addr-1 s=session c=IN IP4 public-ip-addr-1 t=0 0 m=audio 10022 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 . > (7856) DEBUG: write_to_socket (AmUtils.cpp:614): write to unix socket: completed (7856) DEBUG: cacheMsg (AmCtrlInterface.cpp:186): recv-ed: <200 Succeeded> (7856) DEBUG: processEvents (AmEventQueue.cpp:71): event processed (7856) DEBUG: processEvents (AmEventQueue.cpp:69): before processing event (7856) DEBUG: process (AmSession.cpp:421): AmSession::process (7856) DEBUG: process (AmSession.cpp:425): Session received SIP Event (7856) DEBUG: onSipRequest (AmSession.cpp:472): onSipRequest: method = INVITE (7856) DEBUG: parse_sdp_media (AmSdp.cpp:632): next_line=<a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv > (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:0 PCMU/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=0; enc=PCMU; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:2 G726-32/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=2; enc=G726-32; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:4 G723/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=4; enc=G723; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:8 PCMA/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=8; enc=PCMA; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:18 G729a/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=18; enc=G729a; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:96 G726-40/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=96; enc=G726-40; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:97 G726-24/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=97; enc=G726-24; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:98 G726-16/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=98; enc=G726-16; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:100 NSE/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=100; enc=NSE; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=rtpmap:101 telephone-event/8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:693): sdp attribute: pt=101; enc=telephone-event; cr=8000 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=fmtp:101 0-15 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=ptime:30 (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:740): unknown attribute definition 'ptime:30' (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:658): parse_sdp_attribute: s=sendrecv (7856) DEBUG: parse_sdp_attribute (AmSdp.cpp:745): flag definition is not yet supported (sendrecv) (7856) DEBUG: parse_sdp_media (AmSdp.cpp:651): ret=0; next_line=<> (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:341): payload found: 0/PCMU/8000 (7856) DEBUG: getCompatiblePayload (AmSdp.cpp:344): using global address: 192.168.1.241 (7856) DEBUG: negotiate (AmSession.cpp:247): remote party supports telephone events (pt=101) (7856) DEBUG: setRAddr (AmRtpStream.cpp:346): RTP remote address set to 192.168.1.241:16420 (7856) DEBUG: init (AmRtpAudio.cpp:146): AmRtpAudio::init(...) (7856) DEBUG: acceptAudio (AmSession.cpp:607): Sending Rtp data to 192.168.1.241/16420 (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:86): reply: transaction found! (7856) DEBUG: updateStatusReply (AmSipDialog.cpp:125): req.method = INVITE; t.method = INVITE (7856) DEBUG: init (AmCtrlInterface.cpp:231): AmUnixCtrlInterface::init @ /tmp/75EE09BE-4552226600080514-08108600 (7856) DEBUG: write_to_socket (AmUtils.cpp:588): sending: <:t_reply:/tmp/75EE09BE-4552226600080514-08108600 200 OK 44811:1466724767 193812C5-45522256000F0C97-08103000 Contact: <sip:115@public-ip-addr-1:5070> Content-Type: application/sdp . v=0 o=username 0 0 IN IP4 public-ip-addr-1 s=session c=IN IP4 public-ip-addr-1 t=0 0 m=audio 10022 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 . > (7856) DEBUG: write_to_socket (AmUtils.cpp:614): write to unix socket: completed (7856) DEBUG: cacheMsg (AmCtrlInterface.cpp:186): recv-ed: <200 Succeeded> (7856) DEBUG: processEvents (AmEventQueue.cpp:71): event processed (7856) DEBUG: run (AmSession.cpp:292): 81e2d596-978fccc6(a)192.168.1.241 dlg.getUACTransPending() = 0 Here is my config for "proxy B" the transaction handling with SEMS that "proxy A" sends to: # # $Id: ser.cfg,v 1.25.2.1 2005/02/18 14:30:44 andrei Exp $ # # ser for sems configuration # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5070 children=4 unix_sock="/tmp/openser_sems_sock" # ------------------ module loading ---------------------------------- mpath="/usr/local/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) modparam("avpops", "avp_aliases", "email=i:67") modparam("tm", "pass_provisional_replies", 1) # appends for INVITE to voicemail modparam("tm", "tw_append", "voicemail_headers:UA=$hdr(User-Agent);P-Email-Address=$avp(s:email)") # appends for dtmf per INFO modparam("tm", "tw_append", "info_append:Content-Length=$hdr(Content-Length);Content-Type=$hdr(Content-Type);$rb") # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); return; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); return; }; if (method != "ACK" && method != "INVITE" && method != "BYE" && method != "CANCEL" && method != "INFO" ){ log("unsupported method\n"); sl_send_reply("500","unsupported method"); return; } # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing # make transaction if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); if (!t_relay()) { sl_reply_error(); } return; }; if (!t_newtran()){ log("could not create transaction\n"); sl_send_reply("500","could not create transaction"); return; } # actively absorb ACKs if (method == "ACK") { t_relay(); return; } # pass INFO to SEMS if (method=="INFO") { if(!t_write_unix("/tmp/sems_sock","sems/info_append")){ log("could not contact sems\n"); t_reply("500","could not contact media server"); } } if (uri =~ "sip:101.*@") { if (!t_write_unix("/tmp/sems_sock","myapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:102.*@") { if (!t_write_unix("/tmp/sems_sock","myconfigurableapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:103.*@") { if (!t_write_unix("/tmp/sems_sock","myannounceapp")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:104.*@") { if (!t_write_unix("/tmp/sems_sock","myjukebox")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:105.*@") { if (!t_write_unix("/tmp/sems_sock","mycc")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:106.*@") { if (!t_write_unix("/tmp/sems_sock","ivr_announce")){ log("could not contact media server\n"); t_reply("500","could not contact media server"); return; } return; } ############ default sems apps if (uri =~ "sip:110.*@") { if (!t_write_unix("/tmp/sems_sock","echo")){ log("could not contact echo\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:111.*@") { if (!t_write_unix("/tmp/sems_sock","announcement")){ log("could not contact announcement\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:112.*@") { if (!t_write_unix("/tmp/sems_sock","conference")){ log("could not contact conference\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:113.*@") { if (!t_write_unix("/tmp/sems_sock","mailbox")){ log("could not contact mailbox\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:114.*@") { if (!t_write_unix("/tmp/sems_sock","early_announce")){ log("could not contact early_announce\n"); t_reply("500","could not contact media server"); return; } return; } if (uri =~ "sip:115.*@") { # load email avp with some email address avp_write("test(a)test.com","$avp(s:email)"); # use voicemail_headers append to pass it to sems if (!t_write_unix("/tmp/sems_sock","voicemail/voicemail_headers")){ log("could not contact voicemail\n"); t_reply("500","could not contact media server"); return; } return; } t_reply("404","Not found"); } Thank you, any and all help is appreciated, thanks again! -- Brandon Armstead [View Less]

1 0

[Serusers] Using scripts with exec module
by Prettl, Kathrin 08 Nov '06

08 Nov '06

I have written a shell script which has a return value of either 0 or 1. Depending on the outcome of this script I want SER to react. I know I have to use the exec module for this but I don't know how. Can anyone help? Thanks, Kathrin

3 3

Fw: [Users] TM : retransmission timers
by Rao Ramaratnamma 08 Nov '06

08 Nov '06

sorry for reposting -- I think this question belongs to both mailing list. I am really stuck with this. rr ----- Forwarded Message ---- From: Rao Ramaratnamma <raramarat(a)yahoo.com> To: Christian Schlatter <cs(a)unc.edu>; users(a)openser.org Sent: Tuesday, November 7, 2006 11:15:27 PM Subject: Re: [Users] TM : retransmission timers the ser ottendorf announcement does mention improved timers. Cannot openser include this feature too and cannot I merge ser with openser for good … [View More]timers? I am still trying to understand the difference between ser and openser but standart compliance seems to be very important matter! Cannot people provide me with some hints? I am sure that I am not the only who is asking the difference between ser and openser. ser documentation does not appear uptodate, but the software as sannounced appears impressive. I have already asked this question but did not receive any answer. thank you in advance! rr ----- Original Message ---- From: Christian Schlatter <cs(a)unc.edu> To: users(a)openser.org Sent: Tuesday, November 7, 2006 10:52:56 PM Subject: Re: [Users] TM : retransmission timers Greg Fausak wrote: > Hello, > > I believe this is a well known bug. > Granularity of timers is 1 second. So, if you sign up for a timer to > be fired in 1 second it will happen anywhere between 0 seconds and 1 > second. > 2 seconds will happen between 1 and 2 seconds. I usually set up my > timers to be 2, 2, 4, 8. There are VOIP providers that are pretty > sticky about > the first 500ms. If you are using one of them you're out of luck. Yes, there is a timer process that wakes up every second to perform retransmissions. I was actually quite surprised that OpenSER, which is known to be very standards compliant, does not follow the RFC 3261 retransmission timeouts. On the other hand, the RFC 3261 timeout values are just suggestions and standards compliant SIP UA must accept shorter timeouts. Still it would be nice if OpenSER would support sub second timers, this would allow for shorter fail-over times. Christian > > I believe SER has made timer changes to support more exact timer > intervals. They are a completely different camp, with a different feature > set (although they share the same roots). > > -g > > > On 11/7/06, Jean-François SMIGIELSKI <jf-smig(a)ibelgique.com> wrote: >> Hello, >> >> I made strange observations about the intervals between >> retransmissions with the TM module. >> In my experiments, I used the default parameters for the TM module >> timers, and I sent an INVITE that cannot receive answers (it has a >> well known R-URI pattern that is forwarded to a place and port that >> nobody listen). >> >> When reading RFC3261, I expected to see intervals between >> retransmissions of |500ms|1s|2s|4s|8s|16s|. 7 transmissions, during 32s. >> >> But with OpenSER, (I have tested with the debian package 1.1.0-5 on a >> debian etch, and the cvs sources for 1.1.0 or 1.0.1compiled by >> myself), I can see intervals like <500ms, 2s, 4s, 4s,4s, ... until 26s >> are spent (9 sendings). The first interval is sometomes very short >> (40ms). >> >> Altough I like the sequence of 4s separated transmissions, I do not >> know why the first interval is so short, and why there is no sending >> after 1s. >> >> Did anybody observed such behaviours? Are they normal? >> >> Thanks in advance! >> >> JF Smigielski. >> >> >> ________________________________________________________________________ >> iBELGIQUE, exprimez-vous ! >> http://web.ibelgique.com/ >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users [View Less]

7 12

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