Re: [SR-Users] Hop by hop CANCEL, wrong to header

2012-05-25 Thread Vitaliy Aleksandrov 

Hello Daniel,

Thanks for the reply.

Sorry i have made a typo. If E2E_CANCEL_HOP_BY_HOP is defined then 
e2e_cancel() from t_fwd.c calls cancel_branch() function for each branch 
it found at a t_invite transaction.
Then if cfg_get(tm, tm_cfg, reparse_invite) is true cancel_branch() 
calls build_local_reparse() which returns new CANCEL request buffer 
based on outgoing INVITE, but with original To header.


I've searched a bit deeper and found that if E2E_CANCEL_HOP_BY_HOP is 
not defined e2e_cancel() calls e2e_cancel_branch(), which then calls 
build_local_reparse() like in previous description when 
E2E_CANCEL_HOP_BY_HOP was defined.


So the main question is why does kamailio take "To" field from a 
transaction cell and not from outgoing buffer like it does with other 
headers ?


I'm using kamailio-3.0.2, but i have checked 3.2.2 sources and haven't 
found any changes at the functions mentioned above.


Cheers,
Vitaliy Aleksandrov


Hello,

On 5/23/12 5:22 PM, Vitaliy Aleksandrov wrote:

Hi all,

I have a question about CANCEL message processing.

My call sceraio:
When an INVITE request comes I need to rewrite a domain part of the 
several headers(to, from, contact, SDP ip) according to the outgoing 
interface.
I can do it before t_relay(), but when destination user has more then 
one locations and they are reachable through different interfaces all 
forked INVITEs will have the same domain.
To avoid that problem i have tried to move rewriting part(subst from 
the textops module) to the branch_route.


Unfortunately that solution didn't helped me, because "To" header of 
the outgoing CANCEL messages is wrong (unchanged. as it was at the 
moment when transaction was created by the t_relay() ).
As i understood from the documentation and mailing list kamailio 
builds CANCEL based on outgoing INVITE.


I did a small research and found that Kamailio really takes outgoing 
INVITE from each branch (invite_transaction_cell -> 
uac[b_id].request.buffer) and builds CANCEL (build_local_reparse() 
from tm/t_msgbuilder.c) based on it.
But kamailio does an exception for the To header which is described 
below:
***cancel_branch* function (from t_cancel.c) calls 
*build_local_reparse*() and fills one of the parameters with a 
pointer to unmodified To header.
*build_local_reparse*() uses received To header to construct 
outgoing CANCEL.


I have changed:
cancel = build_local_reparse(t, branch, &len, CANCEL, CANCEL_LEN, 
&t->to, reason);

to:
cancel = build_local_reparse(t, branch, &len, CANCEL, CANCEL_LEN, 
NULL, reason);

and it works for me now.

It looks like if E2E_CANCEL_HOP_BY_HOP *e2e_cancel()* (t_fwd.c) will 
call *e2e_cancel_branch()* which works as i want instead of 
*cancel_branch()*, but it is just my assumption.


do you mean if E2E_CANCEL_HOP_BY_HOP is defined? I quick grep at this 
time showed it is defined in t_fwd.h...


What is the version you are using?

Cheers,
Daniel



Why does kamailio generate CANCEL requests in such a way ? Did i miss 
something from the RFC3261 or kamailio documentation ?


Thanks in advance for any help !




___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda




___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Sending MSRP message to kamailio/msrprelay causes 501 error

2012-05-25 Thread Reichert Alexander 
Hi Daniel,

Thanks a lot for your response. We will try the embedded module soon.
In the meanwhile, we found the issue which was related a mistake in the toPath 
header parameter.

Cheers,
Alex


From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: Freitag, 25. Mai 2012 00:20
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users 
Mailing List
Cc: Reichert Alexander; COURTAULT Francois
Subject: Re: [SR-Users] Sending MSRP message to kamailio/msrprelay causes 501 
error

Hello,

kamailio has an embedded msrp relay functionality. You have to load and 
configure msrp module -- it is new in upcoming release (3.3.0, planned to be 
out about mid of June):

http://kamailio.org/docs/modules/devel/modules/msrp.html

Have you tried with it as well? I developed the current version, but had no 
good clients I could test with at that time, so I used mainly network sending 
tools to simulate msrp traffic.

Cheers,
Daniel

On 5/24/12 1:27 PM, Reichert Alexander wrote:
Hi,

We are developing a Java based SIP gateway implementation and are performing 
some integration tests on a kamailio/msrprelay server (plugin from 
www.msrprelay.org).
The SIP signaling part works so far, but when sending a MSRP message, the 
client receives a 501 "Unknown method" error. However, it seems the request 
does not reach the MSRP module on the server as there is no corresponding trace 
log on the server side.

On Protocol level, everything looks fine so far, the sequence executed is as 
follows:

-->SIP REGISTER
<-- SIP/2.0 401 Unauthorized
-->SIP REGISTER
<--SIP/2.0 200 OK
-->INVITE
<--SIP/2.0 407 Proxy Authentication Required
-->ACK
-->INVITE
<--SIP/2.0 180 Ringing
<--SIP/2.0 180 Ringing
<--SIP/2.0 200 OK
-->ACK


The INVITE is processed with the following SDP packet in the request:

v=0
o=- 1337788359935 1337788359935 IN IP4 localhost
s=MSRP Session
c=IN IP4 localhost
t=0 0
m=message 2855 TCP/MSRP *
a=path:msrp://localhost:2855/U3FuvW00m62UY0020H71;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:active

And response:
v=0
o=- 3546777215 3546777216 IN IP4 46.105.78.68
s=sipsimple 0.20.0
c=IN IP4 46.105.78.68
t=0 0
m=message 57233 TCP/MSRP *
a=path:msrp://msrphost:2855/5AUNTOt7XlFsK7VuT4SzETEzMzc3ODg0MTUuMDcyOjQ2LjEwNS43OC42OA==;tcp
 msrp://msrphost:57233/6bf6dd73b9e4587b65b6;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:passive


But when sending the MSRP message, 501 is returned:

MSRP f0CHA1TD SEND
To-Path: msrp://msrphost:57233/6bf6dd73b9e4587b65b6;tcp
From-Path: msrp://localhost:52673/b10XadK9;tcp
Message-ID: 13377883623135c260a3568cc
Byte-Range: 1-*/14

Hello Francois
---f0CHA1TD$


MSRP f0CHA1TD 501 Unknown method: SEND
To-Path: msrp://localhost:52673/b10XadK9;tcp
From-Path: msrp://msrphost:57233/6bf6dd73b9e4587b65b6;tcp
---f0CHA1TD$


When testing with two sip-simple client endpoints, MSRP messaging works fine, 
but on protocol traces we cannot identify any differences between sip-simple 
communication flows and the ones we are implementing.
Does anyone have a hint on what is wrong in this message flow? Any advice is 
appreciated.

Thanks,
Alex





___

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users@lists.sip-router.org

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--

Daniel-Constantin Mierla - http://www.asipto.com

http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] [OT] sems [and kamailio] in risk-of-life service

2012-05-25 Thread Daniel-Constantin Mierla 


just forwarding from SEMS mailing list an interesting story of using 
kamailio and sems in emergency services...


 Original Message 
Subject:[Sems] sems in risk-of-life service
Date:   Thu, 24 May 2012 15:29:38 +0800
From:   Jeremy A 
To: s...@lists.iptel.org



Hi,

This is a belated report on the use of SEMS in a risk of life service.

The system uses kamailio in a distributed architecture of dozens of Fire 
& Rescue stations. This is heavily based on distributed and replicated DNS.


A single '911' style headquarters has duplicate hot swap-over control 
rooms at other locations.


The headquarter and alternate posts have servers that service HQ 
operator positions with SIP phones. These provides sidecar indication of 
F&R Station state for up to 64 F&R stations - using BLF. These phones 
are hooked into an integrated analogue audio management system.


Each Fire and Rescue station has an embedded SIP based controller that 
runs Kamailio and proprietary software to control the F&R station 
electrical and safety systems as well as provide public address 
functions to alert the F&R staff of a new emergency. These PA 
announcements are SIP based using a DSL network and are live from the HQ 
positions, plus computer synthesized voice, as well as alerting tones.


Each station also has multiple SIP phones for in-station and station to 
station calling.


The network is decentralized so failure of the central control system 
still allows point to point communications between Fire and Rescue stations.


The headquarter systems uses SEMS as the primary operator manager to 
perform multiple simultaneous deployment calls to remote Fire and Rescue 
stations. SEMS is used to create a dynamic conference between an 
operator and multiple Fire & Rescue stations. These are automatically 
initiated by SEMS and answered by the F&R embedded systems. This means 
an operator can broadcast a deployment message and initiate station 
control activities at up to five stations (fifth alarm) This is only 
constrained by the bandwidth available at the headquarters. Our SEMS 
packages have been designed to handle non-answered calls to the 
conference and provide operator indication by 'SMS' messages to the 
handsets and audio feedback.


The system provides full forensic recording by using rtpproxy at all 
locations. These recordings are archived by an out-of-band process.


Control of the system is purely SIP based - so every item in the system 
is a SIP based entity. This includes servers, embedded systems, and phones.


The phones are physically integrated into operator positions that also 
handle PSTN, PBX, and radio traffic. The interface is purely keyboard on 
the operator phones.


Options for integration of the SIP system into CAD (Computer Aided 
Dispatch) are obvious. The only drawback is the rusty and ancient 
systems and the unbelievable process required to get approval to integrate.


The system as provided provides at least 5 nines reliability. Probably a 
lot better. The only downside is the DSL network (provided by others at 
amazing expense) that provides a system with a lousy 2 nines 
reliability. We are in the process of developing an offering using 
redundant DLS/3G routing to improve this.


The field stations are a hybrid Centos 5/Slax  system running out of 
flash. The HQ systems are straight Centos 5 systems running off disk or 
off flash. Future versions will be pure Centos out of flash with no 
fancy memory overlay - flash is well good enough.


The system has been live for over a year with no major issues. I can't 
say how many lives have been saved, but certainly quite a few. At least 
we haven't been sued yet :-)


Cheers.



___
Sems mailing list
s...@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/sems

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TLS config file

2012-05-25 Thread Bruno Bresciani 
Thank's for your reply Daniel...

Best Regards

2012/5/24 Daniel-Constantin Mierla 

>  Hello,
>
> if there is none matching the ip address of the interface, the default one
> is used.
>
> So you can define one like [server:127.0.0.1:5061] just to be valid for
> connections coming on loopback interface. You can replace the ip and the
> port to fit your actual wan or lan address.
>
> Cheers,
> Daniel
>
>
> On 5/22/12 4:20 PM, Bruno Bresciani wrote:
>
> The parameter [server:default] of TLS config file must be declared? I want
> specify two different interfaces (WAN and LAN) and I don't know which
> interface will be used as default by TLS module...
> Someone know some information about my question?
>
> Best Regards
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda 
> - http://www.linkedin.com/in/miconda
>
>
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailioi is not relaying BYE message to UAC

2012-05-25 Thread Aft nix 
On Thu, May 24, 2012 at 6:41 PM, Vitaliy Aleksandrov
 wrote:
>
> Thanks for the reply.
>
> We have already came to the same conclusion by some testing in our
> lab. It seems its a bug in provider which not constructing BYE message
> properly.
>
> But i'm interested in if its possible to detect the fault in this BYE
> and construct a new one and then relay it to the UAC.
>
> I mean can i do this :
>
> contact-header = INVITE's contact-header
> if (contact-header != BYE's ruri)
> {
>   construct BYE message with contact header
>   t_relay()
>  }
>
> Cheers
> aft
>
>
> Hi aft,
>
> I think to do what you want you can save Contact field + callid pair taken
> from the INVITEs that comes from your side.
> Then when BYE comes from such provider you should find a correct Contact for
> that call-id and if it exists and not equal to R-URI you can rewrite it.
>
> For example to write to R-URI value from $var(correct_ruri) you can use $ru
> = $var(correct_ruri); statement.
>
> What about a place where contact can be saved, i think htable will be the
> nice one.
> Please pay attention to "autoexpire" parameter of htable module. You should
> take care about the staled records to avoid memory usage problems.
>
> Cheers,
> Vitaliy Aleksandrov
>

Hi Aleksandrov,

Thanks for the suggestion. I was playing with the dialog module to
achieve the same thing. But your suggestion seems more lightweight
ans sensible than invoking full blown dialog functionality most of
which i do not need for my purpose.

I will try your approach and post the update.

In the mean time, my dialog module approach is not working either as expected.

I used dialog module like following :

 #!ifdef WITH_DLG
 modparam("dialog", "enable_stats",0)
 modparam("dialog", "dlg_flag",DLG_FLAG )
 modparam("dialog", "default_timeout",100)
 #!endif


request_route {
 # per request initial checks
 route(REQINIT);
 #!ifdef WITH_DLG
 if (is_method("INVITE") && !has_totag()){
 $dlg_ctx(timeout_route) = 12;
 $dlg_ctx(timeout_bye) = 1;
 }
 dlg_manage();
 #!endif

...
...
 route[WITHINDLG] {

 if (has_totag()) {
 # sequential request withing a dialog should
 # take the path determined by record-routing
 #!ifdef WITH_DLG
 if (is_method("BYE")){
 dlg_get ("$ci","$ft","$tt");
 dlg_bye ("all");
 return;
 }
 #!endif
 if (loose_route()) {
 if (is_method("BYE")) {
 setflag(FLT_ACC); # do accounting ...
 setflag(FLT_ACCFAILED); # ... even if
tansaction fails



#!ifdef WITH_DLG
 route[12]{
 dlg_bye("all");
 xdbg("bye everyone");
 }
 #!endif


I'm not worried about timeout right now. This does not work. When bye
message arrives i can see the following in kamailio log :

[4016]: DEBUG:  [parser/msg_parser.c:624]: SIP Request:
[4016]: DEBUG:  [parser/msg_parser.c:626]:  method:  
[4016]: DEBUG:  [parser/msg_parser.c:628]:  uri:

[4016]: DEBUG:  [parser/msg_parser.c:630]:  version: 
[4016]: DEBUG:  [parser/parse_via.c:1289]: Found param type 232,
 = ; state=16
[4016]: DEBUG:  [parser/parse_via.c:2564]: end of header reached, state=5
[4016]: DEBUG:  [parser/msg_parser.c:511]: parse_headers: Via
found, flags=2
[4016]: DEBUG:  [parser/msg_parser.c:513]: parse_headers: this
is the first via
--
[4016]: DEBUG:  [parser/msg_parser.c:190]: DEBUG: to body
["1010"]
[4016]: DEBUG:  [parser/msg_parser.c:168]: get_hdr_field: cseq
: <3> 
[4016]: DEBUG:  [parser/msg_parser.c:202]: DEBUG: get_hdr_body :
content_length=0
[4016]: DEBUG:  [parser/msg_parser.c:104]: found end of header
[4016]: DEBUG:  [parser/parse_to.c:178]: DEBUG: add_param: tag=e06d7c6a
[4016]: DEBUG:  [parser/parse_to.c:802]: end of header reached, state=29
[4016]: DEBUG: sanity [mod_sanity.c:255]: sanity checks result: 1
[4016]: DEBUG: dialog [dlg_hash.c:652]: no dialog
callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found
[4016]: DEBUG: dialog [dlg_hash.c:683]: no dialog
callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found
[4016]: DEBUG: dialog [dlg_handlers.c:1166]: Callid
'OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' not found
.
.
[4016]: DEBUG: dialog [dlg_hash.c:652]: no dialog
callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found
[4016]: DEBUG: dialog [dlg_hash.c:683]: no dialog
callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found


After some inspection i found out this :

[4017]: DEBUG: dialog [dlg_hash.c:646]: dialog
callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found  on entry
321, dir=1
[401