[SR-Users] Late parallel forking

[Guillaume Bour]

Hi,

I would like to do some kind of "late parallel forking" (see the example below).
Is there a way to do such thing with Kamailio ?

Here is an example:
. A call B
. B device 1 is connected so INVITE is forwarded to it
. B device 2 registers succesfully
. as device 1 as not yet answered and INVITE transaction is not expired, I want INVITE message
to be forwarded to device 2 (so both are ringing)


Regards,
Guillaume Bour

[Daniel-Constantin Mierla]

Hello,

you may get similar results using t_cancel_callid(():
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272

For each call you have to store the call-id, cseq and the target user
somehow (e.g., using htable).

Then, when you have a registration, see if the user has an ongoing call
towards him/her. If yes, cancel that transaction and you end up in
failure route. Based the flags, you can see it was canceled on purpose
and can do another lookup location to get now two branches.

You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location again.

The behavior is not exactly the same as you requested, as first branch
is canceled. But given that the branch will be called again in short
time, the user might not notice anything in terms of ringing interruption.

Alternative is of course writing a function for it, at the end it is on
of the big benefits of open source.

Cheers,
Daniel

Post by Guillaume Bour
Hi,
I would like to do some kind of "late parallel forking" (see the example below).
Is there a way to do such thing with Kamailio ?
. A call B
. B device 1 is connected so INVITE is forwarded to it
. B device 2 registers succesfully
. as device 1 as not yet answered and INVITE transaction is not expired, I want INVITE message
to be forwarded to device 2 (so both are ringing)
Regards,
Guillaume Bour
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Guillaume Bour]

Thanks Daniel,

I tried your solution, and it works great!
Not sure it completely fill our needs though, so we'll probably write our
own module (and push it to the community of course :)

Regards,
Guillaume

Post by Daniel-Constantin Mierla
Hello,
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272
For each call you have to store the call-id, cseq and the target
user somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing
call towards him/her. If yes, cancel that transaction and you end up
in failure route. Based the flags, you can see it was canceled on
purpose and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location
again.
The behavior is not exactly the same as you requested, as first
branch is canceled. But given that the branch will be called again
in short time, the user might not notice anything in terms of
ringing interruption.
Alternative is of course writing a function for it, at the end it is
on of the big benefits of open source.
Cheers,
Daniel

Post by Guillaume Bour
Hi,
I would like to do some kind of "late parallel forking" (see the example below).
Is there a way to do such thing with Kamailio ?
. A call B
. B device 1 is connected so INVITE is forwarded to it
. B device 2 registers succesfully
. as device 1 as not yet answered and INVITE transaction is not expired, I want INVITE message
to be forwarded to device 2 (so both are ringing)
Regards,
Guillaume Bour
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Daniel-Constantin Mierla]

Hello,

Post by Guillaume Bour
Thanks Daniel,
I tried your solution, and it works great!

welcome :-) -- surprising how some odd workarounds are found already
implemented.

Post by Guillaume Bour
Not sure it completely fill our needs though, so we'll probably write our
own module (and push it to the community of course :)

Looking forward to this contribution, would be useful to have.

Cheers,
Daniel

Post by Guillaume Bour
Regards,
Guillaume

Post by Daniel-Constantin Mierla
Hello,
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272
For each call you have to store the call-id, cseq and the target
user somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing
call towards him/her. If yes, cancel that transaction and you end up
in failure route. Based the flags, you can see it was canceled on
purpose and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location
again.
The behavior is not exactly the same as you requested, as first
branch is canceled. But given that the branch will be called again
in short time, the user might not notice anything in terms of
ringing interruption.
Alternative is of course writing a function for it, at the end it is
on of the big benefits of open source.
Cheers,
Daniel

Post by Guillaume Bour
Hi,
I would like to do some kind of "late parallel forking" (see the example below).
Is there a way to do such thing with Kamailio ?
. A call B
. B device 1 is connected so INVITE is forwarded to it
. B device 2 registers succesfully
. as device 1 as not yet answered and INVITE transaction is not expired, I want INVITE message
to be forwarded to device 2 (so both are ringing)
Regards,
Guillaume Bour
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

[Klaus Darilion]

Post by Daniel-Constantin Mierla
Hello,
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272
For each call you have to store the call-id, cseq and the target user
somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing call
towards him/her. If yes, cancel that transaction and you end up in
failure route. Based the flags, you can see it was canceled on purpose
and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location again.
The behavior is not exactly the same as you requested, as first branch
is canceled. But given that the branch will be called again in short
time, the user might not notice anything in terms of ringing interruption.

The problem may be that there is a missed called on device 1. Maybe this
can be avoided by adding the reason header with "cause=200" if the
client supports it.

regards
Klaus

[Olle E. Johansson]

Post by Klaus Darilion

Post by Daniel-Constantin Mierla
Hello,
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272
For each call you have to store the call-id, cseq and the target user
somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing call
towards him/her. If yes, cancel that transaction and you end up in
failure route. Based the flags, you can see it was canceled on purpose
and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location again.
The behavior is not exactly the same as you requested, as first branch
is canceled. But given that the branch will be called again in short
time, the user might not notice anything in terms of ringing interruption.

The problem may be that there is a missed called on device 1. Maybe this
can be avoided by adding the reason header with "cause=200" if the
client supports it.

That is a good idea - but how do you add that to a CANCEL generated
by Kamailio using this function?

/O

[Daniel-Constantin Mierla]

Post by Olle E. Johansson

Post by Klaus Darilion

Post by Daniel-Constantin Mierla
Hello,
- http://kamailio.org/docs/modules/stable/modules/tmx.html#idm8272
For each call you have to store the call-id, cseq and the target user
somehow (e.g., using htable).
Then, when you have a registration, see if the user has an ongoing call
towards him/her. If yes, cancel that transaction and you end up in
failure route. Based the flags, you can see it was canceled on purpose
and can do another lookup location to get now two branches.
You would need to store the initial caller address before looking up
location, revert to it in failure route before looking up location again.
The behavior is not exactly the same as you requested, as first branch
is canceled. But given that the branch will be called again in short
time, the user might not notice anything in terms of ringing interruption.

The problem may be that there is a missed called on device 1. Maybe this
can be avoided by adding the reason header with "cause=200" if the
client supports it.

That is a good idea - but how do you add that to a CANCEL generated
by Kamailio using this function?

There is support for reason header in CANCEL generated by TM -- not sure
it is done for this case but should not be a big patch, as the same
internal function is executed to send this cancel (a parameter should be
set for the reason header, iirc).

Cheers,
Daniel