Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
At 15:37 12/03/2008, Maxim Sobolev wrote: Dan Pascu wrote: Anyway, examples are many and I'm sure people can even find more practical ones. The main reason for all of them being possible, is the fact that a CANCEL is no longer really canceling the call under these circumstances, and that the user is stripped from it's ability to control if a call should end or not before being setup, by random conditions (network packet loss) or purposeful abuses of the protocol behavior. All this has nothing to do with the SIP, really. It just illustrates the point that SIP proxy is bad choice for real-time VoIP accounting. That's a very true statement indeed. In fact a PROXy can server as an aPROXimation of what's going on and that's it. If you use B2BUA, all those concerns go away, as you will get two separate SIP calls, so that your ingress call is isolated from any issues with egress, such as packet loss and so on. My most favorite choice is producing reliable accounting data from PSTN gateways. In the end that's where the paid-for service is provided from, and it can include most complete data (including Q.931 error causes if you wish, and media QoS statistics) -jiri Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Serdev mailing list [EMAIL PROTECTED] http://lists.iptel.org/mailman/listinfo/serdev -- Jiri Kuthanhttp://iptel.org/~jiri/ ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Thursday 13 March 2008, Juha Heinanen wrote: Dan Pascu writes: Do you have any suggestion how can this be at least addressed, if not solved, using the current RFC framework? i haven't followed the proposed solutions in detail, but the solution does not need to be RFC complaint as long as it does not assume any changes in rfc complaint UAs. I thought this through, and to be honest, I do not think this can be solved without cooperation from the UAs. Even more it can't be solved without adding something new to the current framework the RFC provides. Consider the case where the caller sends the CANCEL and the callee at the same time sends the 200 OK. They will intersect in the proxy, but when the callee receives the CANCEL it'll ignore it under the current RFC assumptions about the call setup, because once it has sent the 200 OK, it considers the session as started. Even if the caller ignores the 200 OK or use an ACK+BYE to end the session, the session is still established. Unless something is changed in the equation there is no way for the caller/proxy to indicate to the callee that it should stop because a CANCEL was already received. This new thing, can be something that changes the way processing is supposed to happen with the existing RFC specifications. For example: 1. A CANCEL could be accepted by the callee even after a 200 OK, but before the ACK and its meaning in this context would be that the call was just CANCELED before having a chance to be fully set up and it should be dropped. 2. Some new method like the proposed NACK, which could have the same meaning. Personally I would go with choice 1, as it diverges less from the current specs and only extends the meaning of the CANCEL a bit, otherwise it has the same effect as the 2nd which would require the addition of a new method that is harder to get done. But as you can see both need the cooperation of the UA. Otherwise we could apply 1 right now in the proxy, but it would most likely be completely ignored by all UAs out there. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Thursday 13 March 2008, Rick van Rein wrote: Dan, But, to get involved with the discussion itself, what you are trying to do is deny relativity. I don't think I am. I'm not speaking of the race condition case where the 200 OK and the CANCEL arrive at the same time and it order of them can be viewed as relative. I can live with the uncertainty in that case and users can live with that as well. The issue I raised is with a 200 OK that can come much later (10-15 seconds later) and still establish a connection even though a CANCEL was issued 10 seconds before it. There is no relativity involved there, the order of events is the same for all observers involved, yet a user request to cancel the call was ignored because some provisional reply was not received. No user would accept that he has no control over establishing a call and that his choice to end it is ignored. What I would find useful in this case is that once a CANCEL has arrived, all call setup activities should cease on all branches, with or without provisional replies and if a 200 OK comes later it should be ignored and instead a CANCEL should be forwarded to indicate that the 200 OK is late and is no longer accepted by the originator. Maybe this is not specified by the RFC, but I believe it to be a much better choice than to forward the 200 OK, then ACK it and then send a BYE to close the call. Also technically, you could setup a maximum to the amount of money to be taken from a customer's account for things like call setup or minutes. If the numbers published their cost somewhere, you could simply deny their use. We have a phone system in the Netherlands with special suspect number ranges (090x areacodes). And our operators always mention the price of those numbers along with the number itself. Legally, I am tempted to say that the caller took the initiative to ring a number and he should have known better than to ring such an expensive number. But that thought may be the result of living in the Netherlands, where operators publish the call price alongside their numbers. I don't know how to say this, because I already said it more than 5 times. The issue is _NOT_ about money or a misplaced accounting entry I can correct by hand. The issue is about the user not having control over canceling his call. Consider this example that involved no money or highly priced destinations. I call a support center for some service, which is listed as being free of charge. An initial prompt informs me that if I accept the call, the call will be recorded and my SIP address as well as any information I passed on during the conversation can be shared with the operator's partners for marketing purposes. I do not accept the terms and cancel the call, but the system ignores my cancel and still connects me to the service, even though it is just to issue a BYE to close it, but I still got connected like if I accepted the terms. I had no way of knowing in advance about the terms, there is no price listed anywhere, so how can I chose not to dial the number in the first place? Do you want to spend you time cleaning this situation up, looking up for SIP experts that can testify that you were not at fault, that there was no race condition, that is just a flaw in the protocol and then trying to get that operator to remove you from their databases and whomever they gave those databases to, when the wrong is already done and you are already targeted by marketing campains that ring your phone at whatever time they please? On a different perspective, how would you feel if your mobile phone operator would tell you that pressing the end call button on your mobile may be ignored? Would you want to use such a service? Because with SIP, that is a very possibility. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Thursday 13 March 2008, Alex Hermann wrote: I was expressing more of an idea for an alternate approach, out of the RFC specs, because as it is the RFC seems to not be able to cover this case. What I meant, is that if the CANCEL is sent after a 200 OK, but before the ACK, it should mean that the call is no longer desired (it was canceled already). The INVITE can't be cancelled anymore because the transaction is deleted in the UAS after sending the 200 OK (and it is not allowed to send more than 1 final response), so there is no way to indicate that the INVITE is cancelled. With the current RFC specs, yes. But if the CANCEL would be allowed to be sent until the dialog is confirmed by the ACK, then the UAS would be required to keep the transaction around until ACK-ed and could process this case. If you looking for way to extend/change the SIP rfc's, why not allow a BYE instead of the ACK, or introduce a NACK request to get the wanted behaviour? I'm sure there is more than one way to do this. The NACK sounds the simplest and least disruptive of all the ideas mentioned so far. Of course as it is now, any device that is RFC conformant will ignore that CANCEL, but if this callflow would be a valid one, devices could cope with scenarios like the ones discussed in this thread. What happens (in practice) if you send a BYE instead of the ACK? I don't know, but a BYE sounds too much like the sessions is already established and needs to be closed. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu wrote: On Thursday 13 March 2008, Alex Hermann wrote: I was expressing more of an idea for an alternate approach, out of the RFC specs, because as it is the RFC seems to not be able to cover this case. What I meant, is that if the CANCEL is sent after a 200 OK, but before the ACK, it should mean that the call is no longer desired (it was canceled already). The INVITE can't be cancelled anymore because the transaction is deleted in the UAS after sending the 200 OK (and it is not allowed to send more than 1 final response), so there is no way to indicate that the INVITE is cancelled. With the current RFC specs, yes. But if the CANCEL would be allowed to be sent until the dialog is confirmed by the ACK, then the UAS would be required to keep the transaction around until ACK-ed and could process this case. The INVITE transaction IS kept around in the UAS until ACK is received. But yes, the dialog is created when 200 OK is sent. If you looking for way to extend/change the SIP rfc's, why not allow a BYE instead of the ACK, or introduce a NACK request to get the wanted behaviour? I'm sure there is more than one way to do this. The NACK sounds the simplest and least disruptive of all the ideas mentioned so far. The NACK may work, but it would be a very big and fundamental RFC change. And it would be very disruptive, because it is not compatible with the current RFC. How about my proposal to stop resending INVITE and start resending CANCEL in a proxy if a provisional response is not received? May be I am wrong, but I think it can help and it is really a minor change in RFC that in fact preserves compatibility. Of course as it is now, any device that is RFC conformant will ignore that CANCEL, but if this callflow would be a valid one, devices could cope with scenarios like the ones discussed in this thread. What happens (in practice) if you send a BYE instead of the ACK? I don't know, but a BYE sounds too much like the sessions is already established and needs to be closed. BYE is another transaction. BYE in this situation may, just may, work for some implementations. But, for example, it will not be pretty for proxies that work on transaction level. Terminating the dialog with BYE does not mean that the INVITE transaction will be canceled. Regards, Anatoly. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Thursday 13 March 2008, Anatoly Pidruchny wrote: The NACK may work, but it would be a very big and fundamental RFC change. And it would be very disruptive, because it is not compatible with the current RFC. It is probably one of the simplest ways to solve the conflict. About how disruptive it is, I would say that is just an extension. If a device doesn't support it it can ignore it, as it doesn't change any other call flows, it only fixes one that the current RFC specs can't. How about my proposal to stop resending INVITE and start resending CANCEL in a proxy if a provisional response is not received? May be I am wrong, but I think it can help and it is really a minor change in RFC that in fact preserves compatibility. This still doesn't resolve the conflict between the CANCEL and 200 OK. Even if you start transmitting a CANCEL, still a 200 OK for the initial INVITE can come after that because there is packet loss or the 200 OK was already send before you started to transmit the CANCEL and then you can't handle the situation using the current mechanisms the RFC provides. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Thursday 13 March 2008, Juha Heinanen wrote: Dan Pascu writes: I'm sure there is more than one way to do this. The NACK sounds the simplest and least disruptive of all the ideas mentioned so far. anything that requires changes in SIP UAs is a very long term solution. That is very obvious. Not only it can take a long time to get a consensus on a solution, it would take even longer to get it implemented in UAs. in practice, we only have power to affect on how openser proxy is behaving. Do you have any suggestion how can this be at least addressed, if not solved, using the current RFC framework? -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu writes: Do you have any suggestion how can this be at least addressed, if not solved, using the current RFC framework? i haven't followed the proposed solutions in detail, but the solution does not need to be RFC complaint as long as it does not assume any changes in rfc complaint UAs. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
What it is not clear to me in this case, is what does the proxy do if there is no 1xx reply but the 200 OK comes in directly (after the CANCEL was received and the INVITE continued to be retransmitted). In this case it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK but before confirming it with the ACK, or after a 200 OK it must send an ACK followed by a BYE? What about accounting in the later case, because the call will appear as one that was successfully setup and with 0 second duration while in reality it was canceled. The later case also implies that the proxy is no longer a proxy but a b2bua since it initiates dialogs on its own, dialogs that differ from what the call originator has sent to the proxy. On Monday 10 March 2008, Klaus Darilion wrote: From the sip-implementors list - looks like Maxim is right. regards klaus Robert Sparks schrieb: Part of why it does this is to deal with the case that the first INVITE the proxy sent actually got somewhere, but its response was lost. The retransmission will stimulate a retransmission of the response, letting you move forward to sending the CANCEL from the proxy. RjS On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote: The INVITE transaction must still complete independent of the CANCEL. So the proxy would continue to re-transmit the INVITE. If the proxy does receive a provisional response, it would then stop retransmissions and send the CANCEL down stream. If timer B fired, it would send a 408 response to the INVITE. Note that the proxy should respond to the CANCEL with 200 OK when it receives it since the INVITE transaction is in progress. cheers, (-:bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To: [EMAIL PROTECTED] Subject: [Sip-implementors] CANCEL retransmisson question of no provisional response! Hi! Could someone help me please with this question. Scenario: A transaction-stateful proxy forwards the INVITE request. The proxy does not receive a provisional response, thus starts retransmissions. Now, the caller CANCELs the call. How is the proxy supposed to handle this? Does the proxy still have to retransmit the INVITE or can it stop retransmitting the INVITE? From logical point of view I would think that the proxy should stop the retransmissions, but from Figure 5 in RFC 3261 it looks like the only way to come from Calling state to Terminated state is waiting for Timer B fires (as there is no provisional response yet). thanks klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
There is no ambiguity and no B2B functionality is needed. The call is only officially cancelled when originating UA gets final negative reply to INVITE transaction. Sending CANCEL is not guaranteed to result in final negative reply to INVITE, RFC is very specific on that and any device/software that assumes otherwise is broken. In the situation that you are describing, the proxy should forward INVITE's final positive 200 OK to the originating party and forget about outgoing CANCEL (initiating this transaction obviously makes no sense since the UAC INVITE transaction is already completed). The originating UA at this point should have not received any final reply on its UAC INVITE transaction (that's the very reason why fake 487 should never be generated when branches are pending), so that it is prepared to receive INVITE's 200 OK, send end-to-end ACK and follow up with BYE if it still wants to end up dialog. This case is no different than when UA sends INVITE, gets provisional reply, sends CANCEL, but gets 200 OK to the INVITE transaction before CANCEL gets to its final destination due to network/processing delay. Any RFC-compliant device/software should be able to deal it already. And there is no problem in the accounting either, since answering party actually has answered the call, so that technically it went through. If you think about it a little longer such situation is unavoidable in any signaling network that has non-zero signal propagation/processing delay, which basically means any physical network. There will always be possibility that answering party answers when initiating party has already hanged up but that signal is still in the transit. In fact situation with the previously discussed behaviour relying on no-ACK timeout was much worse, since in that case originating party would consider call as successfully canceled, while for the answering it would be established with non-zero duration required for the no-ACK timeout to fire, which is usually 30 seconds. Dan Pascu wrote: What it is not clear to me in this case, is what does the proxy do if there is no 1xx reply but the 200 OK comes in directly (after the CANCEL was received and the INVITE continued to be retransmitted). In this case it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK but before confirming it with the ACK, or after a 200 OK it must send an ACK followed by a BYE? What about accounting in the later case, because the call will appear as one that was successfully setup and with 0 second duration while in reality it was canceled. The later case also implies that the proxy is no longer a proxy but a b2bua since it initiates dialogs on its own, dialogs that differ from what the call originator has sent to the proxy. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
It makes sense, however I still have reservations that accounting is handled as one would expect in this case. While all the approach you details here makes sense from a technical point of view as per RFC requirements, then end user experience is different. Consider the case where I call a number that has a high setup fee, say 5 euros only to connect even if the call duration is 0. While I wait for this call to setup, I receive no provisional reply, so my phone is not ringing. Then I change my mind and hang-up the phone. My end user expectation is that the call was not setup and I have nothing to pay for. But in reality, if there is network packet loss and a scenario like the one described before happens, the call will actually be setup and show up like a 0 second call with a 5 euro price, not as a canceled call. On Wednesday 12 March 2008, Maxim Sobolev wrote: There is no ambiguity and no B2B functionality is needed. The call is only officially cancelled when originating UA gets final negative reply to INVITE transaction. Sending CANCEL is not guaranteed to result in final negative reply to INVITE, RFC is very specific on that and any device/software that assumes otherwise is broken. In the situation that you are describing, the proxy should forward INVITE's final positive 200 OK to the originating party and forget about outgoing CANCEL (initiating this transaction obviously makes no sense since the UAC INVITE transaction is already completed). The originating UA at this point should have not received any final reply on its UAC INVITE transaction (that's the very reason why fake 487 should never be generated when branches are pending), so that it is prepared to receive INVITE's 200 OK, send end-to-end ACK and follow up with BYE if it still wants to end up dialog. This case is no different than when UA sends INVITE, gets provisional reply, sends CANCEL, but gets 200 OK to the INVITE transaction before CANCEL gets to its final destination due to network/processing delay. Any RFC-compliant device/software should be able to deal it already. And there is no problem in the accounting either, since answering party actually has answered the call, so that technically it went through. If you think about it a little longer such situation is unavoidable in any signaling network that has non-zero signal propagation/processing delay, which basically means any physical network. There will always be possibility that answering party answers when initiating party has already hanged up but that signal is still in the transit. In fact situation with the previously discussed behaviour relying on no-ACK timeout was much worse, since in that case originating party would consider call as successfully canceled, while for the answering it would be established with non-zero duration required for the no-ACK timeout to fire, which is usually 30 seconds. Dan Pascu wrote: What it is not clear to me in this case, is what does the proxy do if there is no 1xx reply but the 200 OK comes in directly (after the CANCEL was received and the INVITE continued to be retransmitted). In this case it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK but before confirming it with the ACK, or after a 200 OK it must send an ACK followed by a BYE? What about accounting in the later case, because the call will appear as one that was successfully setup and with 0 second duration while in reality it was canceled. The later case also implies that the proxy is no longer a proxy but a b2bua since it initiates dialogs on its own, dialogs that differ from what the call originator has sent to the proxy. Regards, -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu schrieb: What it is not clear to me in this case, is what does the proxy do if there is no 1xx reply but the 200 OK comes in directly (after the CANCEL was received and the INVITE continued to be retransmitted). In this case it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK No. If i got it right, if the proxy receives a CANCEL, but does not have got a response from the UAS, it still must retransmit the and it must not send 487 back to the client. The proxy has to: - if UAS does not responses at all - after timer B it will send 487 (or 408?)to the UAC - if the UAS sends a provisional response - send CANCEL to UAS and forward 487 to UAC - if the UAS sends 200 OK -- forward 200 ok to UAC regards klaus but before confirming it with the ACK, or after a 200 OK it must send an ACK followed by a BYE? What about accounting in the later case, because the call will appear as one that was successfully setup and with 0 second duration while in reality it was canceled. The later case also implies that the proxy is no longer a proxy but a b2bua since it initiates dialogs on its own, dialogs that differ from what the call originator has sent to the proxy. On Monday 10 March 2008, Klaus Darilion wrote: From the sip-implementors list - looks like Maxim is right. regards klaus Robert Sparks schrieb: Part of why it does this is to deal with the case that the first INVITE the proxy sent actually got somewhere, but its response was lost. The retransmission will stimulate a retransmission of the response, letting you move forward to sending the CANCEL from the proxy. RjS On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote: The INVITE transaction must still complete independent of the CANCEL. So the proxy would continue to re-transmit the INVITE. If the proxy does receive a provisional response, it would then stop retransmissions and send the CANCEL down stream. If timer B fired, it would send a 408 response to the INVITE. Note that the proxy should respond to the CANCEL with 200 OK when it receives it since the INVITE transaction is in progress. cheers, (-:bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To: [EMAIL PROTECTED] Subject: [Sip-implementors] CANCEL retransmisson question of no provisional response! Hi! Could someone help me please with this question. Scenario: A transaction-stateful proxy forwards the INVITE request. The proxy does not receive a provisional response, thus starts retransmissions. Now, the caller CANCELs the call. How is the proxy supposed to handle this? Does the proxy still have to retransmit the INVITE or can it stop retransmitting the INVITE? From logical point of view I would think that the proxy should stop the retransmissions, but from Figure 5 in RFC 3261 it looks like the only way to come from Calling state to Terminated state is waiting for Timer B fires (as there is no provisional response yet). thanks klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu schrieb: That is not the case. If a 200 OK happens to come at the same time with the CANCEL and there is a race condition and the call does get setup and charged, I can explain my subscriber that he happened to put the call on hook at the same time it was answered by the other side and it was just the fact that it was answered while he was placing it on hook. He can understand that. But if I tell my subscriber that he has put the phone on hook effectively canceling the call, but a 200 OK came out of nowhere 10 seconds later and did setup a session despite the user indicating it has no intention to carry on with it, that there was no race condition, but simply the system ignored his request because there was packet loss and the RFC mandates that it has to wait for some timers to expire, that he won't understand. You are right! Try to tell your subscribers that your wonderful next generation VoIP system takes away their ability to cancel a call, that it may randomly (based on network packet loss) decide to setup a call at a later time despite the user canceling it, and do this based not on an understandable race condition situations, but on purpose, and see how many of them would want to use your system. Dan, you should post this example on the SIP-implementors mailing list. I wonder what the SIP experts will say to this examples. regards klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu wrote: Anyway, examples are many and I'm sure people can even find more practical ones. The main reason for all of them being possible, is the fact that a CANCEL is no longer really canceling the call under these circumstances, and that the user is stripped from it's ability to control if a call should end or not before being setup, by random conditions (network packet loss) or purposeful abuses of the protocol behavior. All this has nothing to do with the SIP, really. It just illustrates the point that SIP proxy is bad choice for real-time VoIP accounting. If you use B2BUA, all those concerns go away, as you will get two separate SIP calls, so that your ingress call is isolated from any issues with egress, such as packet loss and so on. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Maxim Sobolev writes: All this has nothing to do with the SIP, really. It just illustrates the point that SIP proxy is bad choice for real-time VoIP accounting. i didn't notice that someone in this discussion would have suggested to use sip proxy for accounting. accounting in the examples was done pstn. i do agree with dan here and do consider it sip protocol's fault if sip proxy working according to rfc3261 can ignore user's request to cancel a call. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Wednesday 12 March 2008, Maxim Sobolev wrote: Dan Pascu wrote: Anyway, examples are many and I'm sure people can even find more practical ones. The main reason for all of them being possible, is the fact that a CANCEL is no longer really canceling the call under these circumstances, and that the user is stripped from it's ability to control if a call should end or not before being setup, by random conditions (network packet loss) or purposeful abuses of the protocol behavior. All this has nothing to do with the SIP, really. I would say it has everything to do with SIP, being part of the SIP call setup negotiation. Which is more than I can say for solving network packet loss problems at the SIP protocol level. If you would have paid attention to all the examples I mentioned, you'd have seen that the main issue is not some miscalculated accounting entry, but the fact that the user is stripped of his ability to cancel a call he does not want to make because he doesn't agree with the terms and conditions that result from making that call. The consequences that result from the user being forcefully connected to the destination despite his refusal to do so are far more problematic that a miscalculated accounting entry and can even result in users being legally bounded to something they do not want or accept. It just illustrates the point that SIP proxy is bad choice for real-time VoIP accounting. If you use B2BUA, all those concerns go away, as you will get two separate SIP calls, so that your ingress call is isolated from any issues with egress, such as packet loss and so on. While I notice the subtle advertisemet of a b2bua solution here, let's focus on solving the issues that would be introduced in openser by implementing this new CANCEL handling (something that you proposed in the first place). While I can see that the proposed change satisfies RFC requirements and is endorsed by SIP experts, I cannot ignore the fact that it changes the end user experience in a fundamental and undesired way. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Juha Heinanen wrote: Maxim Sobolev writes: All this has nothing to do with the SIP, really. It just illustrates the point that SIP proxy is bad choice for real-time VoIP accounting. i didn't notice that someone in this discussion would have suggested to use sip proxy for accounting. accounting in the examples was done pstn. i do agree with dan here and do consider it sip protocol's fault if sip proxy working according to rfc3261 can ignore user's request to cancel a call. I think the main problem is caused by the fact that the proxy is just a proxy, not a B2BUA. klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Wednesday 12 March 2008, Maxim Sobolev wrote: If you want to isolate ingress and egress dialog state and bill user only for what he has actually sees use b2bua. Then you will be able to end ingress call with 487 immediately upon receiving CANCEL and don't bill user for anything that happens on the other side after that, letting egress calls to complete independently and not affect what user sees in her bill. I disagree. As I said it's not a matter of billing, it's a matter of making a connection where you do not want to. Even if your b2bua immediately ends your leg, it may still have the same issue on the outbound leg and connect to the service you refused to connect to. While the b2bua can chose not to emit a bill for that call because it knows the context, it cannot isolate you from the potential legal bindings that result from making a connection to that address. Rest assured that the other side will consider the original caller as connected to that service and that he has accepted all the terms and conditions since he has made the connection and will have no clue that a b2bua is in the path and some entity that cannot be made legally responsible (the b2bua) is connected instead. In the end it resumes to the fact that the protocol allows for another entity in the network to have control over me canceling a call and that I have no control over my own device's behavior, which is a shortcoming in the protocol IMO. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Mar 12, 2008 at 23:57, Dan Pascu [EMAIL PROTECTED] wrote: On Wednesday 12 March 2008, Maxim Sobolev wrote: No, it's not. Any protocol involving communication delay would have this problem. It's just the matter of how big the window of opportunity actually is. And frankly I don't see how previous behavior is better in that example. It still quite possible that the other branch mentioned there would actually have received INVITE, sent provisional reply, which simply got lost in transit, so that it happily answers the call in 10 seconds afterwards. So that whatever legal binding could be it's all here. In fact, the new behavior, which would continue INVITE retransmits has a better chances to relay CANCEL to that branch in time, due to the fact that it would stimulate retransmission of provisional reply even after CANCEL has already been received. With the current behavior, the caller never receives the 200 OK and doesn't send an ACK to confirm it, so he can claim that he has not accepted the call and his claim is sustained by the sip trace. and the fact that the other side never receives a confirmation (ACK) for the call. The caller will receive the 200, the difference is that it will receive it after a 487. There are 2 cases: - the transaction is already dead when the 200 arrives = the 200 reply is forwarded statelessly - the transaction is still alive (on the wait timer) = even in this case a 2xx reply will be forwarded (2xx after final reply). This is true in all ser versions and most likely in openser too (unless there were some major tm changes). If the UA would send or not an ACK to this 200 after 487 I guess is implementation dependent (the 200 will even have a different totag from the 487 so the UA might even think it deals with different dialogs established due to forking). I think most UAs would drop the 200, but you cannot rely on it. [...] Andrei ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu wrote: Even if a CANCEL arrives, a call may still be setup with a 200 OK + and ACK and then immediately closed by a BYE, which is a conceptually a completely different beast that a simple CANCEL that terminates the call without it being setup. No, you are incorrect, it has been a possibility to get call setup with 200 OK after CANCEL even with the previous behavior. When there are confirmed outgoing branches the proxy did not generate 487 locally, but instead relied CANCEL to them and waited for all of them to complete with either positive or negative final reply. The only case when local 487 was generated before is when CANCEL arrives when all outgoing branched have not generated any provisional response yet. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
From the sip-implementors list - looks like Maxim is right. regards klaus Robert Sparks schrieb: Part of why it does this is to deal with the case that the first INVITE the proxy sent actually got somewhere, but its response was lost. The retransmission will stimulate a retransmission of the response, letting you move forward to sending the CANCEL from the proxy. RjS On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote: The INVITE transaction must still complete independent of the CANCEL. So the proxy would continue to re-transmit the INVITE. If the proxy does receive a provisional response, it would then stop retransmissions and send the CANCEL down stream. If timer B fired, it would send a 408 response to the INVITE. Note that the proxy should respond to the CANCEL with 200 OK when it receives it since the INVITE transaction is in progress. cheers, (-:bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To: [EMAIL PROTECTED] Subject: [Sip-implementors] CANCEL retransmisson question of no provisional response! Hi! Could someone help me please with this question. Scenario: A transaction-stateful proxy forwards the INVITE request. The proxy does not receive a provisional response, thus starts retransmissions. Now, the caller CANCELs the call. How is the proxy supposed to handle this? Does the proxy still have to retransmit the INVITE or can it stop retransmitting the INVITE? From logical point of view I would think that the proxy should stop the retransmissions, but from Figure 5 in RFC 3261 it looks like the only way to come from Calling state to Terminated state is waiting for Timer B fires (as there is no provisional response yet). thanks klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Klaus Darilion wrote: From the sip-implementors list - looks like Maxim is right. Thanks, Klaus! Should this behavior be the default one then? regards klaus Robert Sparks schrieb: Part of why it does this is to deal with the case that the first INVITE the proxy sent actually got somewhere, but its response was lost. The retransmission will stimulate a retransmission of the response, letting you move forward to sending the CANCEL from the proxy. RjS On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote: The INVITE transaction must still complete independent of the CANCEL. So the proxy would continue to re-transmit the INVITE. If the proxy does receive a provisional response, it would then stop retransmissions and send the CANCEL down stream. If timer B fired, it would send a 408 response to the INVITE. Note that the proxy should respond to the CANCEL with 200 OK when it receives it since the INVITE transaction is in progress. cheers, (-:bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To: [EMAIL PROTECTED] Subject: [Sip-implementors] CANCEL retransmisson question of no provisional response! Hi! Could someone help me please with this question. Scenario: A transaction-stateful proxy forwards the INVITE request. The proxy does not receive a provisional response, thus starts retransmissions. Now, the caller CANCELs the call. How is the proxy supposed to handle this? Does the proxy still have to retransmit the INVITE or can it stop retransmitting the INVITE? From logical point of view I would think that the proxy should stop the retransmissions, but from Figure 5 in RFC 3261 it looks like the only way to come from Calling state to Terminated state is waiting for Timer B fires (as there is no provisional response yet). thanks klaus Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Maxim Sobolev schrieb: Hi, Disclamer: we discovered this issue with OpenSER 1.3, but it might be something affecting SER as well, so that I am cross-posting it there. Basically it looks like there is an issue with transactional CANCEL processing, potentially related to the presence of packet loss and/or branching. In a nutshell the situation looks like the following: the call comes in to the proxy, and gets forked into three locations using lookup()/t_relay() functions. Apparently there is some kind of network blackout, since proxy is not getting 100 Trying and does several INVITE retransmits on all 3 egress legs. After about 5 seconds it gets CANCEL from the originating party, it answers 200 to CANCEL and sends 487 for the ingress leg. Then it finally gets 180 Ringing from one leg, and 486 Busy Here from another leg. At that time there has been no provisional response received from the third leg. What it does next is ACK 486 and properly relays CANCEL to the leg from which it has received 180 Ringing, BUT (and that I think is the bug), it does absolutely nothing on third leg from that point on. It doesn't relay CANCEL there, which is RFC-compliant, since there has been no provisional response, however it ceases INVITE retransmits to that leg as well, despite the fact that only about 5 seconds has been passed since the first INVITE to that leg. From the user point of view, the phone that is a target of that 3rd leg continues ringing non-stop (apparently it has received one of INVITEs but provisional reply has been lost), until INVITE transaction expires in the UAS, long after the initial call has been disconnected. My guess is that receiving CANCEL somehow stops re-transmit timer on appropriate INVITE, which is incorrect in the case when no provisional response has been received on that transaction. The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? regards klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu wrote: networks with high packet loss issues. Retransmissions deal nicely with occasional packet loss and that's where it should end. The TCP/IP operates just fine in networks with 5-10% packet loss. Since it's the same 3-way handshake method, I see no reason why SIP would not. With SIP making inroads into wireless networks, which are by nature much more volatile when it comes to delays and packet loss making SIP server properly handling such scenarios is crucial. Unless UAC does number of retransmits specified by the RFC it can never be sure whether absence of provisional reply has been caused by the dead destination or network packet loss issue and the destination is in fact ringing. In the tm module you always assume dead destination, which is IMHO wrong. In my situation this problem has been aggravated by the magnitude of packet loss, but in general I've seen this issue before once in a while on a network with close to zero packet loss rate. Another bad decision is to generate 487 locally in the presence of unconfirmed active branches. SIP proxy should not do it unless it is It's not active anymore. It did timeout after the timer has expired, so it has generated an implicit 408. No, it's not. According to the RFC, explicit 408 happens after Timer B expires, in your case tm module assumes that transaction is dead immediately, without waiting for that. prepared to generate BYE if 200 OK comes from any of those branches (i.e. proxy provides some kind of dialog functionality). Again, in the real world, where packets are getting lost from time to time this could lead to 200 OK coming from the branch even if you do stop INVITE retransmitions. You will get yourself in the situation with originating UA already received fake final negative 487 from proxy, while terminating UA having dialog established, so that the only way to fix the issue is to send BYE from the proxy to the terminating UA. Not true. The dialog is not final until the ACK comes and it'll never come as the originating side has already received a final 487 reply. So a RFC compliant UA on the callee side should discard the dialog itself without any BYE if the ACK is not received after a certain amount of time. Still, ACK timeout would take 30 seconds to happen. You will possibly get a complain from the user about no audio after picking up as well as a 30-second billing mismatch between your system and remote system in the case of call going to some other network. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Klaus Darilion wrote: The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? --- RFC 3261 --- Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the original request). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. --- RFC 3261 --- According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Maxim Sobolev schrieb: Klaus Darilion wrote: The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? --- RFC 3261 --- Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the original request). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. --- RFC 3261 --- Ok. But this does not explicitly mention that the proxy should still send retransmissions. According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. Yes. From figure 5 it looks like retransmissions should not be stopped, but figures are usually not normative. anyway, I asked on the sip-implementors list for help ... and IMO PRACK should be used for lossy networks. regards klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Hi Klaus, Klaus Darilion wrote: Maxim Sobolev schrieb: Klaus Darilion wrote: The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? --- RFC 3261 --- Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the original request). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. --- RFC 3261 --- Ok. But this does not explicitly mention that the proxy should still send retransmissions. I agree on this, but so far there was no explicit mention that it should or it shouldn't :)... According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. Yes. From figure 5 it looks like retransmissions should not be stopped, but figures are usually not normative. As mentioned before, IMHO , figure 5 does not contain at all the case of a CANCEL generated by the UAC. So I guess it does not provide any useful info for our case. anyway, I asked on the sip-implementors list for help ... and IMO PRACK should be used for lossy networks. indeed, I think there are on that list persons with better understanding on the SIP RFC ;) Regards, Bogdan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Friday 07 March 2008, Maxim Sobolev wrote: Klaus Darilion wrote: The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? --- RFC 3261 --- Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the original request). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. --- RFC 3261 --- According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. In the paragraph quoted above I do not see any reference to TimerB or to keep retransmitting the initial INVITE on a branch that did not send a provisional reply, even after the caller has canceled the call. The only thing I read in there is that if a branch has not sent a provisional reply until the branch is about to be canceled, either because other branch has picked up the call or because the caller has canceled the call himself, then a CANCEL should not be transmitted on the branch without a provisional reply. This behavior is already honored by openser, AFAIK. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Bogdan-Andrei Iancu schrieb: Klaus Darilion wrote: Maxim Sobolev schrieb: According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. Yes. From figure 5 it looks like retransmissions should not be stopped, but figures are usually not normative. As mentioned before, IMHO , figure 5 does not contain at all the case of a CANCEL generated by the UAC. So I guess it does not provide any useful info for our case. I think it is included implicitly (by receiving a 487 from the UAS). regards klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Yes, but this behaviour is not relevant - the scheme takes into account the result of the Cancelling (487 reply), but not what the client should do when processing the CANCEL. Regards, Bogdan Klaus Darilion wrote: Bogdan-Andrei Iancu schrieb: Klaus Darilion wrote: Maxim Sobolev schrieb: According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. Yes. From figure 5 it looks like retransmissions should not be stopped, but figures are usually not normative. As mentioned before, IMHO , figure 5 does not contain at all the case of a CANCEL generated by the UAC. So I guess it does not provide any useful info for our case. I think it is included implicitly (by receiving a 487 from the UAS). regards klaus ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote: Bogdan-Andrei Iancu wrote: Hi Maxim, You stated: quote The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. /quote Is this based on RFC indication or a personal opinion? If RFC based, could you please point me out the relevant section? I'm asking mainly because, following my own logic, I would rather say that once the transaction is cancelled on UAS side, no further attempts (read retransmissions) should be done on UAC side. Bogdan, It's based on common sense. Unless UAC does number of retransmits specified by the RFC it can never be sure whether absence of provisional reply has been caused by the dead destination or network packet loss issue and the destination is in fact ringing. In the tm module you always assume dead destination, which is IMHO wrong. In my situation this problem has been aggravated by the magnitude of packet loss, but in general I've seen this issue before once in a while on a network with close to zero packet loss rate. Another bad decision is to generate 487 locally in the presence of unconfirmed active branches. SIP proxy should not do it unless it is prepared to generate BYE if 200 OK comes from any of those branches (i.e. proxy provides some kind of dialog functionality). Again, in the real world, where packets are getting lost from time to time this could lead to 200 OK coming from the branch even if you do stop INVITE retransmitions. You will get yourself in the situation with originating UA already received fake final negative 487 from proxy, while terminating UA having dialog established, so that the only way to fix the issue is to send BYE from the proxy to the terminating UA. OTOH if you wait for the timeout and you have some unreachable branches (I think this is quite common due, e.g. changing ip address), you'll delay possible 6xx answers and use more memory (even a 2xx replied transaction could be kept longer in memory if it has a not responing branch). I'm also not sure if this would be rfc conformant (although after a quick look I cannot find anything for or against it). I would rather send CANCEL even on branches with no provisional response (although the rfc seems to deny this due some possible race conditions (?)). I guess we can have yet another tm config param. for specifying cancel non-pending branches behaviour, but what should be its default value (present way, keep retransmitting INV, or send CANCEL)? Andrei ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Dan Pascu wrote: On Friday 07 March 2008, Maxim Sobolev wrote: Klaus Darilion wrote: The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. Is this really the correct behavior? Is this behavior defined in RFC 3261? --- RFC 3261 --- Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the original request). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. --- RFC 3261 --- According to my reading yes, UAC should wait either arrival of the first provisional response or expiration of Timer B (doing due retransmits in the meantime for unreliable transports) and send CANCEL if provisional reply comes in. In the paragraph quoted above I do not see any reference to TimerB or to keep retransmitting the initial INVITE on a branch that did not send a provisional reply, even after the caller has canceled the call. The only thing I read in there is that if a branch has not sent a provisional reply until the branch is about to be canceled, either because other branch has picked up the call or because the caller has canceled the call himself, then a CANCEL should not be transmitted on the branch without a provisional reply. This behavior is already honored by openser, AFAIK. No, it's not. UAC (SER/OpenSER) that wants to cancel branch should wait for the provisional reply to come back and then send CANCEL. Neitehr SER nor OpenSER does that. The only question is whether or not is should keep re-transmitting INVITE in the meantime. -Maxim ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Andrei Pelinescu-Onciul wrote: On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote: Bogdan-Andrei Iancu wrote: Hi Maxim, You stated: quote The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. /quote Is this based on RFC indication or a personal opinion? If RFC based, could you please point me out the relevant section? I'm asking mainly because, following my own logic, I would rather say that once the transaction is cancelled on UAS side, no further attempts (read retransmissions) should be done on UAC side. Bogdan, It's based on common sense. Unless UAC does number of retransmits specified by the RFC it can never be sure whether absence of provisional reply has been caused by the dead destination or network packet loss issue and the destination is in fact ringing. In the tm module you always assume dead destination, which is IMHO wrong. In my situation this problem has been aggravated by the magnitude of packet loss, but in general I've seen this issue before once in a while on a network with close to zero packet loss rate. Another bad decision is to generate 487 locally in the presence of unconfirmed active branches. SIP proxy should not do it unless it is prepared to generate BYE if 200 OK comes from any of those branches (i.e. proxy provides some kind of dialog functionality). Again, in the real world, where packets are getting lost from time to time this could lead to 200 OK coming from the branch even if you do stop INVITE retransmitions. You will get yourself in the situation with originating UA already received fake final negative 487 from proxy, while terminating UA having dialog established, so that the only way to fix the issue is to send BYE from the proxy to the terminating UA. OTOH if you wait for the timeout and you have some unreachable branches (I think this is quite common due, e.g. changing ip address), you'll delay possible 6xx answers and use more memory (even a 2xx replied transaction could be kept longer in memory if it has a not responing branch). I'm also not sure if this would be rfc conformant (although after a quick look I cannot find anything for or against it). I would rather send CANCEL even on branches with no provisional response (although the rfc seems to deny this due some possible race conditions (?)). I guess we can have yet another tm config param. for specifying cancel non-pending branches behaviour, but what should be its default value (present way, keep retransmitting INV, or send CANCEL)? There are three issues, really: 1. According to the RFC CANCEL on non-pending branches should be deferred until provisional reply comes. Neither SER nor OpenSER do that. They simply don't relay CANCEL if provisional reply comes later on. It looks like a clear bug to me and it needs to be fixed unconditionally. 2. The questionable issue is whether or not UAC should keep retransmitting INVITE when waiting for (1) to happen. This could be made an option. 3. Another questionable issue is whether or not UAS should be sending 487 immediately in the presence of such non-pending branches, it could also be made an option. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
On Mar 07, 2008 at 10:00, Maxim Sobolev [EMAIL PROTECTED] wrote: Andrei Pelinescu-Onciul wrote: On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote: Bogdan-Andrei Iancu wrote: Hi Maxim, You stated: quote The correct behavior of the tm module in this case would be to continue with INVITE re-transmits until we get provisional response and immediate CANCEL once that response comes in. /quote Is this based on RFC indication or a personal opinion? If RFC based, could you please point me out the relevant section? I'm asking mainly because, following my own logic, I would rather say that once the transaction is cancelled on UAS side, no further attempts (read retransmissions) should be done on UAC side. Bogdan, It's based on common sense. Unless UAC does number of retransmits specified by the RFC it can never be sure whether absence of provisional reply has been caused by the dead destination or network packet loss issue and the destination is in fact ringing. In the tm module you always assume dead destination, which is IMHO wrong. In my situation this problem has been aggravated by the magnitude of packet loss, but in general I've seen this issue before once in a while on a network with close to zero packet loss rate. Another bad decision is to generate 487 locally in the presence of unconfirmed active branches. SIP proxy should not do it unless it is prepared to generate BYE if 200 OK comes from any of those branches (i.e. proxy provides some kind of dialog functionality). Again, in the real world, where packets are getting lost from time to time this could lead to 200 OK coming from the branch even if you do stop INVITE retransmitions. You will get yourself in the situation with originating UA already received fake final negative 487 from proxy, while terminating UA having dialog established, so that the only way to fix the issue is to send BYE from the proxy to the terminating UA. OTOH if you wait for the timeout and you have some unreachable branches (I think this is quite common due, e.g. changing ip address), you'll delay possible 6xx answers and use more memory (even a 2xx replied transaction could be kept longer in memory if it has a not responing branch). I'm also not sure if this would be rfc conformant (although after a quick look I cannot find anything for or against it). I would rather send CANCEL even on branches with no provisional response (although the rfc seems to deny this due some possible race conditions (?)). I guess we can have yet another tm config param. for specifying cancel non-pending branches behaviour, but what should be its default value (present way, keep retransmitting INV, or send CANCEL)? There are three issues, really: 1. According to the RFC CANCEL on non-pending branches should be deferred until provisional reply comes. Neither SER nor OpenSER do that. They simply don't relay CANCEL if provisional reply comes later on. It looks like a clear bug to me and it needs to be fixed unconditionally. ser 2.1 does it: if a provisional response arrives on a canceled branch it will immediately result in a CANCEL being sent on that branch (or in case a CANCEL was already sent on the branch in a forced CANCEL retransmission). 2. The questionable issue is whether or not UAC should keep retransmitting INVITE when waiting for (1) to happen. This could be made an option. Yes, I agree. 3. Another questionable issue is whether or not UAS should be sending 487 immediately in the presence of such non-pending branches, it could also be made an option. I think it's linked to (2). If ones send a 487 immediately then you could have 200 after 487 in the same branch (as you pointed out). IMHO it makes little sense to have only (2) or only (3), it should be (2)+(3) or nothing. I'm also thinking of adding: 4. send CANCELs always (even if no provisional response received). It's not rfc conformant, but I don't see any problems with it (IMHO it won't break anything), I like it more then (2)+(3) and the code is already there (it's missing only the module option). There is also the questions on whether or not to do the same thing for: a. cancels because of received 2xx b. cancels becuase of 6xx c. cancels because of script t_reply() I'm thinking of doing it only for (b). (a) and (c) already send a final reply back and the only risk is to loose a provisional response, not send a CANCEL and later receive a final response on that branch (if we receive a provisional response we already automatically send a CANCEL back). For (a) this won't be a problem, if it's a 2xx the UAC should be prepared anyway to accept multiple 2xxs. (c) is rarely used with open branches and the impact is too small to fix IMHO (the perfect fix for (c) would include generating BYEs for possible 2xxs). Andrei ___ Devel mailing list
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Maxim Sobolev writes: The TCP/IP operates just fine in networks with 5-10% packet loss. Since it's the same 3-way handshake method, I see no reason why SIP would not. With SIP making inroads into wireless networks, which are by nature much more volatile when it comes to delays and packet loss making SIP server properly handling such scenarios is crucial. then why you don't use sip/tcp like, for example, nokia phones do. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Juha Heinanen wrote: Maxim Sobolev writes: The TCP/IP operates just fine in networks with 5-10% packet loss. Since it's the same 3-way handshake method, I see no reason why SIP would not. With SIP making inroads into wireless networks, which are by nature much more volatile when it comes to delays and packet loss making SIP server properly handling such scenarios is crucial. then why you don't use sip/tcp like, for example, nokia phones do. TCP has its own issues, with NAT for example. IMHO we should support both well, even in the lossy environments. -Maxim ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Maxim Sobolev writes: TCP has its own issues, with NAT for example. is there some other NAT problems remaining if UAs keep TCP connection to their outbound proxy open all the time and regularly issue double-CRLF keepalive? -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
