sr-users June 2011

sr-users@lists.kamailio.org

75 participants
114 discussions

by Omar

I need to rewrite the destination after I receive 302 I have this logic Onreply Loads in avp the information needed I try sending to failure route and to a route in both cases the $ru become <null> In the route and failureroute I did try rewritehost, rewriteuri, $ru= number+ host And append the route But $ru is always null. Inside the route or failure route If there are no 302 nor the onreply involved everything works fine Any suggestion to rewrite the ruri after a 302 is welcome I am still using Kamailo1.4.3 Omar

13 years, 4 months

Modifying sip packet

by Lucas Alvarez

Hi, I want to modify the following sip packet, I want to change the SDP IP address by $di, which rule could filter this packet? Something like: [ if method("OK") and $di is RFC1918 ] ??? And with which function could I change the Ip address in the SDP content? In this case I would like to change 172.16.99.2 by 190.244.125.41. Thanks in advance, Lucas T 172.16.99.2:5060 -> 190.244.125.41:9055 [AP] SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.99.2;branch=z9hG4bK7c5.bfc43456.0;i=1;received=172.16.99.2;rport=5060. Via: SIP/2.0/TCP 192.168.15.231:1952 ;received=190.244.125.41;branch=z9hG4bK-d8754z-be53247ec649be5b-1---d8754z-;rport=9055. Record-Route: <sip:172.16.99.2;r2=on;lr=on;ftag=b11c6a4e>. Record-Route: <sip:172.16.99.2;transport=tcp;r2=on;lr=on;ftag=b11c6a4e>. From: "Lucas"<sip:1104@67.152.18.231>;tag=b11c6a4e. To: <sip:1101@67.152.18.231>;tag=as5356a251. Call-ID: NzcwZWIxNGE1MDg5ZjVhZWRhYWNlM2RiNmMwM2M4MWM.. CSeq: 2 INVITE. Server: Asterisk PBX 1.8.4.1. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. Contact: <sip:1101@172.16.99.2:5080>. Remote-Party-ID: "Gus Office One" <sip:1101@67.152.18.231 >;party=called;privacy=off;screen=no. Content-Type: application/sdp. Content-Length: 305. . v=0. o=root 1124623741 1124623741 IN IP4 172.16.99.2. s=Asterisk PBX 1.8.4.1. c=IN IP4 172.16.99.2. t=0 0. m=audio 13640 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=ptime:20. a=sendrecv.

13 years, 4 months

Use of mtree module having multiple trees in the same table

by jose luis millan

hello, I wonder if anyone could help me understanding how can I use this module in a scenario where multiple mtrees are defined behind the same database table. I can't guess how to speficy to 'mt_match' the mtree I want to match against, since the 'mtree' module parameter defines a specific memory tree based on a specific table, but not based on a specific 'tname' value. Any help is apreciated, Thanks in advance.

13 years, 4 months

Fwd: 200OK Retransmission Error

by Jijo

Hi All, In an INVITE transaction, no ACK from A party and B party continue retransmission of 200 OK. I have observed that kamailio is not passing the retransmitted 200 OK message from B party to the Application(script) after 3 seconds. Instead kamailio directly sending to A party without passing to the script. I see in the logs that kamailio is cleaning up the transaction after 3 seconds..look for the string "DEBUG: t_lookup_request: no transaction found" before this log it is cleaning up the timer in the log "DEBUG: cleanup_uac_timers: RETR/FR timers reset" What does it mean by that?? How can we make the kamailio to pass the response to the application? Please let me know your comments.. Here is the flow. I cannot send the complete logs which is quite big. so i grep'd using the stirng "tcp_read_req: content-length|get_hdr_field|t_reply_matching|cleanup_uac_timers|RR11" from the complete log.. A kamailo B ----INVITE-->- --------------------INVITE 180 Ringing--<---------------180 Ringing 200 OK-----------<---------------200 OK 0 200 OK-----------<---------------200 OK 500ms 200 OK-----------<---------------200 OK 1s 200 OK-----------<---------------200 OK 2s < From here it is not passing to the application- script> 200 OK-----------<---------------200 OK 4s 200 OK-----------<---------------200 OK 4s 28 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [50]; uri=[ sip:5616990102@192.168.243.151:5060] 36 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 267 86:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 0 282 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 284 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 285 89:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 286 90:2011-06-13T19:47:38+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 292 96:2011-06-13T19:47:38+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:180 Reason=Ringing CT=5616990102 <sip:5616990102@192.168.243.161:5060;transport=tcp> 331 86:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 346 102:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 348 95:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 349 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 350 90:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 356 96:2011-06-13T19:47:39+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102@192.168.243.161:5060;transport=tcp> 398 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_reply.c:1467]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 406 86:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 421 102:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 423 95:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 424 89:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 425 90:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 431 96:2011-06-13T19:47:40+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102@192.168.243.161:5060;transport=tcp> 481 86:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 496 102:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 498 95:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 499 89:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 500 90:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 506 96:2011-06-13T19:47:41+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102@192.168.243.161:5060;transport=tcp> 556 86:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 571 102:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 573 95:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 574 89:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 575 90:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 581 96:2011-06-13T19:47:43+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102@192.168.243.161:5060;transport=tcp> 631 86:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 646 102:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 648 95:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 649 89:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 650 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 651 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 693 86:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 708 102:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 710 95:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 711 89:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 712 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 713 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 755 86:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 770 102:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 772 95:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 773 89:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 774 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 775 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 817 86:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 832 102:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 834 95:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 835 89:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 836 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 837 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 879 86:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 894 102:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 896 95:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 897 89:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 898 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 899 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 941 86:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 956 102:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 958 95:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 959 89:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 960 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 961 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 1003 86:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 1018 102:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 1020 95:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 1021 89:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 1022 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 1023 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction

13 years, 4 months

RTP proxy

by michel freiha

Dear All, I'm using the below config plan for routing my calls...The issue that forcing rtp proxy is not working well and the rtp proxy is never forced....Can you please provide me a guidance here? if($rU=~"^00.*" ) { if(!cr_route("default", "domain.com", "$rU", "$rU", "call_id")){ sl_send_reply("403", "Not allowed"); } else { setbflag(6); route(1); } exit; ## this was missing here -bogdan!!! } else { route(LOCATION); route(RELAY); } } ############# THIS IS THE GENERIC RELAY ROUTE THAT MUST BE USED ALL THE TIME FOR RELAY route[1] { # apply any NAT changes? if(isflagset(5)||isbflagset(6)) { route(4); } exit; } route[4] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ if (nat_uac_test("8")) { * force_rtp_proxy();* } else { force_rtp_proxy(); } xlog("L_ERR","66666666666666666666666666666666666666666"); t_on_failure("1"); t_on_reply("1"); }; The call is going through Route[1] then through Route[4], but rtp proxy is never forced...Any tips please? Regards

13 years, 4 months

Meaning of empty body in NOTIFY

by Eugen Dedu

Hi, ekiga.net registrar uses kamailio 1.5.3 (yes, a bit old...) and for users who are not registered an empty NOTIFY body is returned when asked by a SUBSCRIBE. What does this mean from SIP standard point of view, and from kamailio point of view (are they identical?) I see in RFC3265/3.1.6.2: .... If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body but is difficult for me to interpret what it means. Example: I ask the presence for a user xyz who registered and quit application long time ago: SUBSCRIBE sip:xyz@ekiga.net SIP/2.0 CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 82.238.108.175:5060;branch=z9hG4bKdabe824f-1a8e-e011-9efc-0024d693d8e8;rport User-Agent: Ekiga/3.3.1 From: <sip:eugen.dedu@ekiga.net>;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy Supported: eventlist To: <sip:xyz@ekiga.net> Accept: application/pidf+xml Accept: multipart/related Accept: application/rlmi+xml Contact: <sip:eugen.dedu@82.238.108.175:5060> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 300 Event: presence Content-Length: 0 Max-Forwards: 70 I receive the following answer: NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 CSeq: 1 NOTIFY Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK2a99.b8a72c47.0 User-Agent: Kamailio (1.5.3-notls (i386/linux)) From: sip:xyz@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-10a0 Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy To: sip:eugen.dedu@ekiga.net;tag=4888824f-1a8e-e011-9efc-0024d693d8e8 Contact: <sip:86.64.162.35:5060> Subscription-State: active;expires=370 Event: presence Content-Length: 0 Max-Forwards: 70 To resume: What does SIP standard say about this NOTIFY with empty body? Does this mean that the user xyz is offline? Or does this mean that user's status has not changed? In fact, the NOTIFY with empty body (as shown above) is the first one sent by kamailio, so there is no "previous" state of that user, hence "unchanged" status has no meaning. Thank you, -- Eugen

13 years, 4 months

Proxy Address

by michel freiha

Dear All, I'm using kamailio as Proxy server for registration with RTP proxy as relay server for voice packets...I have an issue that when sending an Invite, the audio address in SDP (o header)is not RTP Proxy address while if I send another Invite to kamailio (second Invite), the RTP Proxy address will be present in SDP sent back by Kamailio... Anyone has a clue about what could be that matter? Regards

13 years, 4 months

Double tuple in notify

by Eugen Dedu

Hi again, > Then it is the time for Eugen to add it in his sip client and send > the patch for enhancing kamailio's presence server with rfc4481, as > well :o) I start my application, and make my own status be shown. I change my status back and forth a few times between Away and DoNotDisturb (each time a publish is sent), the status returned (in notify) is good. When I change my status to Online/Available (and only to this), kamailio returns a double tuple. Is it normal to have a double tuple? If yes, which one to choose (the one with latest timestamp)? Here it is: NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 CSeq: 7 NOTIFY Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK7634.4d863c14.0 User-Agent: Kamailio (1.5.3-notls (i386/linux)) From: sip:eugen.dedu@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-29fc Call-ID: 8a0d723b-0f8d-e011-84d7-0024d693d8e8@snoopy To: sip:eugen.dedu@ekiga.net;tag=7c75723b-0f8d-e011-84d7-0024d693d8e8 Contact: <sip:86.64.162.35:5060> Subscription-State: active;expires=270 Event: presence Content-Length: 938 Content-Type: application/pidf+xml Max-Forwards: 70 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns: rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="pres:eugen.dedu@ekiga.net"> <tuple id="T00000002"> <status> <basic>open</basic> </status> <contact priority="1">sip:eugen.dedu@ekiga.net</contact> <note>online - </note> <timestamp>2011-06-04T13:55:56+02:00+02:00</timestamp> </tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="T00000001"> <status> <basic>open</basic> </status> <contact priority="1">sip:eugen.dedu@ekiga.net</contact> <note>away - jjk</note> <timestamp>2011-06-04T13:54:37+02:00+02:00</timestamp> </tuple> <dm:person xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" id="pid1"> <rpid:activities> <rpid:away/> </rpid:activities> </dm:person> </presence> -- Eugen

13 years, 4 months

Re: [SR-Users] Meaning of empty body in NOTIFY

by Daniel-Constantin Mierla

On 6/10/11 10:07 PM, Craig Southeren wrote: > On 10/06/2011 1:01 PM, Daniel-Constantin Mierla wrote:..deleted >>> >>> So, if a client uploads a presence document that contains a >>> <timed-status> element, that element could be sent by the PA when >>> the client goes offline, rather than the entire document being >>> discarded (which is what I suspect is happening now). >> >> we don't have this rfc implemented in kamailio at this time. Is any >> UA you know doing this kind of thing? > > No Then it is the time for Eugen to add it in his sip client and send the patch for enhancing kamailio's presence server with rfc4481, as well ;-) Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

13 years, 5 months

Functions for DNS

by Nathan Angelacos

I'm looking to build a set of contacts with q values based on SRV records for serial/parallel forking. I want "enum_query" (loading the contact set with a q value based on the order,preference of the NAPTR record) but the ruri is not an e.164 number, and SRV records are used instead. Think in terms of "find all peer proxies based on SRV lookup, and sort them for use with t_load_contacts()/t_next_contacts()." So far I haven't found any api that exposes the DNS lookups in sip-router. Before rolling something custom with Lua, am I missing something that's already documented? Or are there plans to make such a module? Sure don't want to re-invent the wheel. tia

13 years, 5 months

← Newer
1
...
6
7
8
9
10
11
12
Older →

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 June 2011