Re: [SR-Users] Kamailio Freezes and no calls are processed
Hello, On 8/20/11 10:16 PM, Omar wrote: The only difference is we have added some AVPs variables to process, and kamailio stops processing new calls, is not regular, but seems is related to the number of calls received. No additional calls can be processed after certain time, or maybe some amount of calls. we were unable to isolate the problem, but kamailio.fifo is removed, which never happened before. No core dump created. did anybody have a similar issue. first, what version are you using? Do you see any other particular behaviours? Like lot of CPU usage, error messages in syslog? Does the processing recovers? I mean, is it starting to process sip traffic again after a while? Or do you have to restart? Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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] Sip Router Issues (Topoh's module)
Hi Daniel,
Do you need more information to track this issue?
Best regards,
On Mon, 08 Aug 2011 11:08:28 +0200, Richard DEMONGEOT
wrote:
> Hi Daniel,
>
> Following network capture about this error
>
> Establishing dialog :
>
> U 192.168.1.15:22490 -> 192.168.238.66:5060
> INVITE sip:mike@193.41.238.66 SIP/2.0..Via: SIP/2.0/UDP
>
192.168.1.15:22490;branch=z9hG4bK-d87543-ac504a4dec29b725-1--d87543-;rport..Max-Forwards:
> 70..Contact: ..To: "mike" :mike@193.41.238.66>..From:
> "guest";tag=da5f1d51..Call-ID:
> MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 1 INVITE..Allow:
> INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, ME
> SSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent:
X-Lite
> release 1006e stamp 34025..Content-Length: 325v=0..o=- 0 2 IN IP4
> 192.168.1.15..s=CounterPath X-Lite 3.0..c=IN IP4 192.168.1.15
> ..t=0 0..m=audio 59868 RTP/AVP 107 119 0 98 8 3 101..a=alt:1 1 :
8QG5saMW
> GpfUnnJ2 192.168.1.15 59868..a=fmtp:101 0-15..a=rtpmap:107
> BV32/16000..a=rtpmap:119 BV32-FEC/16000..a=rtpmap:98 iLBC/8000..a=rtpmap
> :101 telephone-event/8000..a=sendrecv..
>
> U 192.168.238.66:5060 -> 192.168.1.82:11126
> INVITE sip:mike@192.168.1.82:11126;rinstance=927a1ec90c2eaae1
> SIP/2.0..Record-Route:
> ..Via: SIP/2.0/UDP
> 193.41.238.66;branch=z9hG4bK7922.1834b4a3.0..Via: S
> IP/2.0/UDP
>
193.41.238.91;branch=z9hG4bKsr-jeHVIbuBclW510R2cqTnIEiOglD9IEiZgEun6MTGgZ1u-v1KdEzSpo0B.O2W8EHy1b1SfnZTgMpZ6Mcz.q.G.bpOcEuGxqun6b2Ggle9IfZTgMpZ6MczgkYGtkYe-qun6MTG..Max-Forwards:
> 69..Contact: ip:193.41.238.91;line=sr-pOHGgodZxh6eVMircSD96E2BcfD96qyncEVrcR**>..To:
> "mike"..From:
> "guest";tag=da5f1d51..Call-ID:
> LongPhone@qjd5c5Kmfq1g50x4qEY1deZCLkdg5
> ijZqoKwderiVhKLt50CvhKP85Hj5fD*..CSeq: 2 INVITE..Allow: INVITE, ACK,
> CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
> INFO..Content-Type: application/sdp..User-Agent: X-Lite release 1006e
stamp
> 340
> 25..Content-Length: 345..Session-Expires: 90v=0..o=- 0 2 IN IP4
> 193.41.238.66..s=CounterPath X-Lite 3.0..c=IN IP4 193.41.238.66..t=0
> 0..m=audio 46488 RTP/AVP 107 119 0 98 8 3 101..a=alt:1 1 : 8QG5saMW
> GpfUnnJ2 192.168.1.15 59868..a=fmtp:101 0-15..a=rtpmap:107
> BV32/16000..a=rtpmap:119 BV32-FEC/16000..a=rtpmap:98
> iLBC/8000..a=rtpmap:101
> telephone-event/8000..a=sendrecv..a=nortpproxy:yes..
>
> [...]
>
> dlg_end_dlg used in this case :
>
> U 192.168.238.66:5060 -> 192.168.1.15:22490
> BYE sip:guest@192.168.1.15:22490 SIP/2.0..Via: SIP/2.0/UDP
> 193.41.238.66;branch=z9hG4bK8922.3152a2a4.0..To:
> sip:guest@193.41.238.66;tag=da5f1d51..From:
> sip:mike@193.41.238.66;tag=99700f27..CSeq: 3 BYE..Cal
> l-ID: MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...Content-Length:
> 0..User-Agent: kamailio (3.1.4 (x86_64/linux))..Max-Forwards: 70
>
>
> U 192.168.238.66:5060 -> 192.168.1.82:11126
> BYE sip:mike@192.168.1.82:11126;rinstance=927a1ec90c2eaae1 SIP/2.0..Via:
> SIP/2.0/UDP 193.41.238.66;branch=z9hG4bK8922.4152a2a4.0..To:
> sip:mike@193.41.238.66;tag=99700f27..From: sip:guest@193.41.238.66;tag=
> da5f1d51..CSeq: 3 BYE..Call-ID:
> MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...Content-Length:
> 0..User-Agent: kamailio (3.1.4 (x86_64/linux))..Max-Forwards: 70
>
>
> U 192.168.1.15:22490 -> 192.168.238.66:5060
> SIP/2.0 200 OK..Via: SIP/2.0/UDP
> 193.41.238.66;branch=z9hG4bK8922.3152a2a4.0..Contact:
> ..To:
> ;tag=da5f1d51..From:
> ;tag=99700f2
> 7..Call-ID: MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 3
> BYE..User-Agent: X-Lite release 1006e stamp 34025..Content-Length: 0
>
>
> U 192.168.1.82:11126 -> 192.168.238.66:5060
> SIP/2.0 481 Call/Transaction Does Not Exist..Via: SIP/2.0/UDP
> 193.41.238.66;branch=z9hG4bK8922.4152a2a4.0..To:
> ;tag=99700f27..From:
> ;tag=da5f1d51..Call-ID:
> MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 3
BYE..Accept-Language:
> en..Content-Length: 0
>
> I wish that it can help you to troble shoot this problem.
>
> Best regards,
>
> On Fri, 05 Aug 2011 19:11:45 +0200, Richard DEMONGEOT
> wrote:
>> Hi,
>>
>>
>>
>> On Fri, 05 Aug 2011 17:43:34 +0200, Daniel-Constantin Mierla
>> wrote:
>>> Hello,
>>>
>>> On 8/5/11 9:56 AM, Richard DEMONGEOT wrote:
Dear all,
I've encountered two issues with Sip Router.
Build : Kamailio 3.1.4 for Squeeze (Kamailio's debian Packages).
When i'm using Topoh with Call-ID encoding, instruction
dlg_bye("ALL")
generate me an error on logfiles :
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh
[th_mask.c:166]: invalid input
string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0"
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh
[th_msg.c:480]: cannot decode callid
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh
[th_mask.c:166]: invalid input
string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0"
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh
[th_msg.c:480]: cannot decode
[SR-Users] Freezing development for v3.2.0 today
Hello, just a short reminder that we will close the development of new features for version 3.2.0 at the end of today, GMT. Then the focus should be on testing (e.g., bug fixing) and enhancements to documentation. If you have something to commit, do it today, or if it is impossible for you to make it in the GIT repo today, let us know and we will see what can be done. But don't forget, 3.3.0 will come as well in the no-so-far future. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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] 10 Years SER Conference, Berlin - full booked
Hello, the 10 years SER conference in Berlin is full booked, meaning that new registrations will be accepted only if someone that registered previously will cancel his/her participation. Since we just discovered such a situation, in the case you did register and you haven't received a confirmation email (not the one automatically generated at registration time, but a second one), please reply to me or write to registrat...@lists.sip-router.org telling the date when you did the registration and we will try to solve it. Looking forward to meeting many of you soon in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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] Sip Router Issues (Topoh's module)
Hi Richard,
should be fine for now, just need the time to set it up for
troubleshooting -- traveling, freezing for 3.2 and 10 years SER
conference kept me busy with other things that needed done so far.
Should get back to things reported to me very soon, since tomorrow we
get into testing phase.
Thanks,
Daniel
On 8/22/11 10:50 AM, Richard DEMONGEOT wrote:
Hi Daniel,
Do you need more information to track this issue?
Best regards,
On Mon, 08 Aug 2011 11:08:28 +0200, Richard DEMONGEOT
wrote:
Hi Daniel,
Following network capture about this error
Establishing dialog :
U 192.168.1.15:22490 -> 192.168.238.66:5060
INVITE sip:mike@193.41.238.66 SIP/2.0..Via: SIP/2.0/UDP
192.168.1.15:22490;branch=z9hG4bK-d87543-ac504a4dec29b725-1--d87543-;rport..Max-Forwards:
70..Contact:..To: "mike"..From:
"guest";tag=da5f1d51..Call-ID:
MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 1 INVITE..Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, ME
SSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent:
X-Lite
release 1006e stamp 34025..Content-Length: 325v=0..o=- 0 2 IN IP4
192.168.1.15..s=CounterPath X-Lite 3.0..c=IN IP4 192.168.1.15
..t=0 0..m=audio 59868 RTP/AVP 107 119 0 98 8 3 101..a=alt:1 1 :
8QG5saMW
GpfUnnJ2 192.168.1.15 59868..a=fmtp:101 0-15..a=rtpmap:107
BV32/16000..a=rtpmap:119 BV32-FEC/16000..a=rtpmap:98 iLBC/8000..a=rtpmap
:101 telephone-event/8000..a=sendrecv..
U 192.168.238.66:5060 -> 192.168.1.82:11126
INVITE sip:mike@192.168.1.82:11126;rinstance=927a1ec90c2eaae1
SIP/2.0..Record-Route:
..Via: SIP/2.0/UDP
193.41.238.66;branch=z9hG4bK7922.1834b4a3.0..Via: S
IP/2.0/UDP
193.41.238.91;branch=z9hG4bKsr-jeHVIbuBclW510R2cqTnIEiOglD9IEiZgEun6MTGgZ1u-v1KdEzSpo0B.O2W8EHy1b1SfnZTgMpZ6Mcz.q.G.bpOcEuGxqun6b2Ggle9IfZTgMpZ6MczgkYGtkYe-qun6MTG..Max-Forwards:
69..Contact:..To:
"mike"..From:
"guest";tag=da5f1d51..Call-ID:
LongPhone@qjd5c5Kmfq1g50x4qEY1deZCLkdg5
ijZqoKwderiVhKLt50CvhKP85Hj5fD*..CSeq: 2 INVITE..Allow: INVITE, ACK,
CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO..Content-Type: application/sdp..User-Agent: X-Lite release 1006e
stamp
340
25..Content-Length: 345..Session-Expires: 90v=0..o=- 0 2 IN IP4
193.41.238.66..s=CounterPath X-Lite 3.0..c=IN IP4 193.41.238.66..t=0
0..m=audio 46488 RTP/AVP 107 119 0 98 8 3 101..a=alt:1 1 : 8QG5saMW
GpfUnnJ2 192.168.1.15 59868..a=fmtp:101 0-15..a=rtpmap:107
BV32/16000..a=rtpmap:119 BV32-FEC/16000..a=rtpmap:98
iLBC/8000..a=rtpmap:101
telephone-event/8000..a=sendrecv..a=nortpproxy:yes..
[...]
dlg_end_dlg used in this case :
U 192.168.238.66:5060 -> 192.168.1.15:22490
BYE sip:guest@192.168.1.15:22490 SIP/2.0..Via: SIP/2.0/UDP
193.41.238.66;branch=z9hG4bK8922.3152a2a4.0..To:
sip:guest@193.41.238.66;tag=da5f1d51..From:
sip:mike@193.41.238.66;tag=99700f27..CSeq: 3 BYE..Cal
l-ID: MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...Content-Length:
0..User-Agent: kamailio (3.1.4 (x86_64/linux))..Max-Forwards: 70
U 192.168.238.66:5060 -> 192.168.1.82:11126
BYE sip:mike@192.168.1.82:11126;rinstance=927a1ec90c2eaae1 SIP/2.0..Via:
SIP/2.0/UDP 193.41.238.66;branch=z9hG4bK8922.4152a2a4.0..To:
sip:mike@193.41.238.66;tag=99700f27..From: sip:guest@193.41.238.66;tag=
da5f1d51..CSeq: 3 BYE..Call-ID:
MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...Content-Length:
0..User-Agent: kamailio (3.1.4 (x86_64/linux))..Max-Forwards: 70
U 192.168.1.15:22490 -> 192.168.238.66:5060
SIP/2.0 200 OK..Via: SIP/2.0/UDP
193.41.238.66;branch=z9hG4bK8922.3152a2a4.0..Contact:
..To:
;tag=da5f1d51..From:
;tag=99700f2
7..Call-ID: MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 3
BYE..User-Agent: X-Lite release 1006e stamp 34025..Content-Length: 0
U 192.168.1.82:11126 -> 192.168.238.66:5060
SIP/2.0 481 Call/Transaction Does Not Exist..Via: SIP/2.0/UDP
193.41.238.66;branch=z9hG4bK8922.4152a2a4.0..To:
;tag=99700f27..From:
;tag=da5f1d51..Call-ID:
MGU1ZjI4NTVlN2QwMzkwNTE5NjAwNDAzZmQzYzkyYTU...CSeq: 3
BYE..Accept-Language:
en..Content-Length: 0
I wish that it can help you to troble shoot this problem.
Best regards,
On Fri, 05 Aug 2011 19:11:45 +0200, Richard DEMONGEOT
wrote:
Hi,
On Fri, 05 Aug 2011 17:43:34 +0200, Daniel-Constantin Mierla
wrote:
Hello,
On 8/5/11 9:56 AM, Richard DEMONGEOT wrote:
Dear all,
I've encountered two issues with Sip Router.
Build : Kamailio 3.1.4 for Squeeze (Kamailio's debian Packages).
When i'm using Topoh with Call-ID encoding, instruction
dlg_bye("ALL")
generate me an error on logfiles :
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh
[th_mask.c:166]: invalid input
string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0"
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh
[th_msg.c:480]: cannot decode callid
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh
[th_mask.c:166]: invalid input
string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0"
Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh
[th_msg.c:480]: cannot decode cal
Re: [SR-Users] Kamailio Freezes and no calls are processed
Hi, On Sat, Aug 20, 2011 at 10:16 PM, Omar wrote: > > > The only difference is we have added some AVPs variables to process, and > kamailio stops processing new calls, is not regular, but seems is related to > the number of calls received. > No additional calls can be processed after certain time, or maybe some amount > of calls. > > we were unable to isolate the problem, but kamailio.fifo is removed, which > never happened before. > No core dump created. > > did anybody have a similar issue. I had a similar issue some time ago. Look in the archives and you will find som backtraces from gdb. The problem went away when I changed the dialog module not to write to DB but only use memory. -- Morten Isaksen ___ 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] Kamailio Freezes and no calls are processed
On 22.08.2011 14:04, Morten Isaksen wrote: > On Sat, Aug 20, 2011 at 10:16 PM, Omar wrote: >> >> >> The only difference is we have added some AVPs variables to process, > and kamailio stops processing new calls, is not regular, but seems is > related to the number of calls received. >> No additional calls can be processed after certain time, or maybe some > amount of calls. >> >> we were unable to isolate the problem, but kamailio.fifo is removed, > which never happened before. >> No core dump created. >> >> did anybody have a similar issue. > > I had a similar issue some time ago. Look in the archives and you will > find som backtraces from gdb. > > The problem went away when I changed the dialog module not to write to > DB but only use memory. I added a few fixes to the DB part of the dialog module, so chances are the problem doesn't show up anymore when using sip-router master or a recent copy of the 3.1 branch. If you want to give DB mode another try and encounter these lock ups again, feel free to post to the mailing list and add me in CC so I can take a closer look. Cheers, --Timo ___ 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] min expires question
I think that can easily become a problem if all the users decide to send
registrations as they please. I tried looking into ratelimit and pike and it
wont solve my problem.
What is the extent of the setting min_expires on this module? Will it create a
423 reply to the user or is not the intended behavior?
In the mean time I am trying to craft a 423 Message when the expires in the
Contact header or in the Expires header is less than the min_expires set in the
config but I am having problems parsing and looking for the Expires header.
With the expires in the contact is easy using the select feature or parsing the
whole contact using $ct:
xlog("L_INFO","mylog: Contact Header: [$ct].\n");
$var(c_expires) = $(ct{s.select,1,=});
or this way, it is more accurate
$sel(@contact.expires)
but I can't find a way to do the same thing with the Expires headers. In the
same page that I found the "select " it says:
"The select is a READ-ONLY "function", that helps to get
direct access to some parts of SIP message within the script (like @to,
@cseg.method, @msg["P-anyheader-youwant"]) "
So I am trying to use this @msg["P-anyheader-youwant"] but I can't make it work.
Any ideas?
txs a lot in advance
___
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] min expires question
There is no way to prevent that a SIP client sends you a request at any
time.
The standard defined behavior for setting REGISTER interval is by
setting the expires header.
Of course you could block which does not use the provided expires
header, but then it may increase load on your support team because
customers will start to complain.
regards
Klaus
Am 22.08.2011 15:15, schrieb Fabian Borot:
> I think that can easily become a problem if all the users decide to send
> registrations as they please. I tried looking into ratelimit and pike
> and it wont solve my problem.
> What is the extent of the setting min_expires on this module? Will it
> create a 423 reply to the user or is not the intended behavior?
>
> In the mean time I am trying to craft a 423 Message when the expires in
> the Contact header or in the Expires header is less than the min_expires
> set in the config but I am having problems parsing and looking for the
> Expires header. With the expires in the contact is easy using the select
> feature or parsing the whole contact using $ct:
>
> xlog("L_INFO","mylog: Contact Header: [$ct].\n");
> $var(c_expires) = $(ct{s.select,1,=});
>
> or this way, it is more accurate
>
> $sel(@contact.expires)
>
>
> but I can't find a way to do the same thing with the Expires headers. In
> the same page that I found the "select " it says:
> "The *select* is a READ-ONLY "function", that helps to get direct access
> to some parts of SIP message within the script (like @to, @cseg.method,
> @msg["P-anyheader-youwant"]) "
>
> So I am trying to use this @msg["P-anyheader-youwant"] but I can't make
> it work.
>
> Any ideas?
> txs a lot in advance
>
>
> ___
> 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
___
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] decode_mime_type error
Hi Marius, You are right.. It will fail for parse_accept_body... I hope you will be able to open this issue on bug tracker.. Thanks Jijo On Fri, Aug 19, 2011 at 10:12 PM, Bucur Marius < bucur_marius_ovi...@yahoo.com> wrote: > Hello Jijo, > > About the example I pointed, the parse_accept_body will fail and let me > explain why. > For the second invocation, 'some value' is not a valid mime type (a mime > type is of form 'type/subtype'). When decode_mime_type will not find the '/' > separator (see parse_content.c:310) it will fail, making parse_accept_body > to fail too. > > If you want to test, just call parse_accept_body with the example I > pointed, and you will see it returns -1 for my example (a valid accept > header). This is, of course, bad behavior. > > Best regards, > Marius > > -- > *From:* Jijo > *To:* Bucur Marius ; > sr-users@lists.sip-router.org > *Sent:* Friday, August 19, 2011 11:17 AM > > *Subject:* Re: [SR-Users] decode_mime_type error > > Hi Marius, > > The existing implementation is done considering the limitation of > decode_mime_type but somehow missed the change in parse_content_type_hdr. I > agree with you that its better to do the change in decode_mime_type as it is > common for lot of other callers.. > > Regarding the example you pointed, > According to my understanding from the code, I believe that existing > implementation for parse_accept_body shall work as the mime types are > predefined. So in the example you pointed for second invocation 'some value' > is not a defined mime type as it not matching with predefined types. The > decode_mime_type returns end pointer and parse_accept_body shall process > only with the valid mime type text/plain. > > another example with multiple mime types.., > Accept: text/html, multipart/mixed > In this case parse_accept_body returns 2 mime types as both are predefined > in the list. > > Thanks > Jijo > > > On Thu, Aug 18, 2011 at 5:58 PM, Bucur Marius < > bucur_marius_ovi...@yahoo.com> wrote: > > Hi Jijo, > > In my opinion, decode_mime_type is broken, and parse_accept_body does not > work as expected. > For example, this is a valid accept header: > > accept: text/plain;param=",some value". > > but the parse_accept_body will return -1 because the first return value of > decode_mime_type is ",some value\"". The second invocation will think "some > value\"" is a mime type, which obviously isn't. > > I must say I never saw such an accept header, but the standard permits it. > Indeed, a quick fix would be to ignore the return code when comma is found. > This must be done for other functions that call decode_mime_type > like has_body(mime) in textops. > > This is just my opinion, but I think this solution is a bit hackish since > the convention, the "promise" that decode_mime_type should respect is to > return a non-NULL, non-end pointer ONLY when there are more mime types in > the body. And it doesn't. > A lot of functions that call it rely on this. I think it is easier/more > elegant to fix the bug in the decode_mime_type then to change the function > convention in all callers. > Also, this might work for most callers, but parse_accept_body will still be > buggy, as I explained in the example above. > > Cheers, > Marius > > > From: Jijo > To: Bucur Marius > Sent: Thursday, August 18, 2011 10:48 AM > Subject: Re: [SR-Users] decode_mime_type error > > > Hi Marius, > > Right, the same function is used for Accept and Content-Type. > > I don't think there is any change required for parsing Accept. In case of > Accept the function decode_mime_type is called in a loop until it find all > the media types. On the returning from decode_mime_type(), the main function > parse_accept_xxx() checks the pointer is 'comma' or not. if its comma, then > the function decode_mime_type called again and find the remaining media > types. So i think the existing implementation for Parsing Accept is fine. > > The only change required here is not return error for comma while parsing > the Content-Type. > > Thanks > Jijo > > > On Thu, Aug 18, 2011 at 12:32 PM, Bucur Marius < > bucur_marius_ovi...@yahoo.com> wrote: > > Hello Jijo, > > > >You are right, multiple mime-types are not allowed. But it seems like > decode_mime_type had the purpose of also parsing the Accept header: > > > >Accept: text/html, image/jpeg, multipart > > > >hence the search for commas :). > >The only function that uses this feature and calls decode_mime_type in a > loop is parse_accept_body. The other functions that call decode_mime_type > just fail when returning ret != end, and since multiple mime types in > content-type are not allowed the behavior is fine. > >The bad thing is the Accept header can have mime parameters too (which can > contain comma). > > > >Accept= "Accept" HCOLON [ accept-range *(COMMA accept-range) > ] > >accept-range = media-range *(SEMI accept-param) > >media-range= ( "*/*" / ( m-type SLASH
[SR-Users] [regression] Message flags set in branch_route not saved into transaction
Hello,
It seems kamailio 3 does not save message flags set in branch route into the
transaction. In reply_route and failure_route the flag set in branch_route is
unset. In 1.4 this used to work. I would like to get that behaviour back, is
this possible?
Testscenario:
route {
setflag(0);
t_on_branch("1");
t_on_reply("1");
t_on_failure("1");
xlog("L_NOTICE", "[$rm] Request before relay: $mF");
t_relay();
}
branch_route[1] {
xlog("L_NOTICE", "[$rm] Branch begin: $mF");
setflag(8);
xlog("L_NOTICE", "[$rm] Branch end: $mF");
}
onreply_route[1] {
xlog("L_NOTICE", "[$rm] Reply ($rs) begin: $mF");
setflag(4);
xlog("L_NOTICE", "[$rm] Reply end: $mF");
}
failure_route[1] {
xlog("L_NOTICE", "[$rm] Failure ($T_reply_code): $mF");
}
Log output on 3.x:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0001
[INVITE] Reply end: 0011
[INVITE] Failure (408): 0011
Log output on 1.4:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0101
[INVITE] Reply end: 0111
[INVITE] Failure (408) begin: 0111
--
Greetings,
Alex Hermann
___
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] [regression] Message flags set in branch_route not saved into transaction
On Monday 22 August 2011, Alex Hermann wrote:
> It seems kamailio 3 does not save message flags set in branch route into
> the transaction. In reply_route and failure_route the flag set in
> branch_route is unset. In 1.4 this used to work. I would like to get that
> behaviour back, is this possible?
This patch seems to restore old functionality. Would this be ok to commit?
diff --git a/modules/tm/t_fwd.c b/modules/tm/t_fwd.c
index 30558ab..756e4b4 100644
--- a/modules/tm/t_fwd.c
+++ b/modules/tm/t_fwd.c
@@ -1510,6 +1510,8 @@ int t_forward_nonack( struct cell *t, struct sip_msg*
p_msg ,
clear_branches();
setbflagsval(0, backup_bflags);
+ /* update flags, if changed in branch route */
+ t->uas.request->flags = p_msg->flags;
/* don't forget to clear all branches processed so far */
> Testscenario:
>
> route {
> setflag(0);
>
> t_on_branch("1");
> t_on_reply("1");
> t_on_failure("1");
>
> xlog("L_NOTICE", "[$rm] Request before relay: $mF");
> t_relay();
> }
>
> branch_route[1] {
> xlog("L_NOTICE", "[$rm] Branch begin: $mF");
> setflag(8);
> xlog("L_NOTICE", "[$rm] Branch end: $mF");
> }
>
> onreply_route[1] {
> xlog("L_NOTICE", "[$rm] Reply ($rs) begin: $mF");
> setflag(4);
> xlog("L_NOTICE", "[$rm] Reply end: $mF");
> }
>
> failure_route[1] {
> xlog("L_NOTICE", "[$rm] Failure ($T_reply_code): $mF");
> }
>
> Log output on 3.x:
> [INVITE] Request begin:
> [INVITE] Request before relay: 0001
> [INVITE] Branch begin: 0001
> [INVITE] Branch end: 0101
> [INVITE] Reply (100) begin: 0001
> [INVITE] Reply end: 0011
> [INVITE] Failure (408): 0011
>
> Log output on 1.4:
> [INVITE] Request begin:
> [INVITE] Request before relay: 0001
> [INVITE] Branch begin: 0001
> [INVITE] Branch end: 0101
> [INVITE] Reply (100) begin: 0101
> [INVITE] Reply end: 0111
> [INVITE] Failure (408) begin: 0111
--
Greetings,
Alex Hermann
___
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] [sr-dev] [regression] Message flags set in branch_route not saved into transaction
On Monday 22 August 2011 16:43:43 Alex Hermann wrote: > On Monday 22 August 2011, Alex Hermann wrote: > > It seems kamailio 3 does not save message flags set in branch route into > > the transaction. In reply_route and failure_route the flag set in > > branch_route is unset. In 1.4 this used to work. I would like to get that > > behaviour back, is this possible? > > This patch seems to restore old functionality. Would this be ok to commit? Nevermind, i just found t_flush_flags(), which does exactly what i need. -- Alex Hermann ___ 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] New developer - Matthew Williams
Hello, a new person has joined our development squad - Matthew Williams, currently working for Flowroute, USA. He is already a developer of SEMS (SIP Express Media Server) and he going to add shortly, just in time for 3.2, some Json related extensions, including a JSON-RPC client module. His GIT commit user id is: mgw. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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] E2E ACK is not logged with siptrace modul kamailio
Hi Daniel 1. modul purple is not compiled for me. hal:/usr/local/src/sip-router/modules_k/purple# make CC (gcc) [M purple.so] clientpipe.o In file included from purple.h:23, from clientpipe.c:28: /usr/include/libpurple/status.h:93: error: expected specifier-qualifier-list before ‘gpointer’ make: *** [clientpipe.o] Error 1 There was a change in the libpurple API and the module was not updated for latest version of libpurple -- it has no active maintainer. However, this module is not compiled by default, if you need it either update it to latest purple library or use an older version of that library. Can you commit this to the git to avoid default compilation? diff --git a/pkg/kamailio/deb/debian/rules b/pkg/kamailio/deb/debian/rules index 30feea7..80c23d8 100755 --- a/pkg/kamailio/deb/debian/rules +++ b/pkg/kamailio/deb/debian/rules @@ -41,7 +41,7 @@ MODULES_SP= # Note: the order is important (should be in dependency order, the one # on which other depend first) PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ - ldap xml perl utils purple memcached tls \ + ldap xml perl utils memcached tls \ snmpstats carrierroute xmpp cpl lua python geoip Thanks, Misi ___ 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] E2E ACK is not logged with siptrace modul kamailio
El Mon, 22 Aug 2011 22:04:44 +0200 MÉSZÁROS Mihály escribió: > Hi Daniel > > >> > >> 1. > >> modul purple is not compiled for me. > >> hal:/usr/local/src/sip-router/modules_k/purple# make > >> CC (gcc) [M purple.so] clientpipe.o > >> In file included from purple.h:23, > >> from clientpipe.c:28: > >> /usr/include/libpurple/status.h:93: error: expected > >> specifier-qualifier-list before ‘gpointer’ > >> make: *** [clientpipe.o] Error 1 > > > > There was a change in the libpurple API and the module was not updated > > for latest version of libpurple -- it has no active maintainer. > > However, this module is not compiled by default, if you need it either > > update it to latest purple library or use an older version of that > > library. > > > Can you commit this to the git to avoid default compilation? > > diff --git a/pkg/kamailio/deb/debian/rules b/pkg/kamailio/deb/debian/rules > index 30feea7..80c23d8 100755 > --- a/pkg/kamailio/deb/debian/rules > +++ b/pkg/kamailio/deb/debian/rules > @@ -41,7 +41,7 @@ MODULES_SP= > # Note: the order is important (should be in dependency order, the one > # on which other depend first) > PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ > - ldap xml perl utils purple memcached tls \ > + ldap xml perl utils memcached tls \ > snmpstats carrierroute xmpp cpl lua python geoip > You have different debian folders based on different debian distros. Take a look to pkg/kamailio/deb/ If you use squeeze, you could perform: ln -s pkg/kamailio/deb/squeeze debian and then build kamailio. By default, if you don't symlink debian to a specific distro folder pkg/kamailio/deb/debian is used, which includes almost all the modules. Works fine in debian lenny and ubuntu lucid. ___ 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] Kamailio Freezes and no calls are processed
interestingly i am using memory only instead to read or write the DB in disk with carrierroute. Should i clear the AVP variables that i am using after in send the call out, maybe that is the problem?! Omar On Aug 22, 2011, at 8:04 AM, Morten Isaksen wrote: > Hi, > > On Sat, Aug 20, 2011 at 10:16 PM, Omar wrote: >> >> >> The only difference is we have added some AVPs variables to process, and >> kamailio stops processing new calls, is not regular, but seems is related to >> the number of calls received. >> No additional calls can be processed after certain time, or maybe some >> amount of calls. >> >> we were unable to isolate the problem, but kamailio.fifo is removed, which >> never happened before. >> No core dump created. >> >> did anybody have a similar issue. > > I had a similar issue some time ago. Look in the archives and you will > find som backtraces from gdb. > > The problem went away when I changed the dialog module not to write to > DB but only use memory. > > -- > Morten Isaksen > > ___ > 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 > ___ 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] RFC-5766 / RFC-6062 compliant TURN clients?
I know this might not be totally on-topic for the list, but I figured the list participants might have experience in this domain, so I'm lobbing it out there... I've got some situations where I'd like to connect users who are oftentimes sitting on very locked-down networks (ie, corporate networks) to some SIP-based VoIP infrastructure, but the idea of opening random UDP ports on the networks in question is a no-go. As a result, I'm experimenting with TURN over TCP or TLS as a solution to enable connectivity... however, I can't find any clients that implement the latest specs (X-Lite 4 appears to speak an older version of the TURN protocol; QJsip doesn't work for me; etc. etc.). Do folks here have any suggestions for TURN-compatible clients? I care mostly about PC for the time being (ie, just a proof of concept) but a PC/Mac/Linux solution would be great too. Thanks for any insights, --rafal ___ 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
