sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

RTP proxy
by michel freiha 14 Jun '11

14 Jun '11

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

2 1

Meaning of empty body in NOTIFY
by Eugen Dedu 13 Jun '11

13 Jun '11

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

6 21

Proxy Address
by michel freiha 13 Jun '11

13 Jun '11

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

2 2

Double tuple in notify
by Eugen Dedu 12 Jun '11

12 Jun '11

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

3 2

Re: [SR-Users] Meaning of empty body in NOTIFY
by Daniel-Constantin Mierla 10 Jun '11

10 Jun '11

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

2 1

Functions for DNS
by Nathan Angelacos 10 Jun '11

10 Jun '11

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

2 2

New developer: Peter Dunkley
by Daniel-Constantin Mierla 09 Jun '11

09 Jun '11

Hello, just to let everyone to know that starting with today Peter got developer access to GIT repository. He sent many patches in the past months to fix issues or add new features to presence modules (e.g., OMA extensions to embedded XCAP server) -- some are pending to be committed and expect more to come, as he is continuing to work with this part of SIP server. The user id is 'pd'. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

Re: [SR-Users] Best way to handle OPTIONS message with Max-Forwards of 0
by Sean O'Donnell 09 Jun '11

09 Jun '11

Looks more comprehensive than mine. Thanks! Sean O'Donnell ---- On Wed, 8 Jun 2011, Klaus Darilion (klaus.mailinglists(a)pernau.at) wrote: Anyway - not standard conform but efficient (put somewhere in the beginning) force_rport(); if (is_method("OPTIONS")) { sl_send_reply("200","OK"); exit; } # sipura/linksys keepalive if (is_method("NOTIFY")) { if ( search("^Event: keep-alive") ) { sl_send_reply("200","Keep Alive"); exit; } } # ignore requests generated by sipvicious # User-Agent: friendly-scanner if ($ua == "friendly-scanner") { exit; } regards Klaus Am 08.06.2011 18:28, schrieb Sean O'Donnell: > Hi: > > We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our > service providers > has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. > > Looking at RFC 3261 section 11, this seems to be a valid method of forcing the > proxy to respond to the OPTIONS. > However, the standard initial sanity checks in most proxy configs will reject > this message. I fixed our script > by changing to this: > > # initial sanity checks -- messages with > # max_forwards==0, or excessively long requests > if (!mf_process_maxfwd_header("10")) { > if( method != "OPTIONS" ) { > sl_send_reply("483","Too Many Hops"); > return; > }; > }; > if ( msg:len > max_len ) { > sl_send_reply("513", "Message too big"); > return; > }; > > but does anyone have a better solution? > > Thanks, > > Sean O'Donnell > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

1 0

Re: [SR-Users] Best way to handle OPTIONS message with Max-Forwards of 0
by Sean O'Donnell 08 Jun '11

08 Jun '11

Thanks for the reply. In our case, the SBC treated the 483 as an error of some sort and wouldn't send traffic. It wanted a 200/OK. Anyway, I thought that when a proxy responds to an OPTIONS, its supposed to answer with a 200/OK (3261 11.2). Is that correct? Sean O'Donnell ---- On Wed, 8 Jun 2011, Klaus Darilion (klaus.mailinglists(a)pernau.at) wrote: What is the problem with the default config? The proxy will respond with 483 as the standard defines. I guess the SBC will doe this to check if the proxy is alive and will accept any response as "the proxy is alive". regards Klaus Am 08.06.2011 18:28, schrieb Sean O'Donnell: > Hi: > > We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our > service providers > has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. > > Looking at RFC 3261 section 11, this seems to be a valid method of forcing the > proxy to respond to the OPTIONS. > However, the standard initial sanity checks in most proxy configs will reject > this message. I fixed our script > by changing to this: > > # initial sanity checks -- messages with > # max_forwards==0, or excessively long requests > if (!mf_process_maxfwd_header("10")) { > if( method != "OPTIONS" ) { > sl_send_reply("483","Too Many Hops"); > return; > }; > }; > if ( msg:len > max_len ) { > sl_send_reply("513", "Message too big"); > return; > }; > > but does anyone have a better solution? > > Thanks, > > Sean O'Donnell > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Best way to handle OPTIONS message with Max-Forwards of 0
by Sean O'Donnell 08 Jun '11

08 Jun '11

Hi: We're running kamailio 1.5.5 as part of our VoIP infrastructure. One of our service providers has an SBC that sends an OPTIONS messages with a Max-Forwards of 0. Looking at RFC 3261 section 11, this seems to be a valid method of forcing the proxy to respond to the OPTIONS. However, the standard initial sanity checks in most proxy configs will reject this message. I fixed our script by changing to this: # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { if( method != "OPTIONS" ) { sl_send_reply("483","Too Many Hops"); return; }; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); return; }; but does anyone have a better solution? Thanks, Sean O'Donnell

2 2

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