7 Apr
2010
7 Apr
'10
2:15 a.m.
Hello,
Scenario 1
----------
--------- -------- -------- -------- --------
|Cellphone|--|Wireless|--|Internet|--|Kamailio|--|Asterisk|
| | |Router | | | |rtpproxy| | |
--------- -------- -------- -------- --------
|<-Lowlatency->|
Scenario 2
----------
--------- -------- -------- -------- --------
|Cellphone|--|Wireless|---|Internet|--|Kamailio|--|Asterisk|
| | |Router | | | |rtpproxy| | |
--------- -------- -------- -------- --------
|<-Highlatency->|
Both scenario 1 and scenario 2 are similar in setup, excepting that in
scenario 2 there is a greater latency involved in SIP and RTP
transmission between the wireless router and Kamailio+rtpproxy server.
In scenario 1 calls from the cellphone using a SIP softphone app go
through 100% of the time with both endpoints of the call being audible.
However in scenario 2, calls from the cellphone go through with both
endpoints of the call being audible only sometimes, and during all other
attempts, call goes through with no voice from the cellphone.
In scenario 2 the SIP softphone can always register, the SDP connection
address is always rewritten to use rtpproxy so it does not appear to be
a NAT issue, rtpproxy's logs show a session being set up and torn down,
with RTP stats for caller being 0.
In both scenarios, the equipment and their configuration are identical.
(Both cellphone's are Nokia e51, router's are Netgear wgr614) What might
be probable causes for the behavior seen in scenario 2 ? Could there be
a timing/latency related issue ?
Any pointers on how to approach this problem will be appreciated.
Thanks and Regards,
Vikram.
7 Apr
7 Apr
2:23 a.m.
Latency is not in itself an impediment to a successful VoIP
conversation; latency is just uncustomary for humans, and causes them
to talk over each other not unlike satellite or microwave long-distance
telephone conversations between hemispheres.
The problem that is often present in connection with the underlying
causes of high latency but is a different phenomenon than latency is
jitter. Jitter is the presence of nonlinear temporal deltas between the
arrival of RTP packets. RTP arrival at non-constant intervals causes
audio distortion, "drop-outs," static, repetition, and stream
synchronisation problems.
The bottom line: if there is high but very constant latency, you can
still have a manageable conversation. However, the same things that
cause high latency -- for example, link congestion -- often cause
jitter. The degree of packet queue saturation and/or bandwidth
exhaustion often varies across time and creates stochastic,
indeterminate effects that jitter buffers cannot be designed around, and
certainly not perfectly at any rate.
I would bet that jitter is the cause of your problem, simply because it
often goes hand-in-hand with latency.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
2:26 a.m.
P.S.
Outside of localised, low-activity LAN segments at close proximity,
running VoIP over 802.11b/g/n-style wireless is generally considered a
bad idea among serious network engineers.
It's a topic of fierce debate, though, since there are some narrowly
conceived business models out there that hinge on VoIP framed over small
802.11g wireless sectors and point-to-point 802.11 backhauls and stuff
like that. On the other hand, VoIP over WiMax networks like CLEAR in
the US has generally received positive appraisals.
On 04/06/2010 08:23 PM, Alex Balashov wrote:
Latency is not in itself an impediment to a successful
VoIP
conversation; latency is just uncustomary for humans, and causes them
to talk over each other not unlike satellite or microwave long-distance
telephone conversations between hemispheres.
The problem that is often present in connection with the underlying
causes of high latency but is a different phenomenon than latency is
jitter. Jitter is the presence of nonlinear temporal deltas between the
arrival of RTP packets. RTP arrival at non-constant intervals causes
audio distortion, "drop-outs," static, repetition, and stream
synchronisation problems.
The bottom line: if there is high but very constant latency, you can
still have a manageable conversation. However, the same things that
cause high latency -- for example, link congestion -- often cause
jitter. The degree of packet queue saturation and/or bandwidth
exhaustion often varies across time and creates stochastic,
indeterminate effects that jitter buffers cannot be designed around, and
certainly not perfectly at any rate.
I would bet that jitter is the cause of your problem, simply because it
often goes hand-in-hand with latency.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
6:40 a.m.
New subject: [Kamailio-Users] Possible timing/latency related problem ?
Vikram Ragukumar writes:
In scenario 1 calls from the cellphone using a SIP
softphone app go
through 100% of the time with both endpoints of the call being audible.
However in scenario 2, calls from the cellphone go through with both
endpoints of the call being audible only sometimes, and during all other
attempts, call goes through with no voice from the cellphone.
i have noticed the same thing with some nokia phones. if nokia receives
200 ok, it should start sending audio, but looks like sometimes it
doesn't, since your rtpproxy is not receiving any.
have you checked if in those cases, nokia has sent ACK to kamailio or is
it re-sending the invite?
-- juha
9 Apr
9 Apr
7:44 p.m.
Hello,
Alex, Juha thank you for your response. We have been doing more
debugging here and have some more information regarding the problem
Cell Phone Kamailio VoipSwitch
| | |
|INVITE | |
|------------->| |
|100 Trying | |
|<-------------| |
| |INVITE |
| |------------->|
| |100 trying |
| |<-------------|
| | |
|INVITE | |
|------------->| |
|100 Trying | |
|<-------------| |
| |183SessionProg|
| |<-------------|
| |180 Ringing |
| |<-------------|
|180 Ringing | |
|<-------------| |<-- 180 Ringing relayed before
|183SessionProg| | 183 Session Progress.
|<-------------| | Proxy not rewriting c=
| | 200 OK | field in SDP before
| 200 OK |<-------------| relaying to Cell phone
|<-------------| |
| ACK | |
|------------->| |
| | ACK |
| |------------->|
| | BYE |
| |<-------------|
| BYE | |
|<-------------| |
1) We setup logs for SIP message exchange at the proxy. The logs
indicate that on "some occasions" 180 Ringing is relayed before 183
Session Progress to the cellphone although these messages are received
in the reverse order from the Sip server.
2) Connection parameter not rewritten in SDP of 180 Ringing. The c=
connection parameter in the SDP of the 180 Ringing message that is
relayed to the cellphone from the proxy has the ip address of the Sip
server instead of the ip address of the proxy.
3) All other messages (183 Session Progress, 200 OK) that contain an SDP
are rewritten by the proxy prior to relaying to the Cell phone.
Why is the SDP connection parameter not being rewritten for the 180
Ringing message alone ?
How can i ensure the SIP messages are relayed in the order they are
received ?
Thanks and Regards,
Vikram.
Vikram Ragukumar writes:
In scenario 1 calls from the cellphone using a
SIP softphone app go
through 100% of the time with both endpoints of the call being audible.
However in scenario 2, calls from the cellphone go through with both
endpoints of the call being audible only sometimes, and during all other
attempts, call goes through with no voice from the cellphone.
i have noticed the same thing with some nokia phones. if nokia receives
200 ok, it should start sending audio, but looks like sometimes it
doesn't, since your rtpproxy is not receiving any.
have you checked if in those cases, nokia has sent ACK to kamailio or is
it re-sending the invite?
-- juha
8:29 p.m.
Vikram Ragukumar writes:
Why is the SDP connection parameter not being
rewritten for the 180
Ringing message alone ?
are you sure that you are calling a function, such as use_media_proxy()
or corresponding rtpproxy function, on the ringing reply? does both
ringing and session progress contain a sdp body?
How can i ensure the SIP messages are relayed in the
order they are
received ?
someone who is familiar with tm/core needs to reply to this one. there
may not be any guarantee, because the replies are processed by different
processes.
-- juha
8:42 p.m.
Juha,
Thank you for your response.
Vikram Ragukumar writes:
We were not forcing rtpproxy on 180 Ringing. We have fixed that in the
configuration file and are testing now.
Thanks and Regards,
Vikram.
Why is the SDP connection parameter not being
rewritten for the 180
Ringing message alone ?
are you sure that you are calling a function, such as use_media_proxy()
or corresponding rtpproxy function, on the ringing reply? does both
ringing and session progress contain a sdp body? 
9:11 p.m.
Am 09.04.2010 20:29, schrieb Juha Heinanen:
Vikram Ragukumar writes:
I think the only solution would be to use single processes: children=1,
tcp_children=1.
regards
klaus
Why is the SDP connection parameter not being
rewritten for the 180
Ringing message alone ?
are you sure that you are calling a function, such as use_media_proxy()
or corresponding rtpproxy function, on the ringing reply? does both
ringing and session progress contain a sdp body?
How can i ensure the SIP messages are relayed in
the order they are
received ?
someone who is familiar with tm/core needs to reply to this one. there
may not be any guarantee, because the replies are processed by different
processes. 
10 Apr
10 Apr
1:26 p.m.
New subject: [Kamailio-Users] Possible timing/latency related problem ?
On 4/9/10 9:11 PM, Klaus Darilion wrote:
Am 09.04.2010 20:29, schrieb Juha Heinanen:
This is right. However, this is not only related to sip server itself,
the messages can arrive in a different order when using UDP because of
network. Handling it in server is not a complete solution. The phones
should be able to deal with such cases.
Cheers,
Daniel
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
Vikram Ragukumar writes:
I think the only solution would be to use single processes:
children=1, tcp_children=1.
Why is the SDP connection parameter not being
rewritten for the 180
Ringing message alone ?
are you sure that you are calling a function, such as use_media_proxy()
or corresponding rtpproxy function, on the ringing reply? does both
ringing and session progress contain a sdp body?
How can i ensure the SIP messages are relayed in
the order they are
received ?
someone who is familiar with tm/core needs to reply to this one. there
may not be any guarantee, because the replies are processed by different
processes.
17 Apr
17 Apr
5:23 p.m.
New subject: [Kamailio-Users] Possible timing/latency related problem ?
Vikram Ragukumar writes:
Why is the SDP connection parameter not being
rewritten for the 180
Ringing message alone ?
How can i ensure the SIP messages are relayed in the order they are
received ?
vikram,
what was the conclusion regarding this? did the problem go away when
you called nat traversal functions both on 180 ringing and 183 session
progress?
-- juha
19 Apr
19 Apr
6:15 p.m.
New subject: [Kamailio-Users] Possible timing/latency related problem ?
Juha,
what was the conclusion regarding this? did the
problem go away when
you called nat traversal functions both on 180 ringing and 183 session
progress?
Yes. The problem did go away once we started forcing rtpproxy on 180
Ringing also.
Thanks and Regards,
Vikram.
5132
days inactive
5144
days old
10 comments
5 participants
participants (5)
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Klaus Darilion -
Vikram Ragukumar