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.
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.
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:
Vikram Ragukumar writes:
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
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:
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
On 4/9/10 9:11 PM, Klaus Darilion wrote:
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
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Klaus Darilion -
Vikram Ragukumar