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(a)iptel.org
>>>>
http://mail.iptel.org/mailman/listinfo/serusers
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)openser.org
>>>
http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)iptel.org
>
http://mail.iptel.org/mailman/listinfo/serusers
>