sr-users November 2008

sr-users@lists.kamailio.org

97 participants
170 discussions

[Kamailio-Users] Thomson ST2030 SIP contact problem

by Samuel Muller

Hello all, I've a little problem with the SIP phone Thomson ST2030. When it registers, it auto-adds ";user=phone" in all the fields it can be. The problem is that it can't be called due to the contact header, kamailio can't found the phone. I tried to delete the filed during the REGISTER and the PROXY AUTH processes, with no success ... If someone has a solution, many thanks ! -- -- kamailio.cfg : -- -- ... # ;user=phone hack if (search("^Contact:.*;user=phone")) { xlog("L_INFO", "-> user=phone found, remove it - F=$fu ContactHF=$ct"); replace_all(";user=phone", "\r\n"); #subst("/;user=phone$;$")) } ... => all the logs here : -- -- SQL result -- -- Database: openser SQL query: SELECT * FROM `location` WHERE `id` = 383 LIMIT 0, 30 ; id 383 username 0123451013 domain sip.720.fr contact sip:0123451013@192.168.0.158:5060;user=phone received sip:77.246.81.162:1902 path NULL expires 2008-11-28 13:02:16 q 0.00 callid 18786315-c0a80101-5-a(a)192.168.0.158 cseq 270 last_modified 2008-11-28 12:02:16 flags 0 cflags 64 user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A socket udp:77.246.81.132:5060 methods NULL -- -- kamailio REGISTER sip buffer -- -- REGISTER sip:sip.720.fr;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.158:5060 ;branch=z9hG4bK363142985921875976-158787787 From: <sip:0123451013@sip.720.fr:5060;user=phone>;tag=c0a80101-976e8ab To: <sip:0123451013@sip.720.fr:5060;user=phone> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 CSeq: 250 REGISTER Max-Forwards: 69 Expires: 3600 Contact: <sip:0123451013@192.168.0.158:5060;user=phone> Authorization: Digest username="0123451013", realm="sip.720.fr", nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", uri="sip:sip.720.fr", response="37f8ec824ba77eb37583f38f2a509f77", algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A Allow-Events: refer,dialog,message-summary,check-sync,talk,hold Content-Length: 0 -- -- ngrep log : -- -- U 2008/11/28 12:13:59.813649 77.246.81.162:8680 -> 77.246.81.132:5060 INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >;screen=yes;party=calling. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". Contact: "Sam" <sip:0123451010@192.168.0.113:5060>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 263. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 192.168.0.113. t=0 0. m=audio 35692 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2008/11/28 12:13:59.820056 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14141 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". . U 2008/11/28 12:13:59.882639 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:00.273883 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:01.272604 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:03.283852 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:04.905612 77.246.81.162:8680 -> 77.246.81.132:5060 CANCEL sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="07e4433c6000309b8cac1f917dbb9643",qop=auth,nc=00000002,cnonce="7c8a76fd". User-Agent: Linksys/SPA941-5.1.8. Content-Length: 0. . U 2008/11/28 12:14:04.912088 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 501 Method Not Supported Here. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >;tag=d25c9349df891607b66aeb00d1da49ca.b1d0. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14137 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

15 years, 11 months

[Kamailio-Users] Webx-SER: a new project to give kamailio users a web interface (like Serweb was)

by yannick

Hello, I started a project to give users of Kamailio server a web interface to register and manage their datas. It was inspired by a need of the Ekiga.net platform ( https://www.ekiga.net ) to allow users register like they were able to do when Ekiga.net was using SER and Serweb. I called this software Webx-SER. Webx-SER feature now: * Registration of accounts to kamailio * Password reminder * Changing password Technically, Webx-SER use PHP and MySQL. It has a cache system for common non-interactives pages, a template system to split HTML from PHP and a captcha system to prevent bots. Some work has been put in managing forms to make it user-friendly. The licence is GPL 3 or higher. Webx-SER is actually used on https://www.ekiga.net There is a web site for Webx-SER developments, including users and devels mailing-list, bug tracking system, source tarball releases and GIT repository for source code here: http://webxser.tuxfamily.org/ Feedback, comments, help in coding will be warmly welcome. I also want to thanks Damien Sandras and Jan Schampera for their help, support and inspiration. Best regards, Yannick Defais -- Me joindre en téléphonie IP / vidéoconférence ? sip:yannick@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F

15 years, 11 months

[Kamailio-Users] Attendant call transfer between asterisk gateway and OpenSER problem

by muhammad akl

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace : http://muhammad.akl.googlepages.com/debug.txt Regards

15 years, 12 months

Re: [Kamailio-Users] Trying to deliver a call across multiple peers with t_relay

by Tyler Brauer

Thank you Klaus for the suggestions. I've implemented the configuration below. When the first t_relay fails, Kamailio generates the 408 Request Timeout and doesn't attempt to try an INVITE to the second address. This what the syslog says: Nov 28 06:11:13 server kamailio[1315]: Attempting Carrier 1 Nov 28 06:11:28 server kamailio[1323]: Attempting Carrier 2 Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:t_forward_nonack: no branch for forwarding Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:w_t_relay: t_forward_nonack failed Nov 28 06:11:28 server kamailio[1317]: Attempting Carrier 1 And here's the watered-down version of my configuration. # - - - - - - - - - - - - - - - - - - - - route[0] { if($si=='10.10.10.10') { # Allowed Host route(1); } else { sl_send_reply("603", "Decline"); exit; } } # - - - - - - - - - - - - - - - - - - - - route[1] { if(msg:len > 2048) { sl_send_reply("513", "Message Too Big"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } if (method==OPTIONS) { if ((uri==myself) && (! uri=~"sip:.*[@]+.*")) { options_reply(); exit; } } if (!method=="REGISTER") { record_route(); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); } if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; } route(2); } # - - - - - - - - - - - - - - - - - - - - route[2] { xlog("L_INFO", "Attempting Carrier 1"); t_on_failure("3"); t_relay("udp:1.1.1.1:5090","0x2"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[3] { xlog("L_INFO", "Attempting Carrier 2"); t_on_failure("4"); t_relay("udp:2.2.2.2:5060"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[4] { # I would like to know how to redirect the # original call destined to extension "100" # to 2015551234, but the originating server # will get nervous if the username@ part # of its SIP request is changed. How could } # - - - - - - - - - - - - - - - - - - - - Any further suggestions would be appreciated. Thanks!

15 years, 12 months

[Kamailio-Users] Does enum_query support wildcard and non-terminal NAPTR record ?

by jerome boileau

Hi, I'm testing an ENUM DNS server (BIND9) with Openser 1.2.0. It seems that Openser Enum module doesn't support wildcard and non terminal NAPTR record. Enum module is working well when the NAPTR record is defined in the ENUM DNS with complete phone number and ‘u’ flag. Here is an example of the NAPTR record: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!". When I declared a wildcard in the ENUM DNS (ie: *.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!".), enum_query function didn't find the NAPTR record. The following message is returned in the log, enum_query(): No NAPTR record found for 1.2.3.4.5.6.7.8.9.3.3.enum1.net. Should resolver (ie resolve.c source file) or enum module be modified to handle wildcard or is it just a parameter to set ? In case of wildcard CNAME record instead of NAPTR, openser behave in the same way, the CNAME record was not found. I also tried to use a non-terminal NAPTR to forward the ENUM DNS query towards another domain. Here is the NAPTR record declared in the ENUM DNS: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "" "" "!^.*([0-9]{11})$!\\1.enum2.net!". By using sip_match function, the enum_query (ie do_query) function discards the NAPTR record without ‘u’ flag. I removed the check on the flag (comment sip_match function) so the NAPTR record is not discarded. But instead of looking for the terminal NATR record, enum_query function overwrites the Request URI with the non-terminal NAPTR record. Is the handling of non terminal NAPTR fixed in a new version of enum module ? If not, is it planned ? Thanks in advance for your help. Best regards, Jérôme -- View this message in context: http://www.nabble.com/Does-enum_query-support-wildcard-and-non-terminal-NAP… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

15 years, 12 months

[Kamailio-Users] simultaneus calls limitations

by BERGANZ François

Hello all, How can I contrôle « simultaneus calls limitation I could try to add in the database the number off simultaneous calls per user and when I check invite+1 cancel-1 bye-1 busy-1 BUT I have to insert in the database for each calls the call-id to know which user to do +1 or -1 Have you another idea? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

15 years, 12 months

[Kamailio-Users] How to add Retry-After header in 503 response

by Alex Hermann

Hello, is there a way to add a Retry-After header to a 503 response i'm sending out using t_reply? Use case: t_relay creates an internal 408 on timeout. From failure-route, i want to pass it upstream as 503 with retry-after header. Changing the reply to 503 using t_reply works, but how to add the header? The reply obviously doens't pass through any reply_route. -- Greetings, Alex Hermann

15 years, 12 months

[Kamailio-Users] Trying to deliver a call across multiple peers with t_relay

by Tyler Brauer

Good morning/afternoon/evening! I'm trying to accomplish two things. * First, I'd like to try sending a call from our B2BUA through Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this. if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } } I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA. I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio. * The second thing I'd like is that if the first two peers are unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101(a)1.1.1.1 fails, then 101(a)2.2.2.2 fails, so then 2015551234(a)3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server. Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!

15 years, 12 months

[Kamailio-Users] important: pseudo-variables moved from core to pv module

by Elena-Ramona Modroiu

Hi, all pseudo-variables exported by core in the past are now in PV module. Therefore if you use any of them in your config you have to load the PV module. This is valid with devel version (trunk). This change was discussed some time ago on devel mailing list, the core is slimmer now. Soon transformations will be moved as well, making possible to export new transformations from modules. The core will include only the API to export PV and transformations, plus the engine to use them in config file. Regards, Ramona

15 years, 12 months

[Serusers] Registering port instead of contact field port

by Daniel Serrano

Dear all, I am using SER as IM server and I found that the SER use the contact field to storage the user's location in the memory for future requests. I noted this using the command "serctl alias show" and checking some traces. Since I'm using a NAT scenario I'd like to use the UDP port that my SER server receives during the registration instead of the contact field port to reach the users after their registration. Is there any way to do this? Thanks in advanced. * Daniel Serrano D.** *

15 years, 12 months

Jump to page:

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