some calls that use rtpengine produce "SRT[C]P output wanted, but no
crypto suite was negotiated" syslog messages. below is an example. the
messages seem to appear after rtpengine has replied to offer request,
but before it has got answer request that includes crypto suite
negotiation in its sdp.
Filip Malenka writes:
> Is there any solution for Kamailio with mediaproxy?
i would suggest that you use rtpengine instead.
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.
Hi all,
I have searched for instructions for setting up Kamailio with mediaproxy
instead of rtpproxy, but I can't find anything. I found only OpenSips pages and
some other outdated examples but the config does not apply very much on
kamailio.cfg.
As much as I could find out is that Kamailio na
I pushed two patches, as it required a small adjustment to acc module
for this case -- they are now in master, affecting acc and dialog
modules. Testing and feedback whether it works or not is very appreciated.
I went a different path, considering the case when the bye is coming
from the wire, two
Actually there is nothing special to rely on what so ever prerogatives
in this case. Writing cdrs based on dialog module was added by 1&1 long
time ago (iirc) and they have couple of millions of subscribers and tons
of calls, so this approach might have been better for them from various
reasons. In
Fair enough. It is your prerogative to take a definitive stance on the issue. I was just voicing personal view that truly complete accounting can only be done from SIP message-oriented perspective in software that
On 15/04/15 15:35, Mickael Marrache wrote:
>
> Thanks for your reply, the solution you proposed works fine.
>
>
>
> However, I created a pull request with the flag change you proposed. I
> tested the change, it works, however I wonder if there is a way to
> access the flag name inside the scrip
On 15/04/15 16:27, Mickael Marrache wrote:
>
> I'm looking at the dlg_ontimeout function [dlg_handlers.c:1369] and I
> understand the code, the DLGCB_EXPIRED callbacks are not called when
> the send_bye parameter is set to 1.
>
>
>
> I'm looking at the block 1399-1408.
>
Indeed, looking quickly
Looks like the topic diverged in side discussion, irrelevant to the issue.
The report was related to the fact that the dialog+acc is not recording
the CDRs when sending the BYE on timeout. That is obviously an issue
because there is dedicated functionality for this case. I am not the
original deve
Hook, route, whatever you want to call it. The bottom line is that you cannot rely on the proxy's dialog layer, already a tenuous concept inasmuch as it's implemented strictly on top of transaction state specifica
âWhy are you using the dialog start/end hooks? They work well for standard scenarios clearly understood by the dialog module. For nonstandard scenarios, use the TM local-request route to catch and log endogenous
I'm not using any hook – I just need CDRs to be generated when a dialog timeout
occurs; and currently, no CDRs are written in such cases.
From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Alex
Balashov
Sent: Wednesday, April 15, 2015 5:32 PM
To: sr-users@lists.sip-rou
I'm looking at the dlg_ontimeout function [dlg_handlers.c:1369] and I
understand the code, the DLGCB_EXPIRED callbacks are not called when the
send_bye parameter is set to 1.
I'm looking at the block 1399-1408.
From: Mickael Marrache [mailto:mickaelmarra...@gmail.com]
Sent: Wednesday, Apri
Yes, that is an accurate conclusion, and there is no harm in it. Hopefully, dialog timeouts are a relatively aberrant event. The whole spoof-BYE implementation is a hack, outside the prescribed behaviour for SIP p
Ok I understand, the warning is generated in bye_reply_cb() which I guess is
called when the 200 is received for the BYE, and in this case, there are two
200 (one for each BYE).
The function send_bye() [dlg_req_within.c:325] is called twice: once for the
caller and another time for the callee.
On 15/04/15 15:42, Mickael Marrache wrote:
>
> It looks like it is a real issue since CDRs are not generated on
> dialog timeout.
>
>
>
> If the dialog is not in the timer list, does that mean the
> DLGCB_EXPIRED callbacks are not called?
>
The log message is not related. It pure about trying t
Also, I get this warning without two BYEs crossing since the BYEs are
generated by Kamailio and sent to the caller and callee.
From: Mickael Marrache [mailto:mickaelmarra...@gmail.com]
Sent: Wednesday, April 15, 2015 4:43 PM
To: 'mico...@gmail.com'; 'Kamailio (SER) - Users Mailing List'
Subjec
It looks like it is a real issue since CDRs are not generated on dialog
timeout.
If the dialog is not in the timer list, does that mean the DLGCB_EXPIRED
callbacks are not called?
From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Daniel-Constantin Mierla
Sent: Wedne
Thanks for your reply, the solution you proposed works fine.
However, I created a pull request with the flag change you proposed. I
tested the change, it works, however I wonder if there is a way to access
the flag name inside the script?
Mickael
From: sr-users [mailto:sr-users-boun...@
I also confirm the cdr_on_create() [acc_cdr.c:718] function is called since
I can see the debug statement "dialog '%p' created!".
From: Mickael Marrache [mailto:mickaelmarra...@gmail.com]
Sent: Wednesday, April 15, 2015 3:48 PM
To: sr-users@lists.sip-router.org
Subject: No CDR is written when
Hi,
I'm testing the dialog timeout scenario and I see that no CDR is written.
This is my configuration:
modparam("acc", "cdr_enable", 1)
modparam("acc", "cdr_expired_dlg_enable", 1)
modparam("acc", "cdr_start_on_confirmed", 1)
modparam("acc", "cdr_log_enable", 0)
modparam("acc", "cd
On Wednesday 15 April 2015 14:03:16 Daniel-Constantin Mierla wrote:
> > add_path();
> > msg_apply_changes();
> >
> Are you saying the result after msg_apply_changes() is a broken message?
> You can see what is there by printing $rb or $mb -- don't recall by
> heart
Hello,
On 15/04/15 14:04, Mickael Marrache wrote:
>
> Hi,
>
>
>
> I get the following warning when a dialog timeout occurs:
>
>
>
> kamailio[18889]: WARNING: dialog [dlg_req_within.c:214]:
> bye_reply_cb(): inconsitent dlg timer data on dlg 0x7f422986e448
> [3547:6673] with clid 'mycvJWgmbmOSD
Hello,
On 15/04/15 14:02, Mickael Marrache wrote:
>
> Hi,
>
>
>
> I'm looking for a way to differentiate between regular hangup and
> dialog timeout.
>
>
>
> In both case, the dialog:end event is called. Do you know which
> information can I use in the event route to differentiate between the
Hi,
I get the following warning when a dialog timeout occurs:
kamailio[18889]: WARNING: dialog [dlg_req_within.c:214]: bye_reply_cb():
inconsitent dlg timer data on dlg 0x7f422986e448 [3547:6673] with clid
'mycvJWgmbmOSD5XQrcStKAKoTfW12XeR' and tags
'C5mlsaZCdTmybNSYgvWr75MBxWa5hVyA' 'L1Zzs
On 14/04/15 18:53, Daniel Tryba wrote:
> On Tuesday 14 April 2015 13:37:42 Ben Langfeld wrote:
>> Note that you could equally use add_path().
> add_path();
> msg_apply_changes();
>
> Results in:
>
> SIP/2.0 400 Bad Request.
> ...
> P-Registrar-Error: Path parse err
Hi,
I'm looking for a way to differentiate between regular hangup and dialog
timeout.
In both case, the dialog:end event is called. Do you know which information
can I use in the event route to differentiate between the two cases?
Thanks,
Mickael
__
On 14/04/15 18:40, Daniel Tryba wrote:
> On Tuesday 14 April 2015 17:59:01 Daniel-Constantin Mierla wrote:
>> Upcoming major release has some embedded functionality for this case,
>> relying on path -- iirc, was added by Charles Chance:
> Good to know, if this could do something with DNS SRV reco
Hello,
On 14/04/15 21:46, Mickael Marrache wrote:
>
> Hi,
>
>
>
> I sometimes get the following errors:
>
>
>
> kamailio[16098]: ERROR: [resolve.c:1693]: sip_hostport2su():
> could not resolve hostname: "mycompany.com"
>
> kamailio[16098]: ERROR: tm [ut.h:319]: uri2dst2(): failed to resolve
>
Hello,
I don't remember and t_replicate_to() for config, can you show the
function how you use it in config, with its parameters?
Cheers,
Daniel
On 15/04/15 09:36, Igor Potjevlesch wrote:
>
> To precise, the error occurred with t_replicate_to where the second
> parameter is an AVP like "hostname
To precise, the error occurred with t_replicate_to where the second
parameter is an AVP like "hostname:4060"
Regards,
Igor.
De : Igor Potjevlesch [mailto:igor.potjevle...@gmail.com]
Envoyé : mercredi 15 avril 2015 09:15
À : sr-users@lists.sip-router.org
Objet : Error protoaddr2proxy
Hello,
I got many errors like this one:
ERROR: tm [tm.c:1192]: t_protoaddr2proxy(): tm: protoaddr2proxy: host name
is empty
It looks to be while I'm doing a sl_send_reply but I don't figure out why.
Someone know what going wrong?
Regards,
Igor.
___
32 matches
Mail list logo
