Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Greger,
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion.
The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Hi Marian!
Marian Dumitru wrote:
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion.
The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
AFAIK, CANCEL can happen both in-dialog and outside a dialog. This was a part of the verification we did when developing the ONsip.org reference config filers. I'm not sure if the discussion was on serusers or not, but as far as I remember, there is situation where CANCEL will be in-dialog and thus can take the loose route path, i.e. reINVITEs. As you will see in the ONsip.org config files, CANCEL is handled as an INVITE, but loose route test is done *before* the test on CANCEL to make sure that any in-dialog CANCELs are handled properly.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
... as long as you have done the same r-uri transformations as with the INVITE. g-)
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Hi Greger,
I know that the RFC doesn't specify if CANCEL is or not allows within the dialog - there were also some discussions on the sip-implementors mailing list about how to handle a CANCEL within the dialog. Anyhow, IMHO, even if allowed, CANCEL within the dialog makes less sense - to be honest I saw no implementation doing something like this.
Now, back to the original subject: as Anders describe his problem, is definitely not the case of a within the dialog CANCEL and we should come up with some hints relevant to his case and avoid confusing the guy more than necessary ;).
And regarding the t_relay() and CANCEL - there is no need to apply same RURI transformations as for INVITE - TM saves the INVITE outgoing RURI; when CANCEL comes, it is matched with an INVITE and the RURI for CANCEL is automatically taken from the INVITE transaction.
regards, Marian
Greger V. Teigre wrote:
Hi Marian!
Marian Dumitru wrote:
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion.
The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
AFAIK, CANCEL can happen both in-dialog and outside a dialog. This was a part of the verification we did when developing the ONsip.org reference config filers. I'm not sure if the discussion was on serusers or not, but as far as I remember, there is situation where CANCEL will be in-dialog and thus can take the loose route path, i.e. reINVITEs. As you will see in the ONsip.org config files, CANCEL is handled as an INVITE, but loose route test is done *before* the test on CANCEL to make sure that any in-dialog CANCELs are handled properly.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
... as long as you have done the same r-uri transformations as with the INVITE. g-)
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Marian Dumitru wrote:
I know that the RFC doesn't specify if CANCEL is or not allows within the dialog - there were also some discussions on the sip-implementors mailing list about how to handle a CANCEL within the dialog. Anyhow, IMHO, even if allowed, CANCEL within the dialog makes less sense - to be honest I saw no implementation doing something like this.
To be honest, I don't allow myself to have an opinion on that. :-) Being a practitioner and not an implementor I try to pick up what the implementors are saying. I thought CANCEL within dialog was (although not common) at least occuring.
Now, back to the original subject: as Anders describe his problem, is definitely not the case of a within the dialog CANCEL and we should come up with some hints relevant to his case and avoid confusing the guy more than necessary ;).
You're definitely right about that ;-) Sorry, Anders!
And regarding the t_relay() and CANCEL - there is no need to apply same RURI transformations as for INVITE - TM saves the INVITE outgoing RURI; when CANCEL comes, it is matched with an INVITE and the RURI for CANCEL is automatically taken from the INVITE transaction.
THAT I was not aware of. Thank you for telling me, it means that we can simplify the ONsip.org reference config files. :-D Excellent and thanks, Greger
regards, Marian
Greger V. Teigre wrote:
Hi Marian!
Marian Dumitru wrote:
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion. The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
AFAIK, CANCEL can happen both in-dialog and outside a dialog. This was a part of the verification we did when developing the ONsip.org reference config filers. I'm not sure if the discussion was on serusers or not, but as far as I remember, there is situation where CANCEL will be in-dialog and thus can take the loose route path, i.e. reINVITEs. As you will see in the ONsip.org config files, CANCEL is handled as an INVITE, but loose route test is done *before* the test on CANCEL to make sure that any in-dialog CANCELs are handled properly.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
... as long as you have done the same r-uri transformations as with the INVITE. g-)
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Hi all, The problem is that I don´t see a CANCEL coming from phone B when pressing the "hang-up" button. (A is calling B). I´ve used etheral to trace the messaging between clients and proxy and I never see the CANCEL from user B even though I´m pressing the "hang-up" button... Any idea why the CANCEL is never occuring? (The INVITEs, ACKs and BYEs are there.) Thanks, Anders
Greger V. Teigre skrev:
Marian Dumitru wrote:
I know that the RFC doesn't specify if CANCEL is or not allows within the dialog - there were also some discussions on the sip-implementors mailing list about how to handle a CANCEL within the dialog. Anyhow, IMHO, even if allowed, CANCEL within the dialog makes less sense - to be honest I saw no implementation doing something like this.
To be honest, I don't allow myself to have an opinion on that. :-) Being a practitioner and not an implementor I try to pick up what the implementors are saying. I thought CANCEL within dialog was (although not common) at least occuring.
Now, back to the original subject: as Anders describe his problem, is definitely not the case of a within the dialog CANCEL and we should come up with some hints relevant to his case and avoid confusing the guy more than necessary ;).
You're definitely right about that ;-) Sorry, Anders!
And regarding the t_relay() and CANCEL - there is no need to apply same RURI transformations as for INVITE - TM saves the INVITE outgoing RURI; when CANCEL comes, it is matched with an INVITE and the RURI for CANCEL is automatically taken from the INVITE transaction.
THAT I was not aware of. Thank you for telling me, it means that we can simplify the ONsip.org reference config files. :-D Excellent and thanks, Greger
regards, Marian
Greger V. Teigre wrote:
Hi Marian!
Marian Dumitru wrote:
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion. The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
AFAIK, CANCEL can happen both in-dialog and outside a dialog. This was a part of the verification we did when developing the ONsip.org reference config filers. I'm not sure if the discussion was on serusers or not, but as far as I remember, there is situation where CANCEL will be in-dialog and thus can take the loose route path, i.e. reINVITEs. As you will see in the ONsip.org config files, CANCEL is handled as an INVITE, but loose route test is done *before* the test on CANCEL to make sure that any in-dialog CANCELs are handled properly.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
... as long as you have done the same r-uri transformations as with the INVITE. g-)
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
Hi all, I´ve got a problem when trying to cancel an invite. The situation: A makes a call to B (INVITE). B press the "hang up" button. An here comes the problem. From As side, everything is OK, but from Bs side, the phone is still ringing... How can a solve this problem? Anyone?
Thanks, Anders
Hi Anders!
The CANCEL is sent by the caller. Thus, if A hangs up the call before B has answered, A is sending CANCEL to B.
regards, klaus
Anders Hansson wrote:
Hi all, The problem is that I don´t see a CANCEL coming from phone B when pressing the "hang-up" button. (A is calling B). I´ve used etheral to trace the messaging between clients and proxy and I never see the CANCEL from user B even though I´m pressing the "hang-up" button... Any idea why the CANCEL is never occuring? (The INVITEs, ACKs and BYEs are there.) Thanks, Anders
Greger V. Teigre skrev:
Marian Dumitru wrote:
I know that the RFC doesn't specify if CANCEL is or not allows within the dialog - there were also some discussions on the sip-implementors mailing list about how to handle a CANCEL within the dialog. Anyhow, IMHO, even if allowed, CANCEL within the dialog makes less sense - to be honest I saw no implementation doing something like this.
To be honest, I don't allow myself to have an opinion on that. :-) Being a practitioner and not an implementor I try to pick up what the implementors are saying. I thought CANCEL within dialog was (although not common) at least occuring.
Now, back to the original subject: as Anders describe his problem, is definitely not the case of a within the dialog CANCEL and we should come up with some hints relevant to his case and avoid confusing the guy more than necessary ;).
You're definitely right about that ;-) Sorry, Anders!
And regarding the t_relay() and CANCEL - there is no need to apply same RURI transformations as for INVITE - TM saves the INVITE outgoing RURI; when CANCEL comes, it is matched with an INVITE and the RURI for CANCEL is automatically taken from the INVITE transaction.
THAT I was not aware of. Thank you for telling me, it means that we can simplify the ONsip.org reference config files. :-D Excellent and thanks, Greger
regards, Marian
Greger V. Teigre wrote:
Hi Marian!
Marian Dumitru wrote:
CANCEL has nothing to do with loose route - and it will never hit he loose route. The Route ser is set only when the dialog is established (200 ok); and CANCEL happens *before* the dialog completion. The big idea with CANCEL is to take care to route it *exactly* as its INVITE.
AFAIK, CANCEL can happen both in-dialog and outside a dialog. This was a part of the verification we did when developing the ONsip.org reference config filers. I'm not sure if the discussion was on serusers or not, but as far as I remember, there is situation where CANCEL will be in-dialog and thus can take the loose route path, i.e. reINVITEs. As you will see in the ONsip.org config files, CANCEL is handled as an INVITE, but loose route test is done *before* the test on CANCEL to make sure that any in-dialog CANCELs are handled properly.
As a hint, if you use TM, t_relay() all the time will take care to send the CANCEL to same destination as INVITE.
... as long as you have done the same r-uri transformations as with the INVITE. g-)
regards, Marian
Greger V. Teigre wrote:
Most likely you don't handle the CANCEL messages correctly. May be that you don't do proper loose route handling. Take a look at the example configs (and the Getting Started document) at http://onsip.org/ You gain much be following the logic found there, they have been verified for all kinds of situations... g-)
Anders Hansson wrote:
> Hi all, > I´ve got a problem when trying to cancel an invite. > The situation: A makes a call to B (INVITE). B press the "hang up" > button. An here comes the problem. > From As side, everything is OK, but from Bs side, the phone is > still ringing... > How can a solve this problem? Anyone? > > Thanks, > Anders
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Anders Hansson -
Greger V. Teigre -
Klaus Darilion -
Llanos Serna García-Conde -
Marian Dumitru