sr-dev August 2012

sr-dev@lists.kamailio.org

30 participants
170 discussions

Problem with migrating module
by Carlos Ruiz Díaz 10 Aug '12

10 Aug '12

Hello guys, I wrote a module for credit control which aims to tear a call down when client's credit is over. The problem is that I started writing it when Kam 3.3 was not out yet, and today, when I tried to use it with the latest stable release, I found out that it wasn't working because, somehow, the header fields are displaced. Considering this code: *LM_ALERT("Message CID: %.*s", msg->callid->body.len, msg->callid->body.s);* when I try to read the Call ID hdr field in *3.2* I get the right reading: ALERT: cnxcc [cnxcc_mod.c:807]: Message CID: * vqsxmovczhwztpa(a)carlosrdcnx-laptop.site* * * but if I do the same on *3.3*, with the same code (and recompiled for 3.3 of course) I get the Via hdr field. ALERT: cnxcc [cnxcc_mod.c:807]: Message CID: *SIP/2.0/UDP 127.0.0.1:5062 ;rport;branch=z9hG4bKnoyvhhjv* It's the same for Kam 3.4-dev. What am I doing wrong? Regards. Carlos.

1 0

Adding support for Kamailio adding Path header
by Iñaki Baz Castillo 10 Aug '12

10 Aug '12

Hi, AFAIK kamailio does not add Path header for a REGISTER that is routed to another server. Adding it should be straightforward: There is no need for a new script function. Instead use the existing loose_route() function, but: If the request method is REGISTER then add Path header(s) instead of Record-Route header(s), which the exact SAME value (this includes Outbound flow token and ;ob param, when implemented). No more. Cheers. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2 4

git:3.2: rr(k): fixed offset in building new route header
by Daniel-Constantin Mierla 09 Aug '12

09 Aug '12

Module: sip-router Branch: 3.2 Commit: 72b568cf530446afa26677ee37bf201a6bd6880e URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=72b568c… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Aug 9 08:50:20 2012 +0200 rr(k): fixed offset in building new route header - related to the previous fix done to strict routing intermediary hop (cherry picked from commit e154b2fb9f02d56d9c6a4b2d285791151ae0c8a3) (cherry picked from commit 8db3e9c29b2cf1ff5c6f93411d3e9a90f7eb82ef) --- modules_k/rr/loose.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/rr/loose.c b/modules_k/rr/loose.c index 0dee913..16cab74 100644 --- a/modules_k/rr/loose.c +++ b/modules_k/rr/loose.c @@ -319,7 +319,7 @@ static inline int save_ruri(struct sip_msg* _m) memcpy(s, RR_ROUTE_PREFIX, RR_ROUTE_PREFIX_LEN); memcpy(s + RR_ROUTE_PREFIX_LEN, _m->first_line.u.request.uri.s, _m->first_line.u.request.uri.len); - memcpy(s + ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, + memcpy(s + RR_ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, ROUTE_SUFFIX, ROUTE_SUFFIX_LEN); LM_DBG("New header: '%.*s'\n", len, ZSW(s));

1 0

git:3.3: rr(k): fixed offset in building new route header
by Daniel-Constantin Mierla 09 Aug '12

09 Aug '12

Module: sip-router Branch: 3.3 Commit: 8db3e9c29b2cf1ff5c6f93411d3e9a90f7eb82ef URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8db3e9c… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Aug 9 08:50:20 2012 +0200 rr(k): fixed offset in building new route header - related to the previous fix done to strict routing intermediary hop (cherry picked from commit e154b2fb9f02d56d9c6a4b2d285791151ae0c8a3) --- modules_k/rr/loose.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/rr/loose.c b/modules_k/rr/loose.c index 22360df..f5d869f 100644 --- a/modules_k/rr/loose.c +++ b/modules_k/rr/loose.c @@ -322,7 +322,7 @@ static inline int save_ruri(struct sip_msg* _m) memcpy(s, RR_ROUTE_PREFIX, RR_ROUTE_PREFIX_LEN); memcpy(s + RR_ROUTE_PREFIX_LEN, _m->first_line.u.request.uri.s, _m->first_line.u.request.uri.len); - memcpy(s + ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, + memcpy(s + RR_ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, ROUTE_SUFFIX, ROUTE_SUFFIX_LEN); LM_DBG("New header: '%.*s'\n", len, ZSW(s));

1 0

git:master: usrloc(k): safety check for raw_query
by Daniel-Constantin Mierla 09 Aug '12

09 Aug '12

Module: sip-router Branch: master Commit: f61295a91bb92645ea46dea5f6101232afeb720d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f61295a… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Aug 9 16:14:43 2012 +0200 usrloc(k): safety check for raw_query - db get all contacts functions requires raw_query, but not all db modules implement it --- modules_k/usrloc/dlist.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/modules_k/usrloc/dlist.c b/modules_k/usrloc/dlist.c index c6c4c8e..2f55ce7 100644 --- a/modules_k/usrloc/dlist.c +++ b/modules_k/usrloc/dlist.c @@ -114,6 +114,11 @@ static inline int get_all_db_ucontacts(void *buf, int len, unsigned int flags, void *cp; int shortage, needed; + if(ul_dbf.raw_query==NULL) { + LM_WARN("DB raw query support is required, but not implemented\n"); + return -1; + } + cp = buf; shortage = 0; /* Reserve space for terminating 0000 */

1 0

git:master: rr(k): fixed offset in building new route header
by Daniel-Constantin Mierla 09 Aug '12

09 Aug '12

Module: sip-router Branch: master Commit: e154b2fb9f02d56d9c6a4b2d285791151ae0c8a3 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e154b2f… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Aug 9 08:50:20 2012 +0200 rr(k): fixed offset in building new route header - related to the previous fix done to strict routing intermediary hop --- modules_k/rr/loose.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/rr/loose.c b/modules_k/rr/loose.c index 22360df..f5d869f 100644 --- a/modules_k/rr/loose.c +++ b/modules_k/rr/loose.c @@ -322,7 +322,7 @@ static inline int save_ruri(struct sip_msg* _m) memcpy(s, RR_ROUTE_PREFIX, RR_ROUTE_PREFIX_LEN); memcpy(s + RR_ROUTE_PREFIX_LEN, _m->first_line.u.request.uri.s, _m->first_line.u.request.uri.len); - memcpy(s + ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, + memcpy(s + RR_ROUTE_PREFIX_LEN + _m->first_line.u.request.uri.len, ROUTE_SUFFIX, ROUTE_SUFFIX_LEN); LM_DBG("New header: '%.*s'\n", len, ZSW(s));

1 0

git:master: pkg/deb wrap and sort debian control
by Jon Bonilla 08 Aug '12

08 Aug '12

Module: sip-router Branch: master Commit: 94534adda00e8c47a45f01ba824b9bd238293274 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=94534ad… Author: Jon Bonilla <manwe(a)aholab.ehu.es> Committer: Jon Bonilla <manwe(a)aholab.ehu.es> Date: Thu Aug 9 00:20:57 2012 +0200 pkg/deb wrap and sort debian control This makes it easier to track the dependency changes for version control systems and diff logs Credits to Michael Prokop mprokop(a)sipwise.com --- pkg/kamailio/deb/debian/control | 187 ++++++++++++++++++++++++++-------- pkg/kamailio/deb/lenny/control | 196 +++++++++++++++++++++++------------- pkg/kamailio/deb/lucid/control | 191 +++++++++++++++++++++++----------- pkg/kamailio/deb/precise/control | 191 ++++++++++++++++++++++++++--------- pkg/kamailio/deb/squeeze/control | 209 ++++++++++++++++++++++++-------------- pkg/kamailio/deb/wheezy/control | 195 +++++++++++++++++++++++++---------- 6 files changed, 819 insertions(+), 350 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=945…

1 0

Log from outbound chat today
by Olle E. Johansson 08 Aug '12

08 Aug '12

Friends, I just wanted to mail out the chat log from todays chat about SIP Outbound in Kamailio. We discussed how outbound affects Kamailio today and how it may work in various modes: - Kamailio as an edge proxy - Kamailio as a registrar/location server behind edge proxys - Kamailio as a standalone proxy/registrar We discussed both cases where client does support outbound and where the client does not support it and found that implementing SIP outbound can help both use cases. This is for documentation, copied from my chat client as raw text. A bit messy, but it's all there. /O [1:33pm]oej: My presentation is http://www.slideshare.net/oej/sip2012-outbound [1:33pm]ibc: (phone) [1:33pm]oej: Ok ibc [1:33pm]pdunkley: Thanks oej [1:34pm]oej: Was about to publish it soon anyway as part of SIP2012 [1:34pm]oej: You just put some extra pressure on me to go ahead [1:35pm]shaheryarkh: nice presentation [1:35pm]oej: At this point I'm not aware of any SIP clients that support Outbound [1:35pm]oej: thanks [1:36pm]oej: libre has partial support, haven't checked with Alfred if he completed it [1:37pm]oej: I am pretty sure that ibc has something somewhere since he developed support for it in OverSIp. [1:37pm]oej: To do this in Asterisk, I would have to start with UUID creation [1:37pm]ibc: I'm back [1:38pm]oej: so ibc, do you know any clients with Outbound support - ws or no ws? [1:39pm]ibc: about clients supporting Outbound: by my experience we DONT need clients supporting Outbound in order to make it to work. All the SIP TCP clients "assume" that they will receive incoming request throght the connection of the registration, even if that is anti-RFC 3261, so it's just like adding a function force_outbound() in kamailio [1:39pm]oej: Right. So implementing outbound will make life easier for TCP clients behind NAt, regardless [1:39pm]oej: But for "true" outbound with the failover, we need two registrations to separate servers [1:40pm]ibc: well, JsSIP does support outbound, but supporting Outbound (in a client) is just about advertising it in the Supported header and being able to receive request throught and outbound connection (registration) [1:40pm]oej: And registering at least two times [1:40pm]oej: That's a requirement in the RFC [1:40pm]ibc: yes, for the +sip.instance and reg-id stuff, we do need Outbound aware clients [1:41pm]oej: So I guess we need to create a client or several. I'll check with Alfred. [1:41pm]ibc: I would like to divide Outbound stuff in two parts: [1:42pm]ibc: 1) the stuf made by the proxy (or EDGE proxy) by adding a Outbound flow token in RR or Path [1:42pm]ibc: 2) the sip.instance and reg-id stuf for clean re-registration, proper device's binding update and Outbound failover [1:43pm]oej: So edgeproxy processing (flow token and path) and registrar/location server handling (contact storage, destination set, forking) [1:43pm]oej: Ok. So let's start with edgeproxy stuff [1:43pm]oej: That should be quite simple. [1:43pm]ibc: ok [1:43pm]ibc: that's not so simple :) [1:43pm]oej: Explain then :-) [1:44pm]ibc: lot of complexity in how to add and inspect the flow token in the RR / Route header [1:44pm]ibc: ok, please check this: [1:44pm]ibc: https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/modules/co… [1:44pm]ibc: it's a bit documented [1:44pm]ibc: line 57: [1:45pm]ibc: # Outgoing initial request asking for Outbound. Just valid when: [1:45pm]ibc: # - It's an initial request. [1:45pm]ibc: # - Single Via (so there is no a proxy in front of us). [1:45pm]ibc: # - It's an INVITE, REGISTER, SUBSCRIBE or REFER request. [1:45pm]ibc: # - Has a preloaded top Route with ;ob param pointing to us, or has Contact with ;ob, or [1:45pm]ibc: # it's a REGISTER with ;+sip.instance. [1:45pm]oej: Is "Outgoing" from the core to the device in this case? [1:46pm]ibc: no, it means a request received by the proxy [1:46pm]oej: To start from the beginning [1:46pm]oej: 1) Client opens connection (for connection oriented transports) [1:46pm]ibc: if those requirements are not satisfied, then outbound should not be applied because we could break things [1:46pm]ibc: ok [1:46pm]oej: 2) Client sends REGISTER [1:46pm]oej: 3) Edge proxy creates flow token [1:47pm]oej: Then? [1:47pm]ibc: yes but: [1:47pm]ibc: in step 3) the proxy MUST decide whether to create a token or not [1:47pm]ibc: so apply outbound or not (based on requirements above) [1:47pm]oej: Yep. The client indicates support for outbound [1:47pm]ibc: or force_outbound() is called [1:48pm]oej: 4) Edge proxy adds Record-route and Path headers with flow token (?) [1:48pm]ibc: then the proxy creates a flow token and adds (in my case) two RR or Path, and adds the flow token as the RURI username of the top RR/Path [1:48pm]ibc: and *also* adds ;ob param to the top RR/Path [1:49pm]oej: For REGISTER, there's no RR? So PATH [1:49pm]ibc: yes, but exactly SAME value [1:49pm]ibc: or values [1:49pm]oej: agree [1:49pm]oej: then forward to location server [1:49pm]ibc: please let me re-check in which RR/path (top or second) must the token and ;ob be added [1:49pm]oej: Which will receive at least two register requests with different flow tokens [1:49pm]oej: and different paths [1:50pm]oej: So in Kamailio this will affect RR and Path modules so far. [1:50pm]oej: Anything else? [1:50pm]ibc: yes, the token and ;ob must be added in the top RR/Path as said above [1:50pm]oej: (we're not at the location server yet, forget that part) [1:51pm]ibc: yes, this is just about the EDGE proxy which is GRUU or +sip.instance/reg-id unaware [1:51pm]ibc: the REGISTER is routed to the registrar [1:51pm]oej: This is just for the incoming FIRST request after connection setup [1:51pm]ibc: the registar stores the Path headers [1:51pm]oej: In order for us to support the handling of that request, so far I see changes to RR and path modules - anyone else have other thoughts? [1:51pm]oej: pdunkley? [1:51pm]ibc: I see no other way [1:52pm]oej: miconda? [1:52pm]ibc: by the way, adding the flow token *always* should not break nothing [1:52pm]pdunkley: Sorry, I am doing three different things at once here. I will need to re-read this later and catch up. [1:52pm]oej: ;-) [1:53pm]oej: We're at the edge proxy, trying to sort things out. [1:53pm]oej: Ok, moving on to the registrar [1:53pm]oej: We save the contact, the path header as always [1:53pm]ibc: Outbound (in the EDGE proxy) is just about ading stuf to RR/Path, and the UAS is mandated to mirror those values as per RFC 3261, so we break nothing by always adding that stuf [1:53pm]oej: I think the usrloc module now save the instance id [1:54pm]ibc: and the Path URI's [1:54pm]oej: we already do path URI's [1:54pm]ibc: so a request arrives to the registrar for that AOR [1:54pm]oej: Do we need to respond differently to a register? [1:54pm]ibc: no (unless GRUU is required/supported) [1:54pm]oej: Or is it just a normal register, binding a contact with some properties to an AOR [1:55pm]ibc: normal, but if the registrar supports Outbound and the REGISTER asks for Outbound, then the registrar must store the sip.instance and reg-id [1:55pm]ibc: and "forget" the CSeq and Call-ID of the REGISTER [1:55pm]ibc: so a request arrives to the registrar for that AOR, then: [1:56pm]ibc: the registrar does lookup() [1:56pm]ibc: and for each binding with *same* sip.instance retrieves just *one* [1:56pm]ibc: (the one with best reg-id I hope) [1:56pm]ibc: also retrieves the Path URI's and adds them as Route headers [1:57pm]ibc: the top Route points to the EDGE proxy so routes the request to it [1:57pm]oej: But here's where we need to discuss the destination set in kamailio. [1:57pm]oej: If you suggest that the lookup function should only return ONE contact for one instance-id (one device) then how do we handle failover? [1:57pm]ibc: it should be the top Route (unless we manually modify it) [1:57pm]ibc: ok, let me explain: [1:58pm]oej: We branch with t_relay and the message fails in the edge proxy? Will the edge proxy return a specific code? How do we find the next contact? [1:58pm]ibc: yes, let me ;) [1:58pm]ibc: the registrar gets the binding with reg-id=1. The top Route points to the EDGE proxy so routes the request to it [1:59pm]ibc: the EDGE proxy receives the request and inspects the Routes [1:59pm]ibc: the top Route points to the EDGE proxy so it's removed [1:59pm]ibc: the second Route also points to it but it ALSO contains a ;ob param [1:59pm]ibc: so the Route is removed and the Route RURI username retrieved (which is the flow token) [2:00pm]ibc: the EDGE proxy gets the connection associated to that flow token and routes the request over it (by also adding RR and so on, of course) [2:00pm]ibc: now let's imagine that the connection is closed (reg-id=1) [2:00pm]ibc: the EGDE proxy knows that so replies 430 Flow Token [2:01pm]ibc: the registrar reveices the 430, deletes the selected binding for this transactions and gets the next one (reg-id=2) and tries again [2:01pm]ibc: the second binding (reg-id=2) could have been arrived to the registrar from a different EDGE proxy [2:02pm]ibc: (that's the philosofy of Outbound failover in fact) [2:02pm]oej: exactly [2:03pm]oej: In Kamailio, this stuff is handled in the routing script [2:03pm]ibc: there is more stuff when the EDGE proxy adds RR header(s) for a dialog in which Outbound was used, but it's not so hard [2:03pm]oej: So we need a funciton that we can call if we get 430 to check if there's an alternate path to the same instance id [2:03pm]ibc: I mean: for an in-dialog request [2:03pm]ibc: right [2:03pm]oej: lookup_outbound [2:03pm]ibc: or also if we get 408/503 from the EDGE proxy (down) [2:04pm]pdunkley: Is another function required, or can the existing lookup be used? [2:04pm]oej: We only use lookup once normally [2:04pm]pdunkley: Perhaps lookup() should return the best reg_id available, and then have another function to remove a binding. [2:04pm]oej: this needs to re-lookup and reset the r-uri [2:04pm]ibc: I think it should be intregatted within lookup() since in the first attemp the registrar has no way to know which one to use [2:04pm]ibc: and also the Route headers [2:04pm]pdunkley: Then calling lookup again (from the failure_route[] that handles the 430) should do the right thing? [2:05pm]ibc: (mirrored from the received Path headers but in reverse order) [2:05pm]oej: So we have a request route, use t_relay and end up in branch route and maybe in response route and failure route [2:05pm]oej: Using Lookup again would break the syntax, I think that's bad [2:05pm]ibc: yes, but we also need that, upon a 430, kamailio *removes* the failing binding [2:05pm]oej: This is like dispatcher failover. [2:05pm]oej: Dispatcher adds all possible targets in an avp and sends to the first one [2:06pm]oej: Then in failure route I can select next and resend [2:06pm]oej: I tihnk we should have something similar [2:06pm]ibc: ok, makes sense. Perhaps we need a transaction flag that is activated when it belongs to an Outbound registration [2:06pm]oej: branch flag too [2:06pm]oej: to mark this branch as one that has possible candidates for failover [2:07pm]oej: So a new function should [2:07pm]oej: 1) Remove binding to failed flow [2:07pm]ibc: so: if reply==430 && isbflagset(OUTBOUND_BINDING) then: outbound_next_lookup() [2:07pm]pdunkley: So have lookup functions that populate/use AVPs stored in the transaction, plus another function to remove a binding from the location table? [2:07pm]oej: 2) Reset branch route and r-uri [2:07pm]ibc: not in the transaction but in the branch [2:08pm]oej: One transaction could be targeted to two AORs with two devices each, ending up in many branches with different instance IDs [2:08pm]oej: But each branch is only targeted towards one instance [2:08pm]oej: with multiple reg-ids - which each have a contact, path set (including flow token) [2:08pm]ibc: right [2:09pm]ibc: and remember that Contact URI is useless when using Outbound [2:09pm]oej: Absolutely. It's the flow token that relates to a UDP or TCP/TLS flow [2:09pm]oej: or ws STCP [2:10pm]ibc: the EDGE proxy does NOT route an initial or in-dialog request based on the RURI if it indicates Outbound request in the Route or Contact header [2:10pm]ibc: that's also true: Outbound is ALSO valid for UDP, but in that case the flow token must be decoded to the IP:port [2:10pm]oej: If the indicated flow-token does not relate to an active flow, it should fail directly without even trying [2:11pm]ibc: 430 [2:11pm]oej: So right, don't parse the r-uri and try to reach the client unless the client has an active flow towards you. [2:11pm]ibc: yes [2:11pm]oej: This will affect forwarding - stateful and stateless - in the edge proxy [2:12pm]ibc: and: if the EDGE proxy can detect that the flow token has not been generated by it, then it can reply 403 Forbidden [2:12pm]ibc: Next, whether the Route header field contained an "ob" URI parameter [2:12pm]ibc: or not, the proxy removes the Route header field value and forwards [2:12pm]ibc: the request over the 'logical flow' identified by the flow token, [2:12pm]ibc: that is known to deliver data to the specific target UA instance. If [2:12pm]ibc: the flow token has been tampered with, the proxy SHOULD send a 403 [2:12pm]ibc: (Forbidden) response. If the flow no longer exists, the proxy SHOULD [2:12pm]ibc: send a 430 (Flow Failed) response to the request. [2:12pm]ibc: in http://tools.ietf.org/html/rfc5626#section-5.3.1 [2:12pm]pdunkley: I think this means that a outbound_route() function that is a bit like the loose_route() function (in terms of setting $du) is required. [2:12pm]bulkorok left the chat room. (Quit: gone with the wind...) [2:13pm]pdunkley: If outbound_route() returns -1 then a 430 can be generated from Kamailio configuration? [2:13pm]ibc: yes [2:14pm]ibc: but, before calling to outbound_route() we need to check that we should do outbound [2:14pm]ibc: so: is_outbound_requested() [2:14pm]pdunkley: Then say, if it returns 1 then it means either outbound is not being used (and Kamailio core/loose_route() can work out $du), and if it returns 2 then it means outbound is used and $du is set. A bit like the multiple returns from loose_route(). [2:14pm]oej: Or just a pseudovariable with a name that no one remembers? ;-) [2:14pm]ibc: and that should do soemthing like: https://github.com/versatica/OverSIP/blob/master/lib/oversip/sip/modules/co… [2:15pm]ibc: $or = outbound_requested XD [2:15pm]oej: Sounds like a plan [2:15pm]ibc: we should also consider the case in which there is no EDGE proxy but just a single proxy/registrar [2:16pm]oej: How does outbound apply then? [2:16pm]ibc: it should also add outbound stuff and so, but here is no Path in the register so "something" (the flow token?) should also be stored in the location table [2:16pm]ibc: let's paint the use case: [2:16pm]ibc: REGISTER from the client to the single Kamailio [2:17pm]oej: You mean being able to re-use the connection anyway? [2:17pm]oej: Makes sense [2:17pm]ibc: Kamailio assigns a flow token for the connection and stores it within the binding [2:17pm]ibc: the client sends an INVITE [2:17pm]oej: I don't know how kamailio handles TCP connections today really [2:17pm]oej: Do we reuse them at all? [2:17pm]pdunkley: Only if you use the aliasing stuff :-) [2:17pm]ibc: kamailio adds two RR: the first one with the connection flow token, the top one without it, and routes the request [2:18pm]oej: I know we can keep them open, but I can't check if there's a connexction open to client y [2:18pm]ibc: aliasing stuf is a pain [2:18pm]pdunkley: If you call handle_ruri_alias() it sets $du to the address and port of the other end of the connection. If $du exactly matches a connection it is reused. [2:18pm]ibc: and a risk. There could be 100 UAs registering the same 1.1.1.1 private address in the Contact [2:19pm]pdunkley: Yes, but that is what Kamailio currently does for TCP and TLS reuse - just answering oej's question. [2:19pm]ibc: sure [2:19pm]ibc: anyhow I would like to clarify that: [2:19pm]oej: At some point we need better connection management, also for TLS [2:19pm]ibc: current aliasing stuf is anti RFC 3261 (but it works) [2:19pm]oej: ;-) [2:19pm]pdunkley: As long as - by using flow tokens etc - we can get the far end address and port into $du the connection will be reused. [2:20pm]ibc: if we replace aliasing with outbound, we are better [2:20pm]ibc: and if we force Outbound when the client does not request it (old devices) we are not worse than applying aliasing [2:20pm]pdunkley: In fact, the WS implementation is dependent on the fact that with the right stuff in $du connections are reused. [2:20pm]oej: Hmm. That alias handling may totally break TLS security unless there's a cert check involved [2:21pm]ibc: sure [2:21pm]pdunkley: Once Outbound is forced it'll be better - but at the moment it is what we have :-( [2:21pm]oej: That's life, as long as we agree on the current state and move forward ;-) [2:21pm]ibc: yes, but what I mean is that aliasing could be fully replaced by outbound and it would break nothing [2:21pm]pdunkley: That would be good. [2:21pm]ibc: (sorry, I must go or a while) [2:22pm]oej: I have a meeting coming up as well. Good chat. Peter - do you have enough input for a first stab at outbound? [2:22pm]ibc: I'll be latter (at ~15:30) [2:22pm]ibc: is this chat available in some web? [2:22pm]ibc: I want to twit it XD [2:23pm]oej: Have no idea if it's logged anywhere. [2:23pm]pdunkley: I need to re-read all of this, and the specification, and your presentation... Then I'll have a think about it and post something to sr-dev. [2:23pm]pdunkley: It would be good if this was logged [2:23pm]oej: Let's continue on sr-dev :-) [2:23pm]shaheryarkh: good stuff [2:23pm]shaheryarkh: really informative [2:23pm]shaheryarkh: thanks everyone [2:23pm]oej: I agree to taking a copy and mailing out so it ends up in the mailing list [2:23pm]oej: archives [2:24pm]oej: Do you guys agree? [2:24pm]pdunkley: Yup [2:24pm]oej: ibc asked for it, so I take it he agrees to. [2:24pm]ibc: sure ;) [2:24pm]shaheryarkh: yes [2:24pm]ibc: bye!

5 7

WebSockets and SIPCapture
by Peter Dunkley 08 Aug '12

08 Aug '12

Hi, I've just been adding WebSocket transport support to the modules that I think need updating. I believe I have got them all except modules/sipcapture. I think the update to this module should be in sipcapture.c:hep_msg_received(), but I am not sure what change to make. The way that TLS seems to be handled here is that the HEP header uses the value IPPROTO_IDP - which seems to indicate some sort of fake protocol. Previously TLS was the only fake protocol, but WebSockets (WS) and secure WebSockets (WSS) are also fake protocols (being encapsulated on TCP and TLS respectively). Is there anything simple I can do now, or does this mean the HEP protocol will need to be updated to support WebSockets? -- Peter Dunkley Technical Director Crocodile RCS Ltd

2 2

git:master: nathelper(k): use usrloc ruid and aorhash to build from tag of SIP keepalives
by Daniel-Constantin Mierla 08 Aug '12

08 Aug '12

Module: sip-router Branch: master Commit: ae8f15dcdea73156dbc704bc46908b76ba174393 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ae8f15d… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Aug 8 20:27:17 2012 +0200 nathelper(k): use usrloc ruid and aorhash to build from tag of SIP keepalives - update due to last change in usrloc get all records API function - these values can be used to identify the usrloc records (e.g., upon handling the SIP keepalive reply) --- modules_k/nathelper/nathelper.c | 10 +++++++++- modules_k/nathelper/sip_pinger.h | 16 +++++++++++----- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/modules_k/nathelper/nathelper.c b/modules_k/nathelper/nathelper.c index 4afae00..e5bfc89 100644 --- a/modules_k/nathelper/nathelper.c +++ b/modules_k/nathelper/nathelper.c @@ -1676,6 +1676,8 @@ nh_timer(unsigned int ticks, void *timer_idx) str c; str opt; str path; + str ruid; + unsigned int aorhash; struct sip_uri curi; struct hostent* he; struct socket_info* send_sock; @@ -1736,6 +1738,11 @@ nh_timer(unsigned int ticks, void *timer_idx) memcpy( &(path.len), cp, sizeof(path.len)); path.s = path.len ? ((char*)cp + sizeof(path.len)) : NULL ; cp = (char*)cp + sizeof(path.len) + path.len; + memcpy( &(ruid.len), cp, sizeof(ruid.len)); + ruid.s = ruid.len ? ((char*)cp + sizeof(ruid.len)) : NULL ; + cp = (char*)cp + sizeof(ruid.len) + ruid.len; + memcpy( &aorhash, cp, sizeof(aorhash)); + cp = (char*)cp + sizeof(aorhash); /* determin the destination */ if ( path.len && (flags&sipping_flag)!=0 ) { @@ -1782,7 +1789,8 @@ nh_timer(unsigned int ticks, void *timer_idx) dst.send_sock=send_sock; if ( (flags&sipping_flag)!=0 && - (opt.s=build_sipping( &c, send_sock, &path, &opt.len))!=0 ) { + (opt.s=build_sipping( &c, send_sock, &path, &ruid, aorhash, + &opt.len))!=0 ) { if (udp_send(&dst, opt.s, opt.len)<0){ LM_ERR("sip udp_send failed\n"); } diff --git a/modules_k/nathelper/sip_pinger.h b/modules_k/nathelper/sip_pinger.h index dac6c8a..c6098b3 100644 --- a/modules_k/nathelper/sip_pinger.h +++ b/modules_k/nathelper/sip_pinger.h @@ -117,7 +117,7 @@ error: /* build the buffer of a SIP ping request */ static inline char* build_sipping(str *curi, struct socket_info* s, str *path, - int *len_p) + str *ruid, unsigned int aorhash, int *len_p) { #define s_len(_s) (sizeof(_s)-1) static char buf[MAX_SIPPING_SIZE]; @@ -126,15 +126,16 @@ static inline char* build_sipping(str *curi, struct socket_info* s, str *path, if ( sipping_method.len + 1 + curi->len + s_len(" SIP/2.0"CRLF) + s_len("Via: SIP/2.0/UDP ") + s->address_str.len + - 1 + s->port_no_str.len + s_len(";branch=0") + + 1 + s->port_no_str.len + s_len(";branch=0") + (path->len ? (s_len(CRLF"Route: ") + path->len) : 0) + - s_len(CRLF"From: ") + sipping_from.len + s_len(";tag=") + 8 + + s_len(CRLF"From: ") + sipping_from.len + s_len(";tag=") + + sipping_from.len + 1 + 8 + 1 + 8 + s_len(CRLF"To: ") + curi->len + s_len(CRLF"Call-ID: ") + sipping_callid.len + 1 + 8 + 1 + 8 + 1 + - s->address_str.len + + s->address_str.len + s_len(CRLF"CSeq: 1 ") + sipping_method.len + s_len(CRLF"Content-Length: 0" CRLF CRLF) - > MAX_SIPPING_SIZE ) + > MAX_SIPPING_SIZE ) { LM_ERR("len exceeds %d\n",MAX_SIPPING_SIZE); return 0; @@ -157,6 +158,11 @@ static inline char* build_sipping(str *curi, struct socket_info* s, str *path, } append_str( p, sipping_from.s, sipping_from.len); append_fix( p, ";tag="); + append_str( p, ruid->s, ruid->len); + *(p++) = '-'; + len = 8; + int2reverse_hex( &p, &len, aorhash ); + *(p++) = '-'; len = 8; int2reverse_hex( &p, &len, sipping_fromtag++ ); append_fix( p, CRLF"To: ");

1 0

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev August 2012