Hi,
I know the commande
#openserctl monitor
and
# openserctl fifo get_statistics all
But i like have the number of INVITE / second in openser and the succeful INVITE/second.
Who know any commande to have this statistic?
thanks
See below...
> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
> Sent: Wednesday, November 26, 2008 1:21 AM
[...]
>
> This is clearly a bug in the useragent. The route set must not be
> changed with reINVITEs. Thus, according to the standard the
> Record-Route
> headers for indialog requests are not needed. Maybe you are calling
> record_route() for indialog requests and this confuses the client.
Fully agree on this. But some proxies add Record-Route, some don't,
Openser/Kamailio can configure it.
It's not that clear in the RFC, but I see it the same way:
RFC 3261, 12.2 Request within a Dialog
...
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
12.2.1.2 Processing the Responses
-> The only thing mentioned is that the _Target URI_ gets refreshed by
the 200 OK.
=> reInvites do not modify the routeset of any subsequent request,
neither the ACK not any other upcoming request.
> Try removing the record_route() for indialog requests - may then the
> buggy client remembers the original route set.
Done. Client sends ACK on reInvite directly then :-( Counterpath is OK,
Teles Voipbox not, other clients to be tested ...
So I will have to add vsf uri param from Route to record route in the
proxy. This at least is a reason to upgrade :-) It's done more easily
with tranformations.
Thanks for the discussion! For me it's "clearly a bug in the UA" now,
too ;-) However, let's find a workaround.
br
Walter
Hi all,
I have openser 1.1.0 and i can't do any change before i'm certain.
can i write this code or we have an other syntaxe with version 1.1.
$avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>';
append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n");
thanks
Hi,
I want to disply a number "010101010101" with use of RFC 3325 in openser.
I read the RFC 3325 but i don't understand how do it.
Where i put this number ? in diply name in P-Asserted-Identity, in username in P-Asserted-Identity ,in diply name in FROM or in username in FROM ?
Hello,
I need to change the to sip header.
How can I do it?
Cordialement,
BERGANZ François
cid:image001.gif@01C8F7CD.6BC1D2C0
http://www.acropolistelecom.net <http://www.acropolistelecom.net/>
P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.
Hi all,
I have openser 1.1.0 and i can't do any change before i'm certain.
can i write this code or we have an other syntaxe with version 1.1.
$avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>';
append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n");
thanks
Hi Klaus!
Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header.
Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again?
Let's see, what I can do here.
Br
Walter
-----Ursprüngliche Nachricht-----
Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Gesendet: Dienstag, 25. November 2008 18:04
An: Schober Walter
Cc: users(a)lists.kamailio.org
Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite
Hi Walter!
Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header.
I can not remember any changes in UAC module, thus I am not sure if an update will help you.
regards
klaus
Schober Walter wrote:
> Hello All!
>
> Tried to fix that anyhow but without success yet. Anyone who could
> just tell me, if it's fixed in 1.4.something?
>
> Scenario:
> A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize
> From to phone number in national format) -> B
>
> A Invites B => all OK
> A reInvites B with T.38 -> INVITE => OK
> <- 200 OK => OK
> -> ACK => From field not handled by UAC.
>
> UAC config all default, so UAC restore mode "auto". Neither INVITE nor
> ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's
> handled properly.
>
> Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never
> touch a running system, isn't it?
> But then that customer comes with that Allied Telesis CPE :-) (And Ati
> blames the proxy for not matching the ACK in the CPE although they use
> a from-tag, too).
>
> Many Thanks!
> br
> Walter
>
> _______________________________________________
> Users mailing list
> Users(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello All!
Tried to fix that anyhow but without success yet. Anyone who could just
tell me, if it's fixed in 1.4.something?
Scenario:
A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From
to phone number in national format) -> B
A Invites B => all OK
A reInvites B with T.38 -> INVITE => OK
<- 200 OK => OK
-> ACK => From field not handled by UAC.
UAC config all default, so UAC restore mode "auto". Neither INVITE nor
ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's
handled properly.
Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never
touch a running system, isn't it?
But then that customer comes with that Allied Telesis CPE :-) (And Ati
blames the proxy for not matching the ACK in the CPE although they use a
from-tag, too).
Many Thanks!
br
Walter
----- Mensaje original -----
De: Matteo D'Amato <matteo(a)ecosma.com>
Fecha: Martes, Noviembre 25, 2008 10:12 am
Asunto: [Kamailio-Users] Username vs DID
> Yes I am using a PSTN Gateway, should I create a new table to hold
> the link between the username and DID or do I use the information
> in the alias table?
>
> And there may be some local calls between users, so are you saying
> it would have been easier to use their actual DID numbers as their
> usernames?
I have seen something like this
ie:
PSTN Number: 7565079
Internal Extension:5079
So you use as username= 5079, and PSTN number 7565079.
But it's always better, I think, to have internal user names as "John" and associate its DID only when he is trying to reach the PSTN, adding the RFC 3325 header field P-Asserted-Identity with the DID number.
> --Matteo
