Re: [SR-Users] Using the auth_ephemeral module

Hi Daniel, On 17 January 2017 at 14:15, Daniel-Constantin Mierla wrote: > I guess you can use other modules such as http_client to interact with the > web service. The jansson module can be used to parse the result. > > Also, it should be possible to do it without interacting with the web > serv

Re: [SR-Users] Using the auth_ephemeral module

Hi Peter Dunkley or anyone else who can throw me some clue, I'm interested in using the auth_ephemeral module to authenticate registrations with the help of an external web service. But I'm reading and reading the documentation and I'm clearly missing something. The document starts by describing

Re: [SR-Users] Authentication and outbound proxy

On 17 September 2013 21:59, Olle E. Johansson wrote: > > In theory a SIP request can have multiple proxy authentications and one > www authentication. In practise very few phones support it. > Interesting that in my testing / experiments I saw Bria do this correctly. I had both Kamailio and my

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

On 17 September 2013 14:23, Daniel-Constantin Mierla wrote: > For the received field, you should call fix_nated_register() when you get > the REGISTER (not for the reply). Or build the value for received_avp ( > http://kamailio.org/docs/modules/stable/modules/registrar.html#idp84696) > manually i

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

On 17 September 2013 14:02, Olle E. Johansson wrote: > > Because the REGISTER has expires=0 on the contact, so this is a > DEREGISTRATION, > and that's why you do not see any contacts in the 200 OK. > You need to check that you have contact headers before saving based on the > 200 OK. Or possibly

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

Hi Daniel, Olle, On 16 September 2013 21:30, Daniel-Constantin Mierla wrote: > you can call save() for 200ok received from downstream. In case you deal > with nat or multiple local sockets, you need to call the functions for > fixing the registration as well as storing the local socket. > > The

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

On 16 September 2013 21:30, Daniel-Constantin Mierla wrote: > > you can call save() for 200ok received from downstream. In case you deal > with nat or multiple local sockets, you need to call the functions for > fixing the registration as well as storing the local socket. > > The processing can be

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

On 16 September 2013 19:49, Olle E. Johansson wrote: > > 16 sep 2013 kl. 19:11 skrev Steve Davies : > > Why not forward the registration from the endpoint and let them handle > authentication? > > > I need to push the registration upstream. But I also need a local > l

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

On 16 September 2013 21:03, Olle E. Johansson wrote: > I say you're making it too complex. Let the proxy be a proxy and force the > client to behave properly. > > > The client is an ordinary SIP phone. I don't have any control over its behaviour. But I'm not sure in what way it is behaving impr

Re: [SR-Users] Registering "upstream" with the uac module, but with authentication

> Why not forward the registration from the endpoint and let them handle > authentication? > I need to push the registration upstream. But I also need a local location record since I have an Asterisk on the side that also needs to send calls to the phones via the Kamailio instance. The device o

[SR-Users] Registering "upstream" with the uac module, but with authentication

),`l`.`expires`) AS `expires` from (`location` `l` join `subscriber` `s`) where (`l`.`username` = `s`.`username`) This kinda worked - but didn't quite track the registration status. Do you think this idea has promise? Maybe something similar that works using triggers rather than a straight view mi

[SR-Users] Pseudo-variables and branches

ed - by looking at $rd. But in fact I find that $rd keeps the domain from the ORIGINAL invite even if the call that just failed was the one to 127.0.0.1:5070 . So I'm obviously missing something about how pseudo-variables interact with the branching etc. Thanks, Steve

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 19:42, Daniel-Constantin Mierla wrote: > Can you try the new patch attached? > > I overlooked that the code where to skip sending the reply was in between > some #ifdef ... #else ... #endif and I did it only for the #else branch, > but actually the #ifdef was enabled by compile

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 14:56, Daniel-Constantin Mierla wrote: > I'll check the logs and most probably have to do some test myself, but > it's going to take a bit. > No prob, I'll come back to it later. Steve ___ SIP Express Router (SER) and Kamailio (Open

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 12:22, Daniel-Constantin Mierla wrote: > correction for the above line, the function name is: > > t_set_disable_internal_reply(); > I can't get the parser to agree its valid: 0(29626) DEBUG: [sr_module.c:680]: find_mod_export_record(): find_export_record: not found 0(29626

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 11:18, Steve Davies wrote: > Here's what I put in RELAY route block: > > $var(rr) = t_relay(); > > xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); > > if (!$var(rr)) { > >

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 08:13, Steve Davies wrote: > Here's all that is said about return codes from t_relay in the 4.0.x > module documentation ( > http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_relay). Looks > like there are docs that I didn't find? > >

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 07:55, Olle E. Johansson wrote: > Please read the full documentation for t_relay. There's a lot of return > codes that actually is really helpful. If it fails, read the return code > and take action accordingly. > > Yeah, I know I'm boring, but we do try to write proper referen

[SR-Users] 477 Unfortunately error on sending to next hop occurred

s not listed in the 4.0.3 documentation. Is there a way to get this to work? Thanks, Steve -- Steve Davies: Technical Director, Connection Telecom (Pty) Ltd Email is preferred, but: Phone: 0878200200 ___ SIP Express Router (SER) and Kamailio (OpenSER)

Re: [SR-Users] How to thoroughly test a proxy?

On 22 August 2013 15:13, Alex Balashov wrote: > I do not disagree with any of that, or with testing your flows end-to-end > to uncover problems. I just meant that most of your examples were not > particularly anchored, conceptually. > OK - I concede that point. Since it was really just a top-of

Re: [SR-Users] How to thoroughly test a proxy?

Hi Alex, On 22 August 2013 12:46, Alex Balashov wrote: > > On 08/22/2013 06:25 AM, Steve Davies wrote: > > Ordinary outbound and inbound calls >> Holding / unholding >> "Blind" transfers >> "Attended" transfers >> mid-call reINVIT

[SR-Users] How to thoroughly test a proxy?

Hi Kamailians, Can anyone on the list point me at a list of call flow scenarios I should consider and test to be confident my proxy setup works properly. I'm not looking at the moment for some sort of SIPit torture test, just a sensible set of scenarios. This is for my client side "outbound sip/

Re: [SR-Users] multihomed Kamailio and enable_double_rr

Hi, On 20 August 2013 23:37, Daniel-Constantin Mierla wrote: > I would use also the tags - something like: > - save for invite: > $sht(x=>$ci::$ft) = $sel(contact.uri); > - save for 200ok of invite > $sht(x=>$ci::$tt) = $sel(contact.uri); > > For bye, if uri==myself, then if $sht(x=>$ci::$tt)!=

Re: [SR-Users] multihomed Kamailio and enable_double_rr

On 20 August 2013 18:49, Daniel-Constantin Mierla wrote: > I wanted to add such logic in default config for kamailio as well (not > mangle contact if not first proxy), but forgot about it, I'll do it soon. > There is a new function is_first_hop() in devel version, for older version > the solution

Re: [SR-Users] multihomed Kamailio and enable_double_rr

On 20 August 2013 18:49, Daniel-Constantin Mierla wrote: > If you cannot control 41.221.230.60 or ask for a change there, the > solution is to use htable in your config to store the contact uri from > invite and replace it in bye before loose_route(). > Let me have a go at doing it this way. F

Re: [SR-Users] Fwd: multihomed Kamailio and enable_double_rr

On 20 August 2013 20:16, Steve Davies wrote: > Sorry I didn't write what I meant. But the point was that the OpenSIPs on > 41.221.230.60 is not doing any Contact mangling. > > > Oh . I just looked properly and I'm wrong. Kamailio sends the upstream invite with the Con

Re: [SR-Users] Fwd: multihomed Kamailio and enable_double_rr

On 20 August 2013 20:13, Alex Balashov wrote: > On 08/20/2013 02:11 PM, Steve Davies wrote: > > But I don't quite understand your suggestion that the proxy on >> 41.221.230.60 should route the INVITE per the Record-Route. The >> record-route only says what path

[SR-Users] Fwd: multihomed Kamailio and enable_double_rr

On 20 Aug 2013 18:49, "Daniel-Constantin Mierla" wrote: > the problem with the BYE is that the R-URI is the ip address of kamailio, > resulting in match for strict routing rather than loose routing (both cases > are handled by loose_route() function). > > My guess of what happens is that 41.221.

[SR-Users] multihomed Kamailio and enable_double_rr

Hi, I'm having a problem with routing of BYEs in my multi homed Kamailio. My setup is a phone on 172.16.230.1, talking to Kamailio on 172.16.230.128. On the "outside" Kamailio uses 10.64.5.16 and its talking to 41.221.230.60 I'm using the stock Kamailio 4.0.3 kamailio.cfg, with: WITH_NAT defin

Re: [SR-Users] Kamailio / rtpproxy behaviour on dual-homed box

On 16 August 2013 16:31, Alex Balashov wrote: > I think this thread may help you: > >http://lists.sip-router.org/**pipermail/sr-users/2010-** > October/065669.html > > Hi Alex, Thanks for the pointer! I see that the ka

[SR-Users] Kamailio / rtpproxy behaviour on dual-homed box

ing the RTP flows, on the eth1 (internal) side I can see a flow from 172.16.230.1 (the phone) to 172.16.230.128 (the rtpproxy), but no flow back. On the eth0 side, I see a flow out from 172.16.230.128 going to my xxx.connection-telecom.com box. Wrong source address but it does get there and can be hea