Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
Hi Daniel,
we did something similar with Kamailio at Telefonica. But we chose a little different approach: Our OPTION-Request was in fact not associated with the Dialog at all, thus we did not care about correct CSeq or anything at all. We just sent the OPTIONs to the URI/Routes of the Dialog. All the device had to do, was to reply in one way or another to that OPTIONs Request. That worked pretty well with all kinds of Devices, ranging from Zyxel CPE's, Snom phones, AVM boxes, Asterisk, Symbian built-in and many more. Some very rare crappy network devices (i think, we saw this issue only once, it was a SIP-Client for Symbian, open-source, discontinued) however simply ignored the OPTIONs, but that was anyway a non-supported device. Probably, it would also ignore the OPTION request, if it was with a call-id, cseq, totag, etc. This is similar to the behaviour used by the Dispatcher module.
Just my $0,02, Carsten
2012/5/2 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
-- 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
Hello,
OPTIONS out of dialog are ok to detect if the device is gone (e.g., network problem -- good for dispatcher case where it needs only to figure out if gws are up).
Besides this one, I tried to figure out if the dialog is still active in the end device, by setting dialog's call-id, from-tag and to-tag (e.g., like when the device (crashed and) is restarted between keepalives -- it is still reachable but no dialog anymore). A request with unknown To-tag should be rejected with 481.
My doubts were related to what would be the behaviour of getting a lower cseq when dialog is active (callid, from-tag and to-tag mach).
Cheers, Daniel
On 5/2/12 2:52 PM, Carsten Bock wrote:
Hi Daniel,
we did something similar with Kamailio at Telefonica. But we chose a little different approach: Our OPTION-Request was in fact not associated with the Dialog at all, thus we did not care about correct CSeq or anything at all. We just sent the OPTIONs to the URI/Routes of the Dialog. All the device had to do, was to reply in one way or another to that OPTIONs Request. That worked pretty well with all kinds of Devices, ranging from Zyxel CPE's, Snom phones, AVM boxes, Asterisk, Symbian built-in and many more. Some very rare crappy network devices (i think, we saw this issue only once, it was a SIP-Client for Symbian, open-source, discontinued) however simply ignored the OPTIONs, but that was anyway a non-supported device. Probably, it would also ignore the OPTION request, if it was with a call-id, cseq, totag, etc. This is similar to the behaviour used by the Dispatcher module.
Just my $0,02, Carsten
2012/5/2 Daniel-Constantin Mierlamiconda@gmail.com:
Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
-- 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
Isn't it a responsibility of SIP session timer?
On Wednesday 02 May 2012 15:07:50 Daniel-Constantin Mierla wrote:
Hello,
OPTIONS out of dialog are ok to detect if the device is gone (e.g., network problem -- good for dispatcher case where it needs only to figure out if gws are up).
Besides this one, I tried to figure out if the dialog is still active in the end device, by setting dialog's call-id, from-tag and to-tag (e.g., like when the device (crashed and) is restarted between keepalives -- it is still reachable but no dialog anymore). A request with unknown To-tag should be rejected with 481.
My doubts were related to what would be the behaviour of getting a lower cseq when dialog is active (callid, from-tag and to-tag mach).
Cheers, Daniel
On 5/2/12 2:52 PM, Carsten Bock wrote:
Hi Daniel,
we did something similar with Kamailio at Telefonica. But we chose a little different approach: Our OPTION-Request was in fact not associated with the Dialog at all, thus we did not care about correct CSeq or anything at all. We just sent the OPTIONs to the URI/Routes of the Dialog. All the device had to do, was to reply in one way or another to that OPTIONs Request. That worked pretty well with all kinds of Devices, ranging from Zyxel CPE's, Snom phones, AVM boxes, Asterisk, Symbian built-in and many more. Some very rare crappy network devices (i think, we saw this issue only once, it was a SIP-Client for Symbian, open-source, discontinued) however simply ignored the OPTIONs, but that was anyway a non-supported device. Probably, it would also ignore the OPTION request, if it was with a call-id, cseq, totag, etc. This is similar to the behaviour used by the Dispatcher module.
Just my $0,02, Carsten
2012/5/2 Daniel-Constantin Mierlamiconda@gmail.com:
Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
-- 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
Hello,
On 5/2/12 3:14 PM, Sergey Okhapkin wrote:
Isn't it a responsibility of SIP session timer?
sip session timer support has to be implemented in end UA devices. To do it in the server side, it will require a b2bua. The sst module in kamailio adds headers to require UA to do re-INVITES based on session timer specs, but it does not do them itself.
Cheers, Daniel
On Wednesday 02 May 2012 15:07:50 Daniel-Constantin Mierla wrote:
Hello,
OPTIONS out of dialog are ok to detect if the device is gone (e.g., network problem -- good for dispatcher case where it needs only to figure out if gws are up).
Besides this one, I tried to figure out if the dialog is still active in the end device, by setting dialog's call-id, from-tag and to-tag (e.g., like when the device (crashed and) is restarted between keepalives -- it is still reachable but no dialog anymore). A request with unknown To-tag should be rejected with 481.
My doubts were related to what would be the behaviour of getting a lower cseq when dialog is active (callid, from-tag and to-tag mach).
Cheers, Daniel
On 5/2/12 2:52 PM, Carsten Bock wrote:
Hi Daniel,
we did something similar with Kamailio at Telefonica. But we chose a little different approach: Our OPTION-Request was in fact not associated with the Dialog at all, thus we did not care about correct CSeq or anything at all. We just sent the OPTIONs to the URI/Routes of the Dialog. All the device had to do, was to reply in one way or another to that OPTIONs Request. That worked pretty well with all kinds of Devices, ranging from Zyxel CPE's, Snom phones, AVM boxes, Asterisk, Symbian built-in and many more. Some very rare crappy network devices (i think, we saw this issue only once, it was a SIP-Client for Symbian, open-source, discontinued) however simply ignored the OPTIONs, but that was anyway a non-supported device. Probably, it would also ignore the OPTION request, if it was with a call-id, cseq, totag, etc. This is similar to the behaviour used by the Dispatcher module.
Just my $0,02, Carsten
2012/5/2 Daniel-Constantin Mierlamiconda@gmail.com:
Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
-- 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
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
If SIP clients are standard conform then it should work.
It may happen that crappy clients terminate the call after sending a failure response (I have not seen that yet, but by having seens so many crappy clients I would not be surprised if such clients exist).
regards Klaus
On 02.05.2012 14:31, Daniel-Constantin Mierla wrote:
Hello,
several days ago, just before freezing the development for v3.3.0, I added to dialog module the option to send keep alives for ongoing calls in order to detect if caller/callee is gone.
SIP specs require to increment the CSeq for requests within dialog, but because the keep alives are sent from the sip server, it would results de-synchronization of the CSeq values hold in phones themselves (e.g., a BYE created by caller/callee after a keep alive will be with lower cseq than the other side would expect and accept). One solution would be to update cseq when BYE passes the server to the right value. This implies more processing, as a call can have many re-INVITEs or other requests within dialog sent by caller/callee, including periodic updates to database to store cseq numbers.
So I went for a different approach, like stated in subject -- let's see your opinion if you think is going to work. Practically the keep alives will be OPTIONS with CSeq equal or lower than the last valid value (e.g., the cseq of the INVITE creating the call).
If the caller/callee is gone, that is simply, the OPTION will be timed out and dialog module will send BYE.
If the caller/callee are reachable, but for some reason the call was destroyed (e.g., a crash and restart meanwhile), since there is a To-tag, the OPTIONS should get a 481 Call/Leg transaction does not exists. Again, a case when kamailio will end the dialog.
The one to be discussed here would be caller/callee are still on the call.
Based on RFC (and the feedback from people on another thread here), a requests coming within a dialog with lower CSEq should be replies with 500. CSeq numbers are still ok in both sides (note that requests with lower CSeq can happen in reality, like two fast re-INVITEs sent over UDP, the second arriving first due to network transmission).
I tested with snom phones and jitsi so far, seems to be a working solution (well, jitsi was replying 500 after 20secs to keep alive OPTIONS request, not sure for what reason, just reported back to the project).
Is anyone here seeing any possible issues with the approach?
Call are ended by dialog, with proper CSeq in the BYE, after 10seconds from the moment 408 or 481 is received, no other replies are taken in consideration for ending the dialog from server side.
Cheers, Daniel
-
Carsten Bock -
Daniel-Constantin Mierla -
Klaus Darilion -
Sergey Okhapkin