6 Jul
2010
6 Jul
'10
7:39 p.m.
Hello all,
I need to work on particular ACK within the configuration of SER 0.9.9.
Firstly, I was thinking to make a difference using the CSeq field, but
it seems that the CSeq on ACK contains the ACK himself. Probably because
ACK is a request and not a response.
Would it be possible to proceed in another way?
Regards,
Adrien .L
6 Jul
6 Jul
8:10 p.m.
2010/7/6 inge <inge(a)legos.fr>fr>:
it seems that the CSeq on ACK contains the ACK
himself. Probably because
ACK is a request and not a response.
Please explain better what you mean as this text makes no lot of sense :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:16 p.m.
2010/7/6 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/7/6 inge <inge(a)legos.fr>fr>:
Ah, you meant the method within the CSeq header, then it's ok :)
Alex gave you the response.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
it seems that the CSeq on ACK contains the ACK
himself. Probably because
ACK is a request and not a response.
Please explain better what you mean as this text makes no lot of sense :) 
8:11 p.m.
Hi Adrien,
On 07/06/2010 10:39 AM, inge wrote:
Firstly, I was thinking to make a difference using the
CSeq field, but
it seems that the CSeq on ACK contains the ACK himself. Probably because
ACK is a request and not a response.
You are correct; ACK is a wholly different request and a separate
transaction from the exchange it is meant to acknowledge.
It is possible to differentiate end-to-end vs. hop-by-hop ACKs using
t_check_trans():
http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#t_check_trans
See its usage in the stock kamailio.cfg.
Note that 200 response to CANCEL does not generate an ACK, but a 487
response does, so your question is rather academic.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10:32 p.m.
Hi Alex,
It seems to be exactly what I want to do.
Unfortunately, I'm running SER 0.9.x and "t_check_trans" doesn't exist.
I was thinking also that I can probably do a "setflag" on an INVITE and
test it within the onreply-route. In that case, CANCEL should never came
into this call-flow.
Because, what I want to do exactly, is to handle a call for launching a
script. And so far I launched the script on ACK, therefore, the CANCEL
came in this case too.
I hope I'm clear.
Regards,
Adrien
Le mardi 06 juillet 2010 à 11:11 -0400, Alex Balashov a écrit :
Hi Adrien,
On 07/06/2010 10:39 AM, inge wrote:
Firstly, I was thinking to make a difference
using the CSeq field, but
it seems that the CSeq on ACK contains the ACK himself. Probably because
ACK is a request and not a response.
You are correct; ACK is a wholly different request and a separate
transaction from the exchange it is meant to acknowledge.
It is possible to differentiate end-to-end vs. hop-by-hop ACKs using
t_check_trans():
http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#t_check_trans
See its usage in the stock kamailio.cfg.
Note that 200 response to CANCEL does not generate an ACK, but a 487
response does, so your question is rather academic.
11:03 p.m.
I quickly tried this but I cannot used "exec" within the onreply_route.
So the problem stay the same. I don't know how to execute my script only
on established calls...
Any help/suggestion would be appreciate. Thank you !
Regards,
Adrien
Le mardi 06 juillet 2010 à 19:32 +0200, inge a écrit :
Hi Alex,
It seems to be exactly what I want to do.
Unfortunately, I'm running SER 0.9.x and "t_check_trans" doesn't
exist.
I was thinking also that I can probably do a "setflag" on an INVITE and
test it within the onreply-route. In that case, CANCEL should never came
into this call-flow.
Because, what I want to do exactly, is to handle a call for launching a
script. And so far I launched the script on ACK, therefore, the CANCEL
came in this case too.
I hope I'm clear.
Regards,
Adrien
Le mardi 06 juillet 2010 à 11:11 -0400, Alex Balashov a écrit :
Hi Adrien,
On 07/06/2010 10:39 AM, inge wrote:
_______________________________________________
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 Firstly, I was thinking to make a difference
using the CSeq field, but
it seems that the CSeq on ACK contains the ACK himself. Probably because
ACK is a request and not a response.
You are correct; ACK is a wholly different request and a separate
transaction from the exchange it is meant to acknowledge.
It is possible to differentiate end-to-end vs. hop-by-hop ACKs using
t_check_trans():
http://www.kamailio.org/docs/modules/3.0.x/modules/tm.html#t_check_trans
See its usage in the stock kamailio.cfg.
Note that 200 response to CANCEL does not generate an ACK, but a 487
response does, so your question is rather academic.
10:30 p.m.
Yes, why not, but in a few moment ;)
Does SER 3.0 released ? In the siprouter project ?
Le mercredi 07 juillet 2010 à 09:17 +0200, Klaus Darilion a écrit :
Am 06.07.2010 20:03, schrieb inge:
I quickly tried this but I cannot used
"exec" within the onreply_route.
So the problem stay the same. I don't know how to execute my script only
on established calls...
Upgrade to 3.0 ;-)
regards
klaus 
8 Jul
8 Jul
4 p.m.
Am 07.07.2010 19:30, schrieb inge:
Yes, why not, but in a few moment ;)
Does SER 3.0 released ? In the siprouter project ?
There is no ser/sip-router 3.0 "release". You have to checkout the
sip-router 3.0 branch from git if you want "ser" flavor of sip-router.
If you do not care about the flavor you can use "Kamailio" flavor for
sip-router, which has a real 3.0 "release". But if you need certain
ser-specific modules then you have to use sip-router 3.0 branch from git
as the ser-specific modules are not packaged into Kamailio release.
From code-point-of-view/stability there is no difference between
sip-router 3.0 branch and Kamailio 3.0. The only difference is that
Kamailio has "releases" - that means there is a tarball and debian
packages available too.
regards
Klaus
Le mercredi 07 juillet 2010 à 09:17 +0200, Klaus Darilion a écrit :
Am 06.07.2010 20:03, schrieb inge:
I quickly tried this but I cannot used
"exec" within the onreply_route.
So the problem stay the same. I don't know how to execute my script only
on established calls...
Upgrade to 3.0 ;-)
regards
klaus
8:44 p.m.
Very clear ! thanks.
Le jeudi 08 juillet 2010 à 13:00 +0200, Klaus Darilion a écrit :
Am 07.07.2010 19:30, schrieb inge:
Yes, why not, but in a few moment ;)
Does SER 3.0 released ? In the siprouter project ?
There is no ser/sip-router 3.0 "release". You have to checkout the
sip-router 3.0 branch from git if you want "ser" flavor of sip-router.
If you do not care about the flavor you can use "Kamailio" flavor for
sip-router, which has a real 3.0 "release". But if you need certain
ser-specific modules then you have to use sip-router 3.0 branch from git
as the ser-specific modules are not packaged into Kamailio release.
From code-point-of-view/stability there is no difference between
sip-router 3.0 branch and Kamailio 3.0. The only difference is that
Kamailio has "releases" - that means there is a tarball and debian
packages available too.
regards
Klaus
>
>
> Le mercredi 07 juillet 2010 à 09:17 +0200, Klaus Darilion a écrit :
>>
>> Am 06.07.2010 20:03, schrieb inge:
>>> I quickly tried this but I cannot used "exec" within the
onreply_route.
>>>
>>> So the problem stay the same. I don't know how to execute my script
only
>>> on established calls...
>>
>> Upgrade to 3.0 ;-)
>>
>> regards
>> klaus
>
5050
days inactive
5052
days old
9 comments
4 participants
participants (4)
-
Alex Balashov -
inge -
Iñaki Baz Castillo -
Klaus Darilion