Patches item #1642890, was opened at 2007-01-23 12:41 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver devel Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kobi Eshun (ekobi) Assigned to: Nobody/Anonymous (nobody) Summary: 'bye2bye' UA module prototype Initial Comment: Hi, Attached are two patches implementing a prototype 'bye2bye' UA module that cheaply fakes end-to-end BYE requests -- it's a watchdog that enforces metered call duration. One of the patches augments the existing dialog module so that it caches to/from contact and CSeq values; the other implements the new module. I'm soliciting feedback, in particular: Q1 - is there enough general interest in this functionality to warrant further development? Q2 - is there some additional functionality that makes sense? Q3 - would it be better implemented as an integrated extention to the existing dialog module? Use of the module is very straightforward: - Define the module flag parameter that will enable the watchdog on a per-dialog basis. This is used in conjunction with the dialog module flag defined by 'dlg_flag.' - Optionally define the module parameters 'bye2bye_headers,' 'bye2bye_to_next_hop,' and 'bye2bye_from_next_hop.' - set the value of the dialog 'timeout_avp' as required for each dialog that will be monitored. -- kobi ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-02 02:04 Message: Logged In: NO Hi does any one have deployed success this patch and disconnected the call ram ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-06-18 11:45 Message: Logged In: YES user_id=1275325 Originator: NO Hi Andreas, Hi Kobi, somebosy from our team is working on this topic. There are already 2 patches prepared, but not sufficently tested to make their way on SVN. I hope it will be done in the next weeks. First patch is about having persistency support for the dialog module (via DB) and second is an extention in order to same in the dialog all the information (Cseq, contacts, RR set, etc) you need to build a sequnetial request. regards, bogdan ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-06-14 19:11 Message: Logged In: YES user_id=1039134 Originator: YES Hi, Andreas. I agreed to refactor this prototype so that the code that actually constructs and sends the messages will be generally available via the dialog module -- currently, that is handled by the bye2bye module. Needless to say, this task is in the pipeline :> The second patch is functionally identical to the first. It's compatible with version 1.2.0, and I think it may have one or two bug fixes too. I have not tried applying it to version 1.2.1. Cheers, -- kobi ---------------------------------------------------------------------- Comment By: Andreas Granig (agranig) Date: 2007-06-14 11:40 Message: Logged In: YES user_id=825350 Originator: NO Hi, I'm interested in pushing this feature-request a little further. What's the current status of it? About two months after the initial discussion, another patch has been submitted. What exactly is the diff compared to the initial patch? Andreas ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-03-30 13:58 Message: Logged In: YES user_id=1039134 Originator: YES File Added: dialog.patch ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2007-01-31 10:43 Message: Logged In: YES user_id=1395524 Originator: NO Hi, There are some issues that needs to be addressed with respect to the dialog module and the end-to-end BYE requests: 1. PRACK and dialog timeout: - see discussion: http://openser.org/pipermail/devel/2006-October/004022.html 2. database back-end for dialog module: - on server restart, the dialogues are lost and therefore it will be impossible to terminate a dialog. - on server failover, there's no mechanism to transfer dialogues from the active to the stand-by. ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2007-01-31 06:23 Message: Logged In: YES user_id=1395524 Originator: NO Hi, There are some issues that needs to be addressed with respect to the dialog module and the end-to-end BYE requests: 1. PRACK and dialog timeout: - see discussion: http://openser.org/pipermail/devel/2006-October/004022.html 2. database back-end for dialog module: - on server restart, the dialogues are lost and therefore it will be impossible to terminate a dialog. - on server failover, there's no mechanism to transfer dialogues from the active to the stand-by. ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-01-29 14:08 Message: Logged In: YES user_id=1039134 Originator: YES Yikes! I guess I struck a nerve with this post. It's as if I said "vi is better than emacs" (which is rubbish, of course) and then left the room. First, thanks for all of the feedback. Clearly, there is plenty of interest in this topic, and I'm looking forward to taking this proof-of-concept to the next level. Bogdan indicated early that he would prefer to see this implemented as an integrated extension to the existing dialog module. I'm fine with that, especially since it probably means less work for me. Clearly, the current dialog matching rules are not adequate to provide robust watchdog capability. Near as I can surmize, the enduring debate here is whether to favor computational efficiency over "correctness." I'm wondering if it would be possible to implement both the fast, cookie-based dialog matching, and the (supposedly) slower callid+to/from-tag methods, and to decide at script-time which match is actually used. My prototype omits use of the accumulated routing information -- this is obviously a requirement. When I was modifying the dialog module, I started to feel a bit guilty about bloating the dlg_cell structure just for my purposes. It occurred to me that perhaps the dialog module could accept a bitmask that specified which pieces of dialog state would be cached. In this way, for example, the SST module could function without the extra dialog state required by the bye2bye feature. So, what next? Cheers, -- kobi ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-01-29 13:20 Message: Logged In: YES user_id=1039134 Originator: YES Yikes! I guess I struck a nerve with this post. It's as if I said "vi is better than emacs" (which is rubbish, of course) and then left the room. First, thanks for all of the feedback. Clearly, there is plenty of interest in this topic, and I'm looking forward to taking this proof-of-concept to the next level. Bogdan indicated early that he would prefer to see this implemented as an integrated extension to the existing dialog module. I'm fine with that, especially since it probably means less work for me. Clearly, the current dialog matching rules are not adequate to provide robust watchdog capability. Near as I can surmize, the enduring debate here is whether to favor computational efficiency over "correctness." I'm wondering if it would be possible to implement both the fast, cookie-based dialog matching, and the (supposedly) slower callid+to/from-tag methods, and to decide at script-time which match is actually used. My prototype omits use of the accumulated routing information -- this is obviously a requirement. When I was modifying the dialog module, I started to feel a bit guilty about bloating the dlg_cell structure just for my purposes. It occurred to me that perhaps the dialog module could accept a bitmask that specified which pieces of dialog state would be cached. In this way, for example, the SST module could function without the extra dialog state required by the bye2bye feature. So, what next? Cheers, -- kobi ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-25 11:16 Message: Logged In: YES user_id=1296758 Originator: NO Jerome, Sorry if I sounded rude, that was not the intention. I was just trying to say that I'm happy that some people find the case with weaker security and closing dialogs for which the UAs cannot conform to an OpenSER specific extension to be fine, I'm just unhappy that a better solution with stronger security cannot be implemented because it seems to be opposed by people who invoke performance reasons (which incidentally if you look at the numbers you'll probably see that it is not that much cheaper as people believe, in fact I believe it'll be similarly expensive). By looking at your last post, it seems that you and I express the same ideas and I see no contradiction between what we say, so I'm lost why we have this apparently contradictory conversation. Klaus, The problem with using a cookie is that you cannot be certain it is valid. And the time used to verify the cookie can very well turn out to be lost time. Let me reiterate this: 1. cookie is checked and turns to belong to a dialog (only that it was faked and the message belongs to a different dialog) 2. the call-id is checked and indicates that the cookie was tampered with and cannot be trusted. 3. At this point 2 string comparisons have been performed and we still do not know to which dialog we belong to. 4. we then have to check the tags to identify the real dialog, but then we have already lost time checking the cookie So as a comparison: 1. cookie with no tampering: 2 string comparison: cookie and call-id 2. cookie with tampering: 3 string checks: cookie, call-id, from-tag 3. no cookie used: 2 string checks: call-id and from-tag So IMO, the call-id+from-tag is overall cheaper than the cookie+call-id check On a different note, I do not think that we need to check the to-tag as well. That is undefined until the dialog actually starts (1xx replies may have different to-tags). If we check the to-tag as well, then it may be a bit more expensive, but not by much and the fact that it is safer should count much more in the balance than the fact that it has to compare a few more bytes than the cookie+call-id check. P.S. I believe that we have hijacked this ticket enough. If people still want to discuss this topic I propose to move it to the devel mailing list. ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2007-01-25 07:48 Message: Logged In: YES user_id=1318360 Originator: NO Thinking about it I came to the result: - a cookie is fine if it helps finding the dialog (performance), but it must not be used as dialog identifier. But how to deal with cookies if the dialog stored behind this cookie does not match? or if there is no cookie? We could avoid this bogus situations by using only callid+tags as identifier. As Bogdan said this is slower as a cookie lookup - but maybe we can find another algorithm to fast find a dialog without the need for a cookie (how is tm doing this? - maybe this can be reused ...) IMO security is a very important argument, and it is getting more and more important. I do not want to buy an SBC to protect my openser. Further, security related features should be turned on by default (even if it impacts performance). If people need more performance they should be aware that the security may suffer. Thus, I would like a fast :-) dialog lookup based on callid+fromtag+totag . regards klaus ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-25 07:33 Message: Logged In: NO Dan, I don't understand exactly to which parts of my previous comments you're answering, so I'm going to do something bad, I'll quote you're reply so my answers get clearer in-context : > You seem to be forgetting that there is already a solution that is robust > and hack free. It is to identify the dialog based on the call-id and the > from tag. Well, it is not implemented, but sure I'd like to have this option. In fact, if the perfs are really as goos as cookie check + double check, I'd be the first to use it. And I don't recall I said something else in my previous comments. > So I fail to see your argument about being a polemical point. This is the part where I'm not sure to which of my comments you're referring. > This solution cannot be hacked by the client, but appers not to be accepted > for performance reasons. > Incidentally checking the call-id and the from tag > is not more expensive than checking the cookie and then using the extra > call-id check for better protection, but it is better that the > cookie+call-id check and it is able to clearly identify the dialog unlike > the cookie+call-id check (which is sort of funny). OK, let me clarify what I think : - I won't use the cookie without extra checks anyway, for security reasons - I don't know which is more expensive (cookie + callid check vs. callid + tags upfront). If callid + tags does not add a significant overhead, then again I'd use it too if available. Again, I'm not pushing one way or the other, I'm lacking performance numbers to decide. > As for your choice to send 666 burn in hell replies to user requests, be > my guest. Hum. That was a joke. You got that, right ? > I couldn't care less how you handle your users. I don't really get it. Why are you so rude ? Was I rude ? If I said something earlier that pushed your nerves, please accept my apologies. But sincerely, I'm surprised by such an answer. > My issue is that your "punish the user" scenario can be implemented, while > the alternative I'm willing to use cannot. Well, the idea is not to punish users, merely trying to enforce coherency and handle error cases. I really am at lost with the way this conversation is drifting away from a technical conversation towards an emotionnal one. Totally at lost. > So what about a choice on what dialog matching algorithm to use? If you ask me, I'd say sure ! Choice is good. It's not for me to decide though. But again, I am not trying to push one way or another, I'm just trying to seek information from people who coded it, and try to understand if my prefered method in an ideal world (systematic tags+callid check) is realistic in terms of performance. If it is, let me say it once again, I'll be the first to use it ! And if the overhead is too large, then I have nothing against being pragmatic and stick with the current cookie optimization (and maybe add a tags check along with callid check after dialog matching). Cheers, Jerome ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-25 07:24 Message: Logged In: YES user_id=1296758 Originator: NO Bogdan, Using the cookie mechanism allows such modifications to the message (as I explained them before) that would make the TM machinery still forward them correctly to the right destination and they are still correct in-dialog requests, but the dialog module will not see them as such and would be fooled. The cookie is something specific to only openser and any other UA will ignore it without any side effects (it can even be modified without any effect on dialog matching in the clients, only openser will be affected by this). In short, cookie changes can affect openser while having no effect on the dialog. On the other hand, if one tries to modify other dialog identifying elements (like call-id or the tags) which are dialog identifying elements for any UA, then the request will be rejected by the endpoints themselves and will not be able to affect the dialog. In this case the UAs dialog matching capabilities will be affected as well. In short these changes will make the request no longer belong to the original dialog and thus they cannot affect the original dialog. I see the 2 cases as being very different regarding the level of damage that can be done and how they affect dialog matching. ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-25 07:06 Message: Logged In: YES user_id=1296758 Originator: NO Jerome, You seem to be forgetting that there is already a solution that is robust and hack free. It is to identify the dialog based on the call-id and the from tag. So I fail to see your argument about being a polemical point. This solution cannot be hacked by the client, but appers not to be accepted for performance reasons. Incidentally checking the call-id and the from tag is not more expensive than checking the cookie and then using the extra call-id check for better protection, but it is better that the cookie+call-id check and it is able to clearly identify the dialog unlike the cookie+call-id check (which is sort of funny). As for your choice to send 666 burn in hell replies to user requests, be my guest. I couldn't care less how you handle your users. My issue is that your "punish the user" scenario can be implemented, while the alternative I'm willing to use cannot. So what about a choice on what dialog matching algorithm to use? ---------------------------------------------------------------------- Comment By: Adrian Georgescu (adigeo) Date: 2007-01-25 04:07 Message: Logged In: YES user_id=1682561 Originator: NO In have encountered situations where the cookie was malformed while the original tags were not. The dialog module should: - Match the tags/callid and be able to store arbitrary value/attributes pair for information you might need in the future - Storage must be done on the SIP Proxy and not in the client We curently do this reliably with an external application. I am wondering if this would be done from inside an OpenSER module whether it would have major performance implications? ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-25 03:38 Message: Logged In: YES user_id=1275325 Originator: NO Hi Jerome, Hi Adrian, OpenSER already uses the mechanism of cookies for fast matching replies to transactions - this cookie is stored in the branch param of view. So, it is not a totaly new concept. The security concers are valid in TM and in DIALOG, but an "hack-proof" solution is impossible. As Adrian says that the RR/Route cookie is not reliable as it can be changed, the same is for callid, tags, etc. I have to agree with Jerome on this. If something bogus is received, just discard/reject it. regards, bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-25 03:05 Message: Logged In: NO Hello Adrian, I understand your point and I agree that the idea of storing critical information in a UA-modifiable cookie is a problem in itself. But frankly, the whole SIP message already contains such important, UA modifiable, sensitive data. Integrity is ensured by checking and matching, no matter what the dialog identification method is (additional cookie and/or plain old RFC headers). This does NOT mean we should add more of those critical information in REQUESTs lightly. But I'm not that worried by having a cookie as an implementation artifact, even though I am generally very critical on security matters (well, if the implementation is right and permits double check). What I was calling "pointless an polemical" was the distinction between "hack-proof" and "hack attempts will be punished". In fact, it seems my remark had the opposite effect of what I wished (focus on technical part, not arguable distinctions), and for that I am sorry. What I want to point out is that "hack-proof" might be a noble and respectable goal (that we should pursue), but this is not a realistic objective given SIP level of complexity, so as for all matters related to security, "hack proof" for SIP should be the direction, not the target. What I believe, however, is that if the cookie is used, then the proxy should react to attested manipulations of the cookie (modification, deletion) exactly as if a Call-ID or TAG have been manipulated : reject the REQUEST. But I feel the whole dicussion is pointless if it is possible to implement Klaus scheme (match dialogs with tags + callid directly upon reception of the request) with acceptable performances. If that's the case, then of course I'm in favor of having an RFC-compliant, harder-to-tamper-with system. What do you think ? What would be the overhead of doing upfront checks/matching on callid + tags without a cookie ? Regards, Jerome ---------------------------------------------------------------------- Comment By: Adrian Georgescu (adigeo) Date: 2007-01-25 02:40 Message: Logged In: YES user_id=1682561 Originator: NO Hello Jerome, A SIP proxy system, that needs to be reliable, stores such critical information in a cookie part of a SIP header passed to clients that can on their own either: 1. Modify or delete the cookie on purpose, 2. Modify the cookie by accident (like lowercasingthe cookie as I have seen this in practice) In your opinion, "this is a bit pointless an polemical"? I am sorry, but not many would like to use in production systems that allow end-users to hack it like this. The idea of storing reliably critical information in clients by means of a cookie is not reliable. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-25 02:19 Message: Logged In: NO Hello Klaus, Bogdan, Dan, everyone :-) I would say that what Klaus is saying makes great sense, however I think the "I want a system that cannot be hacked, not one that punishes you when you try to hack it." part is a bit pointless an polemical. We could argue on that for days, so I would advise to let that part go away. What matters, I believe, is in that order : - robustness (a corrolary of which is RFC compliance, an other one security) - performance (historically, SER/OpenSER systems based a large part of their popularity on that) - functionnality IMHO, Klaus suggestion is a better approach as it is more RFC3261-compliant than what we have ( quote from the RFC : "The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship [...] and is referred to as a dialog.") and gives us some additional peace of mind about dialog-matching robustness. However, the question is "What is the performance overhead of Klaus suggestion vs. cookie matching + double check". I consider the cookie part as being only an implementation artifact, acceptable if it helps getting better performances and does not limit RFC compliance. So I would say can't we just add tags checks after cookie-matching ? What are the implications ? The remaining problem is what to do for in-dialog REQUESTs lacking the cookie ? I would be tempted to add an OPTIONAL compatibility mode ONLY if we can find some popular AND broken UACs/UASs that remove some RR parts, but that would be soooo damn broken that I doubt we find any widely-spread products which behave so badly. That mode would just deactivate the cookie-related stuff and just plain check dialog Call-ID + tags. But the default behaviour should IMNSHO be to drop those REQUESTs, terminate the dialog, and send the special "666 Burn in hell" answer code to the faulty UA. Cheers, Jerome ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-24 12:27 Message: Logged In: YES user_id=1296758 Originator: NO The problem is that I do not want to reject requests that do not have the cookie. I want a system that cannot be hacked, not one that punishes you when you try to hack it. Those requests are valid in-dialog requests and if I drop them the call setup will be affected. Moreover I have no idea if the user is trying to hack the system by manipulating the cookie, or it is just an implementation that is flawed and doesn't copy all the parameters from the Request-Route in the subsequent Route headers. And a system that is based around a parameter that is part of the message and can be altered by the endpoints is not a secure system by any means. No matter how many checks you put around that cookie. Moreover, not including the cookie is not the only way to try to fool the system. I can for example start 2 dialogs. One being a prepaid call and the other being a SIP-to-SIP call which is free. I can then use the cookie from the free call into re-INVITE requests from the prepaid call fooling the system believe that they belong to the free call. Thus the proxy will be unable to generate valid BYE requests for the prepaid call when the credit will expire because it's knowledge of the CSeq will be invalid. Now you may say that you can activate the call-id check as well and it won't be fooled, but then again, you compare the cookie and the call-id, how is that more expensive than comparing the call-id and the from-tag which is what is needed to do server based dialog identification without relying on user modifiable cookies in the requests. Even more, with the cookie+call-id checks, you can only detect that the request was manipulated and doesn't belong to the dialog it claims to belong to, but you still do not know to which dialog it realy belongs to and will be left with only 1 choice: to reject it, which is not a good choice. However, if real dialog identification is performed in the server that won't be more expensive than the cookie+call-id checks and will be much more secure allowing me to have a system that cannot be hacked and I do not have to worry about rejecting requests because they look like possible forging attempts. As I said in the beginning, a good system IMO is one that doesn't give you the oportunity to hack it, not one that leaves doors open but punishes you if you try to use them. ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 09:59 Message: Logged In: YES user_id=1275325 Originator: NO First, Jerome, sorry for the mix up :(... Secondly, Klaus, you can already have this behaviour with the current impl. .If a sequential dialog does notmatch to any current dialogs (cookie and/no tight matching), you can check from script the PV $DLG_status - this this doee not exists, just negatively reply. regards, bogdan ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2007-01-24 07:52 Message: Logged In: YES user_id=1318360 Originator: NO Yes - we need some functions for security checks - check if request contains a valid dialog cookie - check if request matches a ongoind dilaog (cookie+callid+tags) Then, a secure system would reject in.dialog messages if the request does not exist in the dialog table. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 07:43 Message: Logged In: NO Bogdan, Thanks for the expanation. From what you're saying, the only logic missing to reach Dan's safety target would be "If there is no cookie in an in-dialog REQUEST, then either terminate the dialog (on the assumption someone is trying to manipulate the call flow - I am envisioning something like "Internal proxy error" ala sl_reply_error) or just fall back to "slow matching", like the double checking but done upfront. Is that right ? also, as a sidenote, guys, my first name is "Jérôme", Martin being the last name, so please call me "Jérôme" (I don't care that much about the accents :-)). Cheers, Jerome ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 07:28 Message: Logged In: YES user_id=1275325 Originator: NO Martin, the cookie is used to locate for a fast location of the internal dialog record. Once found, you have the option to double check the matching by seting the "use_tight_match"module param - this will force the checking of callid also. So there is a safety mechanism :)... Klaus already suggested to add more extra checks (like tags). The advantage of using the cookie, even with the tigh matching, is that you so not try to match the request to N dialogs by doing expensive string comps, but you do it only once, to double check the result. regards, bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 06:33 Message: Logged In: NO Dan, Are you suggesting that the dialog module should use the cookie if present (for optimization purposes) but still check the CallID: and To: field to make sure it does not miss an altered request in case the dialog cookie is missing ? Or do you think we need to go even further and totally remove the dialog cookie and only use pristine header to identify the dialog matching a particular request ? I don't see all the implications in terms of speed, but from what I understand the cookie method was chosen for performance reasons, because we benefit from the fact that the RR: header is already parsed and stored. What do you think ? Cheers, Jerome Martin ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-24 06:21 Message: Logged In: YES user_id=1296758 Originator: NO There is another thing that needs to be considered when building functionality that needs strict control over the message flow in a dialog, like the one that this patch wishes to implement. The dialog module has a serious shortcoming that prevents such functionality to be reliable. The dialog module identifies in-dialog requests by using a cookie in the Record-Route header. This cookie can be removed or altered by the endpoints (on purpose or because of a flawed implementation). If this happens those requests will not be identified as belonging to the dialog and will be ignored in computing dialog related state. Now any functionality that needs strict control over the message flow in a dialog (like for example implementing a prepaid system where fake BYEs need to be sent when the user credit has expired) cannot be reliably based on the dialog module in its current form. For example if the endpoints send some in-dialog requests with the cookie missing or altered, they will not be identified by the proxy as belonging to the dialog and the CSeq information will not be updated. Then later when the fake BYEs are sent, they will have an old CSeq number which will be rejected by the endpoints because it was already used and the call will not be closed. In this case the call will continue past the credit limit and there is nothing the proxy can do to close it. All of this happens because in the current implementation of the dialog module, the endpoints have control over which messages will be detected as being part of the dialog and which not. ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2007-01-24 05:38 Message: Logged In: YES user_id=1318360 Originator: NO I agree with Dan. Please see my feature request with some details about the data which should be stored inside the dialog structure. https://sourceforge.net/tracker/index.php?func=detail&aid=1632996&group_id=139143&atid=743023 ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-24 05:32 Message: Logged In: YES user_id=1296758 Originator: NO For this functionality to be really useful, much more information needs to be stored per dialog and be put in the faked BYEs. One thing that comes to mind is the Route headers that would be present in the BYEs sent by the endpoints themselves as a result of Record-Route information added by proxies that wish to stay in the path. The fake BYEs must follow the same path that the native BYEs sent by the endpoints would have, for 2 reasons: 1. You may not have direct access to the endpoints because you do not have the NAT with them open, so you need to send via the proxies that have. 2. If you send directly to the endpoints, the other proxies that wished to stay in the path by using Record-Routes will be unaware of the dialog that just ended and may make wrong assumptions and wrong decisions about the call. Without adding the Route heders, the functionality's usefulness is limited to calls where there is only 1 proxy between the endpoints. ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 04:07 Message: Logged In: YES user_id=1275325 Originator: NO Hi Martin, I do not disagree with you, but 'm exploring the possibilities :). My thoughs were to keep dialog module as a container for the basic dialog functionalities - creating, tracing and terminating them. Based on this, I see the existing module a good place to have a geenric function for ending a dialog. Maybe more new modules will want to do dialog cancelling and I see no reason not to have everything together. If more complex dialog-processing modules will show in time, they will all use the basic dialog functions from "dialog" module. At least this is my personal view on the matter. Shortly : 1) keep in dialog module all the basic functionlities (add, view, delete) 2) add more modules for complex dialog-based scenarios Regards, Bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 03:06 Message: Logged In: NO Hi Bogdan, It seems you disagree with my point of keeping things separate, which is fine by me. I understand the reasons, but still I am afraid this can grow out of reach quick. As I mentionned before, I perceive the dialog-related features as having the highest growth-potential of the whole OpenSER codebase, and I would not like to see it become nuclear-factory-sized as I am sure many people will have "related features" to add. However, you're the one with CVS access so you probably know better :-) Still, I would appreciate if you took some time when you're a bit less busy to share your thoughts in more depth on that matter. Still, the important thing is that Kobi initiative is really one of those that WILL attract users and typically enhances OpenSER in a manner that will seduce many people. Way to go ! (and in fact, I'm happy disregarding if this ends up in a separate module or in dialog :-) Best Regards, Jerome Martin ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 02:52 Message: Logged In: YES user_id=1275325 Originator: NO Hi Kobi, yes, the interes exists and it si huge :) my original plan was to have the dialog module to encapsulate dialog-related functionalities. First was to be able to track down dialogs and possible to do count based on different criteria (see the features request comming from Klaus). I would prefer to stick to this original plan and continue extending the dialog module (instead of adding small new modules) as time as there is related functionality. regards, bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 02:21 Message: Logged In: NO Hello Kobi, I am myself in the process of writing some code to implement this functionnality myself, so I am very enthusiastic about you submission. If you want to talk about it (help, debugging, ideas, discussion), I can be reached at [EMAIL PROTECTED] My own code is not a module but an external piece of code called by exec(), so I'll probably dump it in favor to your approach which is of course cleaner. As of your questions, here are my answers : Q1 - is there enough general interest in this functionality to warrant further development? Well, given the number of threads I've seen on SER/OPENSER MLs, I would say everybody's looking for a way to cut calls. Currently, I've only seen external perl scripts using FIFO UA features to acheive this (and I'm doing the same thing). Q2 - is there some additional functionality that makes sense? In order to enlarge the module's userbase, an ideal addition would be being able to trigger the end2end BYE messages from an external source in addtion to timed calls. Q3 - would it be better implemented as an integrated extention to the existing dialog module? I would keep both modules separate for now, as I suspect many more functionnalities will arise that use dialog statefullness, and a global policy that makes sense would rather be keeping things clean, small and maintainable. But that's just IMHO. Cheers, Jerome Martin ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-01-23 12:42 Message: Logged In: YES user_id=1039134 Originator: YES File Added: dialog.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143 _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
