RE: [Asterisk-Users] CDR for transfered calls
The issue we have here is not just related to IAX. If you have Asterisk step out of the media stream for any call, you lose the capability to determine the status of the call, and therefore lose the ability to track the call in your CDR. Perhaps (at least for the case of IAX transfers or maybe sip registry transfers (reinvite from/to a different asterisk server), we need an option for centralized CDR record keeping. At the begining of any transaction, create a truly global unique ID for the transaction and log it with the central CDR system. Now pass that Unique ID along to any parties in the transaction, and each party updates the central CDR system with any changes to the transaction. In a scenerio like this you would be able to maintain accurate CDR records for any calls in which the media stream passes through devices supporting the CDR system. For it to work fully, you'd need to get UAs to support it as well (probably would need an RFC and alot of prodding), since in some cases calls will be UA to UA after all the initial signalling is completed. -Chris On 12:32 AM 6/10/2004, Florian Overkamp wrote: Hi, -Original Message- Yes. The issue here is that billing information is never correct in such a scenario, since the call duration on the registered asterisk machine (the one that is kicked from the path) is no longer correct. To fix this a notransfer=yes is mandatory, but that defies the practicality of having a voip conversation take the shortest path. Sure... So, this issue is sort of a bug and it really needs to be implemented then! I'm afraid its not that simple. Unless I'm misunderstanding the concepts of IAX(2) design, it does not support such behaviour _by design_. Who knows what would break if someone hacked our desires in there. A solution then would be: choose another protocol. Technically you could spin off an IAX2-cdr channel that supports it, but that would require duplicate efforts to maintain both channels. My current position is 'deal with it' and accept the extra traffic. If someone with more knowledge about IAX(2) can comment on the feasability of this behaviour we may proceed in that direction, otherwise we're just stuck. Florian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] CDR for transfered calls
On Tuesday 15 June 2004 13:53, Chris A. Icide wrote: The issue we have here is not just related to IAX. If you have Asterisk step out of the media stream for any call, you lose the capability to determine the status of the call, and therefore lose the ability to track the call in your CDR. Is it possible to have a callback whereupon the server that stepped out of the way gets notified by one/both of the endpoints as to the call completion and so on? Perhaps (at least for the case of IAX transfers or maybe sip registry transfers (reinvite from/to a different asterisk server), we need an option for centralized CDR record keeping. At the begining of any transaction, create a truly global unique ID for the transaction and log it with the central CDR system. Now pass that Unique ID along to any parties in the transaction, and each party updates the central CDR system with any changes to the transaction. In a scenerio like this you would be able to maintain accurate CDR records for any calls in which the media stream passes through devices supporting the CDR system. For it to work fully, you'd need to get UAs to support it as well (probably would need an RFC and alot of prodding), since in some cases calls will be UA to UA after all the initial signalling is completed. This is a nice idea, I think -- something akin to a syslog server even. Regards, Andrew ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] CDR for transfered calls
Chris A. Icide wrote: The issue we have here is not just related to IAX. If you have Asterisk step out of the media stream for any call, you lose the capability to determine the status of the call, and therefore lose the ability to track the call in your CDR. That brings up a question that's been running around in my head... imagine this scenario: User has a SIP phone, sitting behind a NAT. Asterisk A is their PBX, where their SIP registration goes. Asterisk B is a PRI server, just handles a PRI (or two) of channels. A call comes in on the PRI, and is routed from Asterisk B to Asterisk A using SIP. The call is then routed by Asterisk A to the SIP phone, and the user answers. At this point, both Asterisk boxes are still in the media stream. Since the SIP phone is behind a NAT, and thus canreinvite=no, will Asterisk A reinvite Asterisk B _only_, so Asterisk A can drop out of the media path? ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
[sorry - too lazy to re-arrange this top-posting stuff] Not all Asterisk channel types lose control when they step out of the media stream. SIP devices will notify the proxy server (Asterisk, in our case) that a call has terminated, so even though the media stream never went through the proxy (Asterisk). This is an important distinction between IAX2 and SIP - media and control messages are not tightly linked with SIP as they are with IAX2. Until IAX2 has some type of backwards path notification, there is no method (to my knowledge) that IAX2 can notify the origin servers that the call has been terminated. The only way for any server in the path to know the status of the call (with IAX2) is to not transfer the call away from itself, thus bearing the full load of the media stream and the control channel. I would be happy to learn of other's experiences in managing this issue, as it is quite important (mandatory, really) in any type of managed service environment. JT At 10:53 AM -0700 on 6/15/04, Chris A. Icide wrote: The issue we have here is not just related to IAX. If you have Asterisk step out of the media stream for any call, you lose the capability to determine the status of the call, and therefore lose the ability to track the call in your CDR. Perhaps (at least for the case of IAX transfers or maybe sip registry transfers (reinvite from/to a different asterisk server), we need an option for centralized CDR record keeping. At the begining of any transaction, create a truly global unique ID for the transaction and log it with the central CDR system. Now pass that Unique ID along to any parties in the transaction, and each party updates the central CDR system with any changes to the transaction. In a scenerio like this you would be able to maintain accurate CDR records for any calls in which the media stream passes through devices supporting the CDR system. For it to work fully, you'd need to get UAs to support it as well (probably would need an RFC and alot of prodding), since in some cases calls will be UA to UA after all the initial signalling is completed. -Chris On 12:32 AM 6/10/2004, Florian Overkamp wrote: Hi, -Original Message- Yes. The issue here is that billing information is never correct in such a scenario, since the call duration on the registered asterisk machine (the one that is kicked from the path) is no longer correct. To fix this a notransfer=yes is mandatory, but that defies the practicality of having a voip conversation take the shortest path. Sure... So, this issue is sort of a bug and it really needs to be implemented then! I'm afraid its not that simple. Unless I'm misunderstanding the concepts of IAX(2) design, it does not support such behaviour _by design_. Who knows what would break if someone hacked our desires in there. A solution then would be: choose another protocol. Technically you could spin off an IAX2-cdr channel that supports it, but that would require duplicate efforts to maintain both channels. My current position is 'deal with it' and accept the extra traffic. If someone with more knowledge about IAX(2) can comment on the feasability of this behaviour we may proceed in that direction, otherwise we're just stuck. Florian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
On Tue, 15 Jun 2004, John Todd wrote: Not all Asterisk channel types lose control when they step out of the media stream. SIP devices will notify the proxy server (Asterisk, in our case) that a call has terminated, so even though the media stream never went through the proxy (Asterisk). This is an important distinction between IAX2 and SIP - media and control messages are not tightly linked with SIP as they are with IAX2. Until IAX2 has some type of backwards path notification, there is no method (to my knowledge) that IAX2 can notify the origin servers that the call has been terminated. The only way for any server in the path to know the status of the call (with IAX2) is to not transfer the call away from itself, thus bearing the full load of the media stream and the control channel. I would be happy to learn of other's experiences in managing this issue, as it is quite important (mandatory, really) in any type of managed service environment. If you depend on behavior of an unspecified client your asking for trouble. It would be pretty trivial to get a client to send back this 'Call Completed' message right after a re-invite/native bridge has completed. If you have access to the source you can modify the client to do it, or if you have access to the network you have something proxy'ng the packets and at certain times including or excluding certain messages James ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
James Golovich [EMAIL PROTECTED] wrote: On Tue, 15 Jun 2004, John Todd wrote: Not all Asterisk channel types lose control when they step out of the media stream. SIP devices will notify the proxy server (Asterisk, in our case) that a call has terminated, so even though the media stream never went through the proxy (Asterisk). This is an important distinction between IAX2 and SIP - media and control messages are not tightly linked with SIP as they are with IAX2. Until IAX2 has some If you depend on behavior of an unspecified client your asking for trouble. It would be pretty trivial to get a client to send back this 'Call Completed' message right after Then the PSTN is broken too. SS7 (the signalling portion) is separate from voice trunks. This was done because it was insecure doing exactly the opposite -- which put the signalling along with the media, which made phreaking phun and easy. IMO, signalling and media should be separate. The proxying system should know when the call is complete regardless of whether or not it's in the media, as proper billing depends on it. In the PSTN world, it's not the end users that are responsible for signalling the end of the call; the switches do that when the media path (i.e., voice trunk) is disconnected. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
At 5:13 PM -0400 on 6/15/04, James Golovich wrote: On Tue, 15 Jun 2004, John Todd wrote: Not all Asterisk channel types lose control when they step out of the media stream. SIP devices will notify the proxy server (Asterisk, in our case) that a call has terminated, so even though the media stream never went through the proxy (Asterisk). This is an important distinction between IAX2 and SIP - media and control messages are not tightly linked with SIP as they are with IAX2. Until IAX2 has some type of backwards path notification, there is no method (to my knowledge) that IAX2 can notify the origin servers that the call has been terminated. The only way for any server in the path to know the status of the call (with IAX2) is to not transfer the call away from itself, thus bearing the full load of the media stream and the control channel. I would be happy to learn of other's experiences in managing this issue, as it is quite important (mandatory, really) in any type of managed service environment. If you depend on behavior of an unspecified client your asking for trouble. It would be pretty trivial to get a client to send back this 'Call Completed' message right after a re-invite/native bridge has completed. If you have access to the source you can modify the client to do it, or if you have access to the network you have something proxy'ng the packets and at certain times including or excluding certain messages James 1) That is true with SIP as well, so the threat is already understood. If the Asterisk server in the middle receives a Call Completed message from one side, it should send a Call Completed message to the other side, which should (and I use the word SHOULD in the RFC meaning) cause the other side to hang up the call if it has not already done so. If there are two users of the same software package, and they conspire to generate bogus Call Completed messages and then ignore them, it would be possible for those two users to keep their media stream flowing and cheat the Asterisk server in the middle into thinking that the call had completed. However, the media stream is not flowing through any Asterisk components, so this risk is limited. The trick is that if the same provider controls one side of the channel then this is not a problem since the endpoint that is owned by the provider would honor the Call Completed message. I think my point is it's better to have some information than no information in a provider setting. It is ultimately impossible to regulate this if you're billing for it at the call level, but from a logging and troubleshooting perspective this is really a good thing to have. The ability (default setting) for IAX2-to-IAX2 calls to vanish from the server's perspective after a call is set up will cause future heartache from customer service, metrics-gathering, and legal perspectives. 2) Any method needs to understand and consider the possibility of multiple levels of transferring. This is the same headache with encryption. If I have an architecture of three or four levels deep of IAX2 connections that pass a call between each other, the original server probably should somehow have the _option_ of keeping track of that call's length and status, and optionally closing the call down. This is not just from a traditional telco point of view (billing, fraud, etc) but there are other reasons one might want to do this that are non-obvious. The originating server needs to be able to control the status of a call that was passed to it without nailing up the media stream. I might be wrong here, on two counts: first, that any server in the path of reference needs to know the state of a call. SIP is built on a stateless model, but Asterisk is half-stateless - it always keeps state for calls that are passing through it, but it tries to get rid of those calls as quickly as possible by relinquishing control to the clients. Maybe this is good, maybe it's ultimately flawed. The second place I might be flawed is that maybe we can keep the media stream; maybe it's not such a huge burden for what Asterisk is trying to do. G.729 or ilbc are down in the 20 kbps range, so for a system that claims to be a PBX, perhaps that's not a big deal. If this claimed to be a softswitch then that would be a problem. Many people are using it as a softswitch, which could cause the half-stateless and media relay problems to collide in a very ugly explosion of bad CDR's or Gig-E transit connections... JT ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
I might be wrong here, on two counts: first, that any server in the path of reference needs to know the state of a call. SIP is built on a stateless model, but Asterisk is half-stateless - it always keeps state for calls that are passing through it, but it tries to get rid of those calls as quickly as possible by relinquishing control to the clients. Maybe this is good, maybe it's ultimately flawed. The second place I might be flawed is that maybe we can keep the media stream; maybe it's not such a huge burden for what Asterisk is trying to do. G.729 or ilbc are down in the 20 kbps range, so for a system that claims to be a PBX, perhaps that's not a big deal. If this claimed to be a softswitch then that would be a problem. Many people are using it as a softswitch, which could cause the half-stateless and media relay problems to collide in a very ugly explosion of bad CDR's or Gig-E transit connections... JT How about producing UA box with * on it and 1-2 fxs/fxo ports. It should be a complete * system capable of dealing with 2-3 SIP/H323/IAX channels. Something like Soekris 4801 board stripped down or even some other CPU to keep the cost down. If box like this can be put together cost effectively, then this device could be used to be part of complete global system of * ONLY solution offering complete encryption and authentication. Encryption, because one can get each UA to establish required IPSEC tunnels dynamically where IP SEC tunnels could follow (or rather lead) media path. Authentication for purpose of CDR stored locally on UA and centrally. SSL certificates could be used on each UA to minimise fraud. In another words, if the media path is set to by pass one or more * servers, then each UA (originator and terminator) will have a job of dumping CDR details into their trusted * server after a call is completed. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Hi, -Original Message- Yes. The issue here is that billing information is never correct in such a scenario, since the call duration on the registered asterisk machine (the one that is kicked from the path) is no longer correct. To fix this a notransfer=yes is mandatory, but that defies the practicality of having a voip conversation take the shortest path. Sure... So, this issue is sort of a bug and it really needs to be implemented then! I'm afraid its not that simple. Unless I'm misunderstanding the concepts of IAX(2) design, it does not support such behaviour _by design_. Who knows what would break if someone hacked our desires in there. A solution then would be: choose another protocol. Technically you could spin off an IAX2-cdr channel that supports it, but that would require duplicate efforts to maintain both channels. My current position is 'deal with it' and accept the extra traffic. If someone with more knowledge about IAX(2) can comment on the feasability of this behaviour we may proceed in that direction, otherwise we're just stuck. Florian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Sure... So, this issue is sort of a bug and it really needs to be implemented then! I'm afraid its not that simple. Unless I'm misunderstanding the concepts of IAX(2) design, it does not support such behaviour _by design_. Who knows what would break if someone hacked our desires in there. A solution then would be: choose another protocol. Technically you could spin off an IAX2-cdr channel that supports it, but that would require duplicate efforts to maintain both channels. My current position is 'deal with it' and accept the extra traffic. If someone with more knowledge about IAX(2) can comment on the feasability of this behaviour we may proceed in that direction, otherwise we're just stuck. In that case, I suppose we have to put up with it untill it gets to be a real pain in the neck :) ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Hi, -Original Message- Try notransfer=no in iax.conf Hmm, I assume you mean transfer=no, but that also keeps the voice flow through the machine. Would IAX2 support having signalling going through all machines and voice data through the shortest path, more or less like how SIP works, while keeping the nice NAT/firewall functionality :-) I would not be surprised if this is impossible by design, but who knows... Florian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] CDR for transfered calls
Would IAX2 support having signalling going through all machines and voice data through the shortest path No, Signalling+Voice is tightly coupled. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Holger Schurig wrote: Would IAX2 support having signalling going through all machines and voice data through the shortest path No, Signalling+Voice is tightly coupled. To my knowledge, IAX2 will take shortest route possible. I.e. A call from UA A to UA C through server B will switch from original path (ABC) to (AC) and this is default behaviour unless notransfer=yes exist in iax.conf. Anyone know for sure? Ta Senad ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Hi, -Original Message- No, Signalling+Voice is tightly coupled. To my knowledge, IAX2 will take shortest route possible. I.e. A call from UA A to UA C through server B will switch from original path (ABC) to (AC) and this is default behaviour unless notransfer=yes exist in iax.conf. Yes. The issue here is that billing information is never correct in such a scenario, since the call duration on the registered asterisk machine (the one that is kicked from the path) is no longer correct. To fix this a notransfer=yes is mandatory, but that defies the practicality of having a voip conversation take the shortest path. Florian ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
Florian Overkamp wrote: Hi, -Original Message- No, Signalling+Voice is tightly coupled. To my knowledge, IAX2 will take shortest route possible. I.e. A call from UA A to UA C through server B will switch from original path (ABC) to (AC) and this is default behaviour unless notransfer=yes exist in iax.conf. Yes. The issue here is that billing information is never correct in such a scenario, since the call duration on the registered asterisk machine (the one that is kicked from the path) is no longer correct. To fix this a notransfer=yes is mandatory, but that defies the practicality of having a voip conversation take the shortest path. Sure... So, this issue is sort of a bug and it really needs to be implemented then! ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] CDR for transfered calls
Hi there, I have the following scenario: I want user A to make a call to user B. If, any of these users transfer the call to user C, then asterisk should generate a CDR for the first leg of the call. And after the transfered call is finished, asterisk should generate a second CDR. I believe I was able to do it once, a long time ago... But, I tried this feature again today, and asterisk was generating only one CDR (for the transfered call). Is this possible? I use aterisk 0.7.2 with Grandstream phones. thanks in advance, Pablo Salinas ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] CDR for transfered calls
pesb wrote: Hi there, I have the following scenario: I want user A to make a call to user B. If, any of these users transfer the call to user C, then asterisk should generate a CDR for the first leg of the call. And after the transfered call is finished, asterisk should generate a second CDR. I believe I was able to do it once, a long time ago... But, I tried this feature again today, and asterisk was generating only one CDR (for the transfered call). Is this possible? I use aterisk 0.7.2 with Grandstream phones. thanks in advance, Pablo Salinas Try notransfer=no in iax.conf ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
