I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Hello
On 10/31/05 00:27, Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
You have to check that there is no BYE with same call-id, To and From tags as the INVITE. Since the BYE may be sent by any of the parties in the call, you have to do a cross check of the tags, too.
Daniel
- Daryl
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Thanks for the help guys! This is just what I was loookig for.
- Daryl
On 10/31/05, Evan Borgstrom evan.borgstrom@ca.mci.com wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
I am currently working on inbound calls I have setup a DID alias to my login and it rings. The only problem is if I answer it is dead air. I am beginning to think it may be a NAT issue. Is anyone using SER for Inbound calls and have something that works with a natted client?? Outbound currently works great!!
Thx for any help.
Eric
After fooling around with nathelper/rtp_proxy etc. for weeks I finally gave up and installed mediaproxy and now everything is working fine.
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Eric Haskins Sent: Monday, October 31, 2005 1:32 PM To: SER Users Subject: [Serusers] Forwarding inbound(PSTN DID) calls to NATTED Client
I am currently working on inbound calls I have setup a DID alias to my login and it rings. The only problem is if I answer it is dead air. I am beginning to think it may be a NAT issue. Is anyone using SER for Inbound calls and have something that works with a natted client?? Outbound currently works great!!
Thx for any help.
Eric
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Be careful because some user agents use same call id many times. To be 100% sure, you have to check the From and To tags, too.
Cheers, Daniel
On 10/31/05 17:31, Evan Borgstrom wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Any idea which user agants have this problem?
- Daryl
On 11/1/05, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Be careful because some user agents use same call id many times. To be 100% sure, you have to check the From and To tags, too.
Cheers, Daniel
On 10/31/05 17:31, Evan Borgstrom wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
If a UA doesn't change it's call id on every new transaction or it reuses call id's then drop support for the UA in your network and tell the vendor to fix their broken implementation. I'm tired of seeing little kludges to deal with one or two broken vendors. Section 8.1.1.4 of RFC 3261:
In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA.
AFAIK there's no method specific behavior for INVITE's that would warrant the UA's reusing call-id's...
-Evan
Daniel-Constantin Mierla wrote:
Be careful because some user agents use same call id many times. To be 100% sure, you have to check the From and To tags, too.
Cheers, Daniel
On 10/31/05 17:31, Evan Borgstrom wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On 11/01/05 20:46, Evan Borgstrom wrote:
If a UA doesn't change it's call id on every new transaction or it
reuses call id's then drop support for the UA in your network and tell the vendor to fix their broken implementation. I'm tired of seeing little kludges to deal with one or two broken vendors. Section 8.1.1.4 of RFC 3261:
In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA.
Here is where the problem usually occurs. Most of the UA I have seen relies on IP address to fulfill this requirement, but this fails in the case of private addresses. Usually, the call id is in the form of "some_hash@ip".
According to RFC, what really identifies the call is call-id, from-tag and to-tag, so in my opinion is better to use all of them. If you control the type of user agents in your network, then you can do a lot of optimization everywhere, in an open environment you have to be prepared for the worst (btw: I am not at all voip service provider/itsp). Just for example, the person implementing serweb chose the same approach, to check the tags when getting cdrs, too.
Daniel
AFAIK there's no method specific behavior for INVITE's that would
warrant the UA's reusing call-id's...
-Evan
Daniel-Constantin Mierla wrote:
Be careful because some user agents use same call id many times. To be 100% sure, you have to check the From and To tags, too.
Cheers, Daniel
On 10/31/05 17:31, Evan Borgstrom wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Daniel-Constantin Mierla wrote:
On 11/01/05 20:46, Evan Borgstrom wrote:
If a UA doesn't change it's call id on every new transaction or it
reuses call id's then drop support for the UA in your network and tell the vendor to fix their broken implementation. I'm tired of seeing little kludges to deal with one or two broken vendors. Section 8.1.1.4 of RFC 3261:
In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA.
Here is where the problem usually occurs. Most of the UA I have seen relies on IP address to fulfill this requirement, but this fails in the case of private addresses. Usually, the call id is in the form of "some_hash@ip".
How would the UA having a RFC1918 IP address cause it fail? It's still a valid address it's just not routable, besides it's the part before @ip that's really important. md5(time() + my_mac_address) will give you a "unique identifier over space and time" so there's no excuse for reusing or not generating unique call-id's.
According to RFC, what really identifies the call is call-id, from-tag and to-tag, so in my opinion is better to use all of them. If you control the type of user agents in your network, then you can do a lot of optimization everywhere, in an open environment you have to be prepared for the worst (btw: I am not at all voip service provider/itsp). Just for example, the person implementing serweb chose the same approach, to check the tags when getting cdrs, too.
You're right, it is better to use all of them but for the point of the query (which is not meant to be authoritative but informative) using just the call-id should be more than enough so long as vendor's are not lazy and properly implement call-id's.
-Evan
Daniel
AFAIK there's no method specific behavior for INVITE's that would
warrant the UA's reusing call-id's...
-Evan
Daniel-Constantin Mierla wrote:
Be careful because some user agents use same call id many times. To be 100% sure, you have to check the From and To tags, too.
Cheers, Daniel
On 10/31/05 17:31, Evan Borgstrom wrote:
Here's a query to find "active calls".
SELECT t1.from_uri as orig_number, t1.to_uri as term_number, DATE_FORMAT(t1.timestamp, '%a %b %D %Y, %h:%i:%s %p') as calldate, t1.sip_callid as callid FROM acc t1 WHERE t1.timestamp > (NOW() - 14400) AND t1.sip_method='INVITE' AND t1.sip_callid NOT IN (SELECT t2.sip_callid FROM acc t2 WHERE t2.sip_method = 'BYE')
The calldate is formatted a way that I prefer (eg. Mon Oct 31st 2005, 09:49:20 AM), feel free to change it. The other thing to note is "t1.timestamp > (NOW() - 14400)", this sets the query to only find INVITEs in the last 4 hours to handle situations where INVITEs are sent but BYEs aren't.
-Evan
Daryl Sanders wrote:
I'm trying to come up with a query on the acc table that will return all INVITES that don't have a matching BYE. I'm basically looking for sessions that are currently open.
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
On 01-11-2005 15:41, Evan Borgstrom wrote:
Daniel-Constantin Mierla wrote:
On 11/01/05 20:46, Evan Borgstrom wrote:
If a UA doesn't change it's call id on every new transaction or it reuses call id's then drop support for the UA in your network and tell the vendor to fix their broken implementation. I'm tired of seeing little kludges to deal with one or two broken vendors. Section 8.1.1.4 of RFC 3261:
In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA.
Here is where the problem usually occurs. Most of the UA I have seen relies on IP address to fulfill this requirement, but this fails in the case of private addresses. Usually, the call id is in the form of "some_hash@ip".
How would the UA having a RFC1918 IP address cause it fail? It's still a valid address it's just not routable, besides it's the part before @ip that's really important. md5(time() + my_mac_address) will give you a "unique identifier over space and time" so there's no excuse for reusing or not generating unique call-id's.
Right, if you can determine current time. This is not always the case, you can have a phone that was rebooted and has neither internal clock nor access to NTP.
Jan.