17 Sep
2013
17 Sep
'13
4:02 p.m.
17 sep 2013 kl. 13:52 skrev Steve Davies
<steve-lists-srusers(a)connection-telecom.com>om>:
Hi Daniel, Olle,
On 16 September 2013 21:30, Daniel-Constantin Mierla <miconda(a)gmail.com> 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 like:
- forward register
- if getting 200ok, call save() for it
- if local timeout, call save in failure route -- you will have to call it via a
sub-route, because save() is only allowed in request route and reply route, although
failure_route should be safe for it
- if other reply from downstram, let it go to the phone
I've made a start with this but need a little more help.
In route block [SIPOUT], in the case of a request going to a foreign domain I added:
# we need to track the reply to the REGISTER since we need to also save locally
if ( is_method("REGISTER") ) {
t_on_reply("REGISTER_REPLY");
t_on_failure("REGISTER_FAILURE");
}
So this "captures" the reply or failure.
Then:
onreply_route[REGISTER_REPLY] {
# Got a reply to a register from upstream. Save locally if its an OK
if (t_check_status("200")) {
save("location", "0x02", "sip:$tU@local.domain.com");
append_hf("X-Runway-Trace: Runway saved registration as
$tU(a)local.domain.com\r\n")uot;);
}
}
The problem I have is that the save operates based on the content of the 200 OK reply.
So what goes into my DB for a register is like so:
id: 31
ruid: uloc-52383743-20e9-2
username: 2686959
domain: NULL
contact: sip:2686959@172.16.230.1:36574;rinstance=212220b8566c4337;transport=udp
received: sip:10.64.5.16:5060
path: NULL
expires: 2013-09-17 14:32:24
q: -1.00
callid: MDA1MzRmZDQzZmMxNzhlNWUwMGUzNmYwNGYwZTM1YTc
cseq: 2
last_modified: 2013-09-17 13:32:24
flags: 0
cflags: 0
user_agent: n/a
socket: udp:10.64.5.16:5060
methods: NULL
instance: NULL
reg_id: 0
So this is OK, but the received and socket are both wrong (they are the
"outside" interface of my proxy, where the reply came in. The registering phone
actually talks to Kamailio on the 172.16.230.128 interface).
More of a problem is what happens for an "unregister".
Here's the REGISTER as forwarded by Kamailio and the reply that comes back and is
processed in the onreply_route:
U 2013/09/17 13:22:58.004730 10.64.5.16:5060 -> x.x.x.60:5060
REGISTER sip:vc2.connection-telecom.com SIP/2.0.
Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK66a6.f18d2a5.0.
Via: SIP/2.0/UDP
172.16.230.1:50108;branch=z9hG4bK-d8754z-f3d2c8070cecc90e-1---d8754z-;rport=50108.
Max-Forwards: 16.
Contact:
<sip:2686959@172.16.230.1:50108;rinstance=36d56481f191d185;transport=udp>;expires=0.
To: "vc2 2686959"<sip:2686959@xxxx.connection-telecom.com>.
From: "vc2
2686959"<sip:2686959@xxxx.connection-telecom.com>;tag=114bde0a.
Call-ID: ZmUyY2JiOWQzMWE3OTM3YTNjNTM1OGUxOTE5Njc2ZTk.
CSeq: 4 REGISTER.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: Bria 3 release 3.5.4 stamp 70878.
Authorization: Digest
username="2686959",realm="xxxx.connection-telecom.com",nonce="52383baf2e3b9efcb10180e2ad059ff0ae7fa675",uri="sip:vc2.connection-telecom.com",response="bad296f5041c869c330f015c4dcb6351",algorithm=MD5.
Content-Length: 0.
P-hint: outbound.
.
U 2013/09/17 13:22:58.226378 x.x.x.60:5060 -> 10.64.5.16:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK66a6.f18d2a5.0;rport=5060.
Via: SIP/2.0/UDP
172.16.230.1:50108;branch=z9hG4bK-d8754z-f3d2c8070cecc90e-1---d8754z-;rport=50108.
To: "vc2
2686959"<sip:2686959@xxxx.connection-telecom.com>;tag=4bb452afea88ea368a51bf5f3eee867d.8da4.
From: "vc2
2686959"<sip:2686959@xxxx.connection-telecom.com>;tag=114bde0a.
Call-ID: ZmUyY2JiOWQzMWE3OTM3YTNjNTM1OGUxOTE5Njc2ZTk.
CSeq: 4 REGISTER.
Server: Telviva SIP proxy.
Content-Length: 0.
So the 200 OK does not have the Contact header.
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
read the response code from save().
/O
On the save Kamailio does not remove the existing registration from the location table,
so the unregister isn't effective for the local location table.
Is there a way to get the save to find the original request? Can I pull the original
request back via tm module somehow? Other ideas on getting this right?
Thanks,
Steve
_______________________________________________
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
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden