4 Sep
2006
4 Sep
'06
11:04 a.m.
I've added the following lines to my ser.cfg file:
###################
modparam("usrloc", "use_domain", 1) #If the domain part of the
user
should be also saved and used for identifing the user (along with the
username part). Useful in multi domain scenarios. Non 0 value means true.
modparam("registrar", "use_domain", 1) # If set to 1 then the
registrar
will use username@domain as address of record. If the variable is set to
0 then only username will be used as the address of record. Default
value is 0.
###################
I've added 2 diferent domains to the domain table, and got different
phones registered with those different domains.
Although, after editing that way ser.cfg file, my phones still register
in Ser, but none of them can call any other, even if I call someone only
by username or by username@domain.
Am I in the right path to configure a multi-domain Ser server? What else
should I do to make things work fine?
Regards,
Ricardo.
5 Sep
5 Sep
3:41 a.m.
Yes, you are on the right path :-)
I'm not sure why you cannot reach others. It sounds like a more
fundamental problem... Look at the AORs with serctl. Are they
registered correctly? If you don't use domain for usrloc, what happens?
g-)
Ricardo Carvalho wrote:
I've added the following lines to my ser.cfg
file:
###################
modparam("usrloc", "use_domain", 1) #If the domain part of the
user should be also saved and used for identifing the user (along with
the username part). Useful in multi domain scenarios. Non 0 value
means true.
modparam("registrar", "use_domain", 1) # If set to 1 then the
registrar will use username@domain as address of record. If the
variable is set to 0 then only username will be used as the address of
record. Default value is 0.
###################
I've added 2 diferent domains to the domain table, and got different
phones registered with those different domains.
Although, after editing that way ser.cfg file, my phones still
register in Ser, but none of them can call any other, even if I call
someone only by username or by username@domain.
Am I in the right path to configure a multi-domain Ser server? What
else should I do to make things work fine?
Regards,
Ricardo.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:40 a.m.
In fact what was happening was that I was using aliases to dial users
and it isn't working because as it could be seen with "serctl ul show"
aliases don't have the domain in AOR. It can be seen bellow in this
e-mail. Because of this, when I dial the alias of some user (5101 for
exemple), in the debug of Ser results "lookup(): '5101@domain_B' Not
found in usrloc" and then the call fails obviously.
How can I add the domain of each user to the AOR of their aliases?
On the other hand, as expected, when I call someone by their
"username@domain_A", it rings phones registered with that user and that
domain_A, and when I call someone by their "username@domain_B", it rings
phones registered with that user and that domain_B. This is expected
because I can see with "serctl ul show" that users have their AOR with
their domain as can be seen below in this e-mail.
Unfortunately there is one more problem. When I dial just the username
of someone (like "test") without his domain, it rings the phone
registered with test@domain_A. How can I make in this situations the
call being rejected like with "404", "User Not Found" reply?
Thank a lot,
Ricardo.
"serctl ul show" results:
##########################################
...Record(0xb6174e60)...
domain: 'aliases'
aor : '5101@'
~~~Contact(0xb6174ea0)~~~
domain : 'aliases'
aor : '5101@'
Contact : 'sip:test@domain_B'
Expires : Permanent
q : 1
Call-ID :
'The-Answer-To-The-Ultimate-Question-Of-Life-Universe-And-Everything'
CSeq : 42
User-Agent: 'SIP Express Router FIFO'
received : ''
State : CS_SYNC
Flags : 128
next : (nil)
prev : (nil)
~~~/Contact~~~~
.../Record...
domain: 'location'
aor : 'test@domain_B'
~~~Contact(0xb6177d10)~~~
domain : 'location'
aor : 'test@domain_B'
Contact : 'sip:test@192.168.6.13:5060'
Expires : 1633
q :
Call-ID : '7B2CA981D23AE8B62820D8B4F36F9E5C@domain_B'
CSeq : 53668
User-Agent: 'X-Lite release 1105d'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
.../Record...
##########################################
Greger V. Teigre wrote:
Yes, you are on the right path :-)
I'm not sure why you cannot reach others. It sounds like a more
fundamental problem... Look at the AORs with serctl. Are they
registered correctly? If you don't use domain for usrloc, what happens?
g-)
Ricardo Carvalho wrote:
I've added the following lines to my ser.cfg
file:
###################
modparam("usrloc", "use_domain", 1) #If the domain part of the
user should be also saved and used for identifing the user (along
with the username part). Useful in multi domain scenarios. Non 0
value means true.
modparam("registrar", "use_domain", 1) # If set to 1 then the
registrar will use username@domain as address of record. If the
variable is set to 0 then only username will be used as the address
of record. Default value is 0.
###################
I've added 2 diferent domains to the domain table, and got different
phones registered with those different domains.
Although, after editing that way ser.cfg file, my phones still
register in Ser, but none of them can call any other, even if I call
someone only by username or by username@domain.
Am I in the right path to configure a multi-domain Ser server? What
else should I do to make things work fine?
Regards,
Ricardo.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10 a.m.
New subject: [Serusers] Retransmission problem
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
6 Sep
6 Sep
3:18 a.m.
New subject: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get
problems because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly
what you do (and probably not then either)
3. When having problems like that, use a pretested Getting Started
config fil (http://iptel.org/ser/doc/gettingstarted). If you still have
the problem, there is something external (like UA2 on same box as SER).
Fix it and then compare the logic of your config file with the Getting
Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:32 a.m.
New subject: R: [Serusers] Retransmission problem
Many thanks for the reply, it is very useful but it contains bad news because, if is it
possible, it is important for me to preserve the possibility to have the SIP proxy and SIP
gateway in the same board. <?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to proxy and gateway,
can I leave them on the same hardware?
2. If I correctly understand the transaction creation in SER: SER absorbs the
retransmission only if already exists a transaction for the original INVITE and SER
creates a new transaction for an INVITE only when is invoked the t_relay. Consequently, If
a retransmitted INVITE arrives when the elaboration of the original INVITE is still in
progress, SER repeats all the elaboration also for the second INVITE.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be slow (it does an
external query, something similar to an exec) and it is important that I don't invoke
it twice for the same INVITE, so I try to use t_newtran to anticipate the transaction
creation before invoking this function.
However, as first step, I will remove the t_newtran, t_forward_nonack_uri and I try
again.
Thanks again.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: mercoledì 6 settembre 2006 9.19
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get problems
because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly what you do
(and probably not then either)
3. When having problems like that, use a pretested Getting Started config fil (
http://iptel.org/ser/doc/gettingstarted). If you still have the problem, there is
something external (like UA2 on same box as SER). Fix it and then compare the logic of
your config file with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
_____
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
7 Sep
7 Sep
3:23 a.m.
New subject: R: [Serusers] Retransmission problem
Inline.
Zappasodi Daniele wrote:
Many thanks for the reply, it is very useful but it contains bad news
because, if is it possible, it is important for me to preserve the
possibility to have the SIP proxy and SIP gateway in the same board.
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to
proxy and gateway, can I leave them on the same hardware?
Yes, the trick is to get the listen and alias directives correct in your
ser.cfg. You can run multiple servers or UAs on the same server, you
just have to make sure you don't have alias=myip in ser.cfg. This will
make SER believe messages for another server/UA is to be routed locally.
2. If I correctly understand the transaction creation in SER: SER
absorbs the retransmission only if already exists a transaction for
the original INVITE and SER creates a new transaction for an INVITE
only when is invoked the t_relay.
Yes, if not, SER will be transaction stateless and just happily forward
any message.
Consequently, If a retransmitted INVITE arrives when the elaboration
of the original INVITE is still in progress, SER repeats all the
elaboration also for the second INVITE.
I'm not sure what you mean by "elaboration", but if you mean that the
script will be executed for retransmitted INVITEs, then yes.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be
slow (it does an external query, something similar to an exec) and it
is important that I don't invoke it twice for the same INVITE, so I
try to use t_newtran to anticipate the transaction creation before
invoking this function.
However, as first step, I will remove the t_newtran,
t_forward_nonack_uri and I try again.
Normally, you should not have to worry about the transaction state, just
process the INVITE and use t_relay() and let SER handle the
retransmissions etc. I cannot see that your scenario would require more
fine-grained control over the transaction state, but then I don't know
what you are trying to do...
g-)
Thanks again.
-----Messaggio originale-----
*Da:* Greger V. Teigre [mailto:greger@teigre.com]
*Inviato:* mercoledì 6 settembre 2006 9.19
*A:* Zappasodi Daniele
*Cc:* serusers(a)lists.iptel.org
*Oggetto:* Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely
to get problems because SER sees it's own IP address in a message
destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know
exactly what you do (and probably not then either)
3. When having problems like that, use a pretested Getting Started
config fil (http://iptel.org/ser/doc/gettingstarted). If you still
have the problem, there is something external (like UA2 on same
box as SER). Fix it and then compare the logic of your config file
with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly
and it resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the
packet after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the
relevant parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in
lo_capture.cap between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
21 Sep
21 Sep
9:09 a.m.
New subject: R: R: [Serusers] Retransmission problem
Hello,
In the past days I have done some tests: I have removed the t_newtran and
t_forward_nonackuri (now I use only t_relay) and I have put the proxy on a different
address, but the problem persists.
Looking better the syslog I have observed that the retransmission occurs when happens this
situation:
a child process handles the INVITE, forwards it, but after it sends out the UDP message,
the OS gives the execution control to other children, so it can't complete the
execution and in particular it can't set the retransmission timer (start_retr in
t_forward_non_ack).
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: _reply_light: finished
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: mk_proxy: doing DNS lookup...
Sep 13 10:14:32 SAM-IP ser[870]: check_via_address(10.1.9.170, 10.1.9.170, 0)
...
Now are in execution the other children, while the it remains suspended. When the OS gives
again the control to the first "INVITE child" it completes the execution (with
start_retr and so on), but sometimes takes it too late, after the arrive of a final reply
(480 Temporarily Unavailible):
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[4]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[0]: 0x405e3c90
Sep 13 10:14:33 SAM-IP ser[870]: SER: new transaction fwd'ed
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG:destroy_avp_list: destroying list (nil)
Sep 13 10:14:33 SAM-IP ser[870]: receive_msg: cleaning up
In this case, immediately after it set the retransmission timeout, the timer process
starts the retrasmission of the original INVITE, without waiting the timeout value (1
second) and moreover without taking care of the fact that the transaction is deleted:
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:0,tl=0x405e3c24 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c14 next=0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405ea470 next=0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405ea358, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c80 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405e3b68, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
I suppose that the inconsistency is related to the setting of the timer after the
"480", probably in the handling of the final reply there is the cleaning of the
retransmission timer, but in this race condition the timer is set after the 480.
I'm not familiar with the internal code of the tm and timer modules, but what do you
think if I change the position of the instructions in the t_forward_non_ack function in
order to set the timer before sending out the UDP packet?
start_retr( &t->uac[i].request );
if (added_branches & (1<<i)) {
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
I hope in this way, the handling of the final reply cleans correctly the timer.
Otherwise I would put some test before the start_retr function to understand if the
transaction is still alive.
Regards,
Daniele.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: giovedì 7 settembre 2006 9.24
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: R: [Serusers] Retransmission problem
Inline.
Zappasodi Daniele wrote:
Many thanks for the reply, it is very useful but it contains bad news because, if is it
possible, it is important for me to preserve the possibility to have the SIP proxy and SIP
gateway in the same board.
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to proxy and gateway,
can I leave them on the same hardware?
Yes, the trick is to get the listen and alias directives correct in your ser.cfg. You can
run multiple servers or UAs on the same server, you just have to make sure you don't
have alias=myip in ser.cfg. This will make SER believe messages for another server/UA is
to be routed locally.
2. If I correctly understand the transaction creation in SER: SER absorbs the
retransmission only if already exists a transaction for the original INVITE and SER
creates a new transaction for an INVITE only when is invoked the t_relay.
Yes, if not, SER will be transaction stateless and just happily forward any message.
Consequently, If a retransmitted INVITE arrives when the elaboration of the original
INVITE is still in progress, SER repeats all the elaboration also for the second INVITE.
I'm not sure what you mean by "elaboration", but if you mean that the script
will be executed for retransmitted INVITEs, then yes.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be slow (it does an
external query, something similar to an exec) and it is important that I don't invoke
it twice for the same INVITE, so I try to use t_newtran to anticipate the transaction
creation before invoking this function.
However, as first step, I will remove the t_newtran, t_forward_nonack_uri and I try
again.
Normally, you should not have to worry about the transaction state, just process the
INVITE and use t_relay() and let SER handle the retransmissions etc. I cannot see that
your scenario would require more fine-grained control over the transaction state, but then
I don't know what you are trying to do...
g-)
Thanks again.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: mercoledì 6 settembre 2006 9.19
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get problems
because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly what you do
(and probably not then either)
3. When having problems like that, use a pretested Getting Started config fil
(http://iptel.org/ser/doc/gettingstarted). If you still have the problem, there is
something external (like UA2 on same box as SER). Fix it and then compare the logic of
your config file with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
9:29 a.m.
New subject: R: R: [Serusers] Retransmission problem
Hello,
A correction to my previous email:
start_retr must go inside the if
if (added_branches & (1<<i)) {
start_retr( &t->uac[i].request );
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
Regards,
Daniele
-----Messaggio originale-----
Da: Zappasodi Daniele
Inviato: giovedì 21 settembre 2006 15.09
A: 'Greger V. Teigre'
Cc: serusers(a)lists.iptel.org
Oggetto: R: R: [Serusers] Retransmission problem
Hello,
In the past days I have done some tests: I have removed the t_newtran and
t_forward_nonackuri (now I use only t_relay) and I have put the proxy on a different
address, but the problem persists.
Looking better the syslog I have observed that the retransmission occurs when happens this
situation:
a child process handles the INVITE, forwards it, but after it sends out the UDP message,
the OS gives the execution control to other children, so it can't complete the
execution and in particular it can't set the retransmission timer (start_retr in
t_forward_non_ack).
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: _reply_light: finished
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: mk_proxy: doing DNS lookup...
Sep 13 10:14:32 SAM-IP ser[870]: check_via_address(10.1.9.170, 10.1.9.170, 0)
...
Now are in execution the other children, while the it remains suspended. When the OS gives
again the control to the first "INVITE child" it completes the execution (with
start_retr and so on), but sometimes takes it too late, after the arrive of a final reply
(480 Temporarily Unavailible):
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[4]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[0]: 0x405e3c90
Sep 13 10:14:33 SAM-IP ser[870]: SER: new transaction fwd'ed
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG:destroy_avp_list: destroying list (nil)
Sep 13 10:14:33 SAM-IP ser[870]: receive_msg: cleaning up
In this case, immediately after it set the retransmission timeout, the timer process
starts the retrasmission of the original INVITE, without waiting the timeout value (1
second) and moreover without taking care of the fact that the transaction is deleted:
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:0,tl=0x405e3c24 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c14 next=0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405ea470 next=0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405ea358, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c80 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405e3b68, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
I suppose that the inconsistency is related to the setting of the timer after the
"480", probably in the handling of the final reply there is the cleaning of the
retransmission timer, but in this race condition the timer is set after the 480.
I'm not familiar with the internal code of the tm and timer modules, but what do you
think if I change the position of the instructions in the t_forward_non_ack function in
order to set the timer before sending out the UDP packet?
start_retr( &t->uac[i].request );
if (added_branches & (1<<i)) {
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
I hope in this way, the handling of the final reply cleans correctly the timer.
Otherwise I would put some test before the start_retr function to understand if the
transaction is still alive.
Regards,
Daniele.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: giovedì 7 settembre 2006 9.24
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: R: [Serusers] Retransmission problem
Inline.
Zappasodi Daniele wrote:
Many thanks for the reply, it is very useful but it contains bad news because, if is it
possible, it is important for me to preserve the possibility to have the SIP proxy and SIP
gateway in the same board.
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to proxy and gateway,
can I leave them on the same hardware?
Yes, the trick is to get the listen and alias directives correct in your ser.cfg. You can
run multiple servers or UAs on the same server, you just have to make sure you don't
have alias=myip in ser.cfg. This will make SER believe messages for another server/UA is
to be routed locally.
2. If I correctly understand the transaction creation in SER: SER absorbs the
retransmission only if already exists a transaction for the original INVITE and SER
creates a new transaction for an INVITE only when is invoked the t_relay.
Yes, if not, SER will be transaction stateless and just happily forward any message.
Consequently, If a retransmitted INVITE arrives when the elaboration of the original
INVITE is still in progress, SER repeats all the elaboration also for the second INVITE.
I'm not sure what you mean by "elaboration", but if you mean that the script
will be executed for retransmitted INVITEs, then yes.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be slow (it does an
external query, something similar to an exec) and it is important that I don't invoke
it twice for the same INVITE, so I try to use t_newtran to anticipate the transaction
creation before invoking this function.
However, as first step, I will remove the t_newtran, t_forward_nonack_uri and I try
again.
Normally, you should not have to worry about the transaction state, just process the
INVITE and use t_relay() and let SER handle the retransmissions etc. I cannot see that
your scenario would require more fine-grained control over the transaction state, but then
I don't know what you are trying to do...
g-)
Thanks again.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: mercoledì 6 settembre 2006 9.19
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get problems
because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly what you do
(and probably not then either)
3. When having problems like that, use a pretested Getting Started config fil
(http://iptel.org/ser/doc/gettingstarted). If you still have the problem, there is
something external (like UA2 on same box as SER). Fix it and then compare the logic of
your config file with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
22 Sep
22 Sep
2:13 a.m.
New subject: R: R: [Serusers] Retransmission problem
Daniele,
This is way beyond scope of serusers :-) Kudos to you for thorough
debugging. I'm afraid my knowledge of implementation of the timers is
not good enough to pretend to say something smart...
I suggest you post this to serdev.
g-)
Zappasodi Daniele wrote:
Hello,
A correction to my previous email:
start_retr must go inside the if
if (added_branches & (1<<i)) {
start_retr( &t->uac[i].request );
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
Regards,
Daniele
-----Messaggio originale-----
Da: Zappasodi Daniele
Inviato: giovedì 21 settembre 2006 15.09
A: 'Greger V. Teigre'
Cc: serusers(a)lists.iptel.org
Oggetto: R: R: [Serusers] Retransmission problem
Hello,
In the past days I have done some tests: I have removed the t_newtran and
t_forward_nonackuri (now I use only t_relay) and I have put the proxy on a different
address, but the problem persists.
Looking better the syslog I have observed that the retransmission occurs when happens
this situation:
a child process handles the INVITE, forwards it, but after it sends out the UDP message,
the OS gives the execution control to other children, so it can't complete the
execution and in particular it can't set the retransmission timer (start_retr in
t_forward_non_ack).
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: _reply_light: finished
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: mk_proxy: doing DNS lookup...
Sep 13 10:14:32 SAM-IP ser[870]: check_via_address(10.1.9.170, 10.1.9.170, 0)
...
Now are in execution the other children, while the it remains suspended. When the OS
gives again the control to the first "INVITE child" it completes the execution
(with start_retr and so on), but sometimes takes it too late, after the arrive of a final
reply (480 Temporarily Unavailible):
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[4]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[0]: 0x405e3c90
Sep 13 10:14:33 SAM-IP ser[870]: SER: new transaction fwd'ed
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG:destroy_avp_list: destroying list (nil)
Sep 13 10:14:33 SAM-IP ser[870]: receive_msg: cleaning up
In this case, immediately after it set the retransmission timeout, the timer process
starts the retrasmission of the original INVITE, without waiting the timeout value (1
second) and moreover without taking care of the fact that the transaction is deleted:
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:0,tl=0x405e3c24 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c14 next=0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405ea470 next=0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405ea358, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c80 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405e3b68, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
I suppose that the inconsistency is related to the setting of the timer after the
"480", probably in the handling of the final reply there is the cleaning of the
retransmission timer, but in this race condition the timer is set after the 480.
I'm not familiar with the internal code of the tm and timer modules, but what do you
think if I change the position of the instructions in the t_forward_non_ack function in
order to set the timer before sending out the UDP packet?
start_retr( &t->uac[i].request );
if (added_branches & (1<<i)) {
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
I hope in this way, the handling of the final reply cleans correctly the timer.
Otherwise I would put some test before the start_retr function to understand if the
transaction is still alive.
Regards,
Daniele.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: giovedì 7 settembre 2006 9.24
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: R: [Serusers] Retransmission problem
Inline.
Zappasodi Daniele wrote:
Many thanks for the reply, it is very useful but it contains bad news because, if is it
possible, it is important for me to preserve the possibility to have the SIP proxy and SIP
gateway in the same board.
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to proxy and gateway,
can I leave them on the same hardware?
Yes, the trick is to get the listen and alias directives correct in your ser.cfg. You can
run multiple servers or UAs on the same server, you just have to make sure you don't
have alias=myip in ser.cfg. This will make SER believe messages for another server/UA is
to be routed locally.
2. If I correctly understand the transaction creation in SER: SER absorbs the
retransmission only if already exists a transaction for the original INVITE and SER
creates a new transaction for an INVITE only when is invoked the t_relay.
Yes, if not, SER will be transaction stateless and just happily forward any message.
Consequently, If a retransmitted INVITE arrives when the elaboration of the original
INVITE is still in progress, SER repeats all the elaboration also for the second INVITE.
I'm not sure what you mean by "elaboration", but if you mean that the
script will be executed for retransmitted INVITEs, then yes.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be slow (it does an
external query, something similar to an exec) and it is important that I don't invoke
it twice for the same INVITE, so I try to use t_newtran to anticipate the transaction
creation before invoking this function.
However, as first step, I will remove the t_newtran, t_forward_nonack_uri and I try
again.
Normally, you should not have to worry about the transaction state, just process the
INVITE and use t_relay() and let SER handle the retransmissions etc. I cannot see that
your scenario would require more fine-grained control over the transaction state, but then
I don't know what you are trying to do...
g-)
Thanks again.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: mercoledì 6 settembre 2006 9.19
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get problems
because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly what you do
(and probably not then either)
3. When having problems like that, use a pretested Getting Started config fil
(http://iptel.org/ser/doc/gettingstarted). If you still have the problem, there is
something external (like UA2 on same box as SER). Fix it and then compare the logic of
your config file with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
2:55 a.m.
New subject: R: R: R: [Serusers] Retransmission problem
Hello Greger,
Thanks anyway, I will post the question to serdev.
Regards,
Daniele
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: venerdì 22 settembre 2006 8.14
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: R: R: [Serusers] Retransmission problem
Daniele,
This is way beyond scope of serusers :-) Kudos to you for thorough
debugging. I'm afraid my knowledge of implementation of the timers is
not good enough to pretend to say something smart...
I suggest you post this to serdev.
g-)
Zappasodi Daniele wrote:
Hello,
A correction to my previous email:
start_retr must go inside the if
if (added_branches & (1<<i)) {
start_retr( &t->uac[i].request );
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
Regards,
Daniele
-----Messaggio originale-----
Da: Zappasodi Daniele
Inviato: giovedì 21 settembre 2006 15.09
A: 'Greger V. Teigre'
Cc: serusers(a)lists.iptel.org
Oggetto: R: R: [Serusers] Retransmission problem
Hello,
In the past days I have done some tests: I have removed the t_newtran and
t_forward_nonackuri (now I use only t_relay) and I have put the proxy on a different
address, but the problem persists.
Looking better the syslog I have observed that the retransmission occurs when happens
this situation:
a child process handles the INVITE, forwards it, but after it sends out the UDP message,
the OS gives the execution control to other children, so it can't complete the
execution and in particular it can't set the retransmission timer (start_retr in
t_forward_non_ack).
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: _reply_light: finished
Sep 13 10:14:32 SAM-IP ser[870]: DEBUG: mk_proxy: doing DNS lookup...
Sep 13 10:14:32 SAM-IP ser[870]: check_via_address(10.1.9.170, 10.1.9.170, 0)
...
Now are in execution the other children, while the it remains suspended. When the OS
gives again the control to the first "INVITE child" it completes the execution
(with start_retr and so on), but sometimes takes it too late, after the arrive of a final
reply (480 Temporarily Unavailible):
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[4]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG: add_to_tail_of_timer[0]: 0x405e3c90
Sep 13 10:14:33 SAM-IP ser[870]: SER: new transaction fwd'ed
Sep 13 10:14:33 SAM-IP ser[870]: DEBUG:destroy_avp_list: destroying list (nil)
Sep 13 10:14:33 SAM-IP ser[870]: receive_msg: cleaning up
In this case, immediately after it set the retransmission timeout, the timer process
starts the retrasmission of the original INVITE, without waiting the timeout value (1
second) and moreover without taking care of the fact that the transaction is deleted:
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:0,tl=0x405e3c24 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c14 next=0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405ea470 next=0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405ea358, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405ea470
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: timer routine:4,tl=0x405e3c80 next=(nil)
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : request resending
(t=0x405e3b68, INVITE si ... )
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: add_to_tail_of_timer[5]: 0x405e3c80
Sep 13 10:14:33 SAM-IP ser[879]: DEBUG: retransmission_handler : done
I suppose that the inconsistency is related to the setting of the timer after the
"480", probably in the handling of the final reply there is the cleaning of the
retransmission timer, but in this race condition the timer is set after the 480.
I'm not familiar with the internal code of the tm and timer modules, but what do you
think if I change the position of the instructions in the t_forward_non_ack function in
order to set the timer before sending out the UDP packet?
start_retr( &t->uac[i].request );
if (added_branches & (1<<i)) {
if (SEND_BUFFER( &t->uac[i].request)==-1) {
LOG(L_ERR, "ERROR: t_forward_nonack: sending request failed\n");
if (proxy) { proxy->errors++; proxy->ok=0; }
} else {
success_branch++;
}
I hope in this way, the handling of the final reply cleans correctly the timer.
Otherwise I would put some test before the start_retr function to understand if the
transaction is still alive.
Regards,
Daniele.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: giovedì 7 settembre 2006 9.24
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: R: [Serusers] Retransmission problem
Inline.
Zappasodi Daniele wrote:
Many thanks for the reply, it is very useful but it contains bad news because, if is it
possible, it is important for me to preserve the possibility to have the SIP proxy and SIP
gateway in the same board.
Some other clarification:
1. I have two ethernet interfaces, if I give different IP address to proxy and gateway,
can I leave them on the same hardware?
Yes, the trick is to get the listen and alias directives correct in your ser.cfg. You can
run multiple servers or UAs on the same server, you just have to make sure you don't
have alias=myip in ser.cfg. This will make SER believe messages for another server/UA is
to be routed locally.
2. If I correctly understand the transaction creation in SER: SER absorbs the
retransmission only if already exists a transaction for the original INVITE and SER
creates a new transaction for an INVITE only when is invoked the t_relay.
Yes, if not, SER will be transaction stateless and just happily forward any message.
Consequently, If a retransmitted INVITE arrives when the elaboration of the original
INVITE is still in progress, SER repeats all the elaboration also for the second INVITE.
I'm not sure what you mean by "elaboration", but if you mean that the
script will be executed for retransmitted INVITEs, then yes.
Do you confirm my description?
I have built a function that in heavy load traffic condition could be slow (it does an
external query, something similar to an exec) and it is important that I don't invoke
it twice for the same INVITE, so I try to use t_newtran to anticipate the transaction
creation before invoking this function.
However, as first step, I will remove the t_newtran, t_forward_nonack_uri and I try
again.
Normally, you should not have to worry about the transaction state, just process the
INVITE and use t_relay() and let SER handle the retransmissions etc. I cannot see that
your scenario would require more fine-grained control over the transaction state, but then
I don't know what you are trying to do...
g-)
Thanks again.
-----Messaggio originale-----
Da: Greger V. Teigre [mailto:greger@teigre.com]
Inviato: mercoledì 6 settembre 2006 9.19
A: Zappasodi Daniele
Cc: serusers(a)lists.iptel.org
Oggetto: Re: [Serusers] Retransmission problem
1. DON'T have UA2 and SER on the same server. You are very likely to get problems
because SER sees it's own IP address in a message destined for UA2
2. Don't use t_newtran and t_forward_nonack_uri unless you know exactly what you do
(and probably not then either)
3. When having problems like that, use a pretested Getting Started config fil
(http://iptel.org/ser/doc/gettingstarted). If you still have the problem, there is
something external (like UA2 on same box as SER). Fix it and then compare the logic of
your config file with the Getting Started reference config
g-)
Zappasodi Daniele wrote:
Hello,
I have a big problem with the retransmissions.
In my tests sometimes the retransmission handler doesn't seem to work properly and it
resends the INVITE after receiving a final response.
Moreover it doesn't respect the time-out (instead wait 1 second it resends the packet
after few decimal), but this is a minor item.
An example:
INVITE sip:31203
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
From 32201
UA1(32201) ---> SER ---> UA2(31203)
INVITE UA1 ---> SER ---> UA2
Trying UA1 <--- SER
183 UA1 <--- SER <--- UA2
480 UA1 <--- SER <--- UA2
ACK UA1 ---> SER ---> UA2
...
Other call.
After 0,5 msec SER sends again the first INVITE to UA2:
INVITE SER ---> UA2
183 SER <--- UA2
etc.
In the attached zipped file there are the syslog, the ser config file (only the relevant
parts) and the ethereal captures related to this example.
Some additional information:
SER version is 0.9.2, compiled for arm.
In my scenario SER and UA2 are on the same box.
In LAN_capture.cap file there is the message flow between UA1 and SER, in lo_capture.cap
between SER and UA2.
Can someone explain me this behaviour?
Maybe something wrong in my config file? Note that I use t_lookup_request, t_newtran,
t_forward_nonack_uri in order to recognize retransmitted INVITE, could it be here the
problem?
thanks
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message inerror.
**********************************************************************
5 Sep
5 Sep
9:06 a.m.
New subject: [Serusers] avp module help
Hi,
I am new to OpenSER/SER and was reviewing the avp module. Does anyone know
with regard to the function avp_check(name,op_value) what the ne, lt, le,
gt, ge, re parameters stand for? (for instance xor, i know is exclusive or)
.. I do not know what the 6 above stand for and I am trying to learn the
syntax for programming reasons, or where can I find more information. I
have been reading the openSER module handbook/cookbook but I suppose this is
too simple of a need to explain in the handbook, and my apologies for not
knowing but I still would like to know.
operator = 'eq' | 'ne' | 'lt' | 'le' | 'gt' |
'ge' | 're' | 'fm' | 'and' |
'or' | 'xor'
Thanks,
Tracy
_________________________________________________________________
Windows Live Spaces is here! Its easy to create your own personal Web site.
http://spaces.live.com/signup.aspx
Serusers
mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
9:21 a.m.
New subject: [Serusers] avp module help
eq : "equals"
ne : "not equal (to)"
lt : "less than"
le : "less than or equal to"
gt : "greater than"
ge : "greater than or equal to"
No idea what re and fm are.
N.
On Tue, 05 Sep 2006 13:06:35 +0000, Tracy Lofton wrote
Hi,
I am new to OpenSER/SER and was reviewing the avp module. Does
anyone know with regard to the function avp_check(name,op_value)
what the ne, lt, le, gt, ge, re parameters stand for? (for instance
xor, i know is exclusive or) .. I do not know what the 6 above
stand for and I am trying to learn the syntax for programming
reasons, or where can I find more information. I have been reading
the openSER module handbook/cookbook but I suppose this is too
simple of a need to explain in the handbook, and my apologies for
not knowing but I still would like to know.
operator = 'eq' | 'ne' | 'lt' | 'le' | 'gt' |
'ge' | 're' | 'fm' |
'and' | 'or' | 'xor'
Thanks,
Tracy
_________________________________________________________________
Windows Live Spaces is here! Its easy to create your own personal
Web site. http://spaces.live.com/signup.aspx
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Serusers
mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6 Sep
6 Sep
3:09 a.m.
New subject: [Serusers] avp module help
re : regular expression
fm: regular expression found in an avp
g-)
sip wrote:
eq : "equals"
ne : "not equal (to)"
lt : "less than"
le : "less than or equal to"
gt : "greater than"
ge : "greater than or equal to"
No idea what re and fm are.
N.
On Tue, 05 Sep 2006 13:06:35 +0000, Tracy Lofton wrote
Hi,
I am new to OpenSER/SER and was reviewing the avp module. Does
anyone know with regard to the function avp_check(name,op_value)
what the ne, lt, le, gt, ge, re parameters stand for? (for instance
xor, i know is exclusive or) .. I do not know what the 6 above
stand for and I am trying to learn the syntax for programming
reasons, or where can I find more information. I have been reading
the openSER module handbook/cookbook but I suppose this is too
simple of a need to explain in the handbook, and my apologies for
not knowing but I still would like to know.
operator = 'eq' | 'ne' | 'lt' | 'le' | 'gt' |
'ge' | 're' | 'fm' |
'and' | 'or' | 'xor'
Thanks,
Tracy
_________________________________________________________________
Windows Live Spaces is here! It's easy to create your own personal
Web site. http://spaces.live.com/signup.aspx
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Serusers
mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6570
days inactive
6588
days old
13 comments
5 participants
participants (5)
-
Greger V. Teigre -
Ricardo Carvalho -
sip -
Tracy Lofton -
Zappasodi Daniele