I am analyzing some voice data. I have a data and each row represent a call scenario. Now each row has columns related to call.
The column I am interested in are SIP release cause, Jitter, MOS.
Here are some Release Causes:
'SIP: 487 Request Canceled',
'SIP: 200 OK',
'SIP: 480 Temporarily Unavailable',
'SIP: 504 Gateway Timeout',
'SIP: 408 Request Timeout',
'SIP: 484 Address Incomplete',
'SIP: 403 Forbidden',
'SIP: 404 Not Found',
'SIP: 486 Busy Here',
'SIP: 500 Server Internal Error',
'SIP: 503 Service Unavailable',
'SIP: 500 Service Unavailable',
'SIP: 580 Precondition Failure',
'SIP: 481 Call Leg/Transaction Does Not Exist',
'SIP: 603 Decline',
'SIP: 488 Not Acceptable Here'
Now I can see in my data for SIP OK , there are some jitter and MOS values which is correct since some RTP packets would be exchanged.
But for other release cause like SIP 487 Cancel, I could see some of my rows have jitter and MOS values which is strange since RTP packets are not expected here.
Similarly with other 4XX and 5XX release causes.
Now I want to understand the cases (Release Causes) where there may be some RTP packet exchange which may lead to jitter.
Am I altogether getting the concept of jitter wrong. Can it occur without any RTP exchanges. Or are there any RTP flow for release cause other than SIP 200 OK.
200 OK is not the only SIP response to result in RTP packets being sent.
Early Media (RFC 3960) allows media (RTP) to be sent before the session is established with the 200 OK response.
Early media allows callers to hear particular ringback tones when a call is in the ringing state, and RVAs playing announcements like "Unable to reach that destination", without sending a 200 OK and flagging the call as answered.
In short, if you're looking at RTP packets or RTCP packets to calculate Jitter, then there's RTP packets being sent, the the cause is probably Early Media.
Related
let's say I have connection using SIPS (SIP secure) using g729 codec.
Does anyone know how many bandwidth it takes?
I know call using g729 codec 10ms is about 11Kb bandwidth consumption.
According to me:
SIP or SIPS use almost the same bandwidth. It will makes no difference.
The SIP bandwidth compared to RTP is insignificant.
Imagine you have a one minute call. The total exchange would be, for example:
For SIP:
1000 bytes for INVITE
1000 bytes for 200 OK for INVITE
500 bytes for ACK
500 bytes for BYE
500 bytes for 200 Ok for BYE
total = 3500 bytes
For RTP and g729, with 10ms:
Each of my RTP packet is 22 bytes. (not including UDP headers)
G729 payload: 10 bytes
RTP header: 12 bytes
total = 100 * 22 = 2200 bytes/second (which is 17,6kb/s)
total = 100 * 22 * 60 = 132000 bytes for a one minute call
For only one minute, the ratio is already
132000/(132000+3500) = 97,4%
3500/(132000+3500) = 2,6%
If you have longuer call duration, the sip related bandiwdth would drop quickly under 1%.
If you have frequent SIP messages during the calls (like INFO), may be you can take them into account, but this is usually not the case.
NOTE: I used an 8kbit/s G729 stream encoder instead of 11kbit/s. Just replace with your own values.
EDIT:
With usual SRTP encryption method, if you use SRTP, the encrypted payload will remain the same size. However, an additionnal authentication tag is usually used. With AES_CM_128_HMAC_SHA1_80 being used, 10 bytes will be added to each packet.
Consider this sample SIP dialog
A-->--INVITE-->--B CSeq 101
A--<--TRYING--<--B CSeq 101
A--<--200 OK--<--B CSeq 101
A-->-- ACK -->--B CSeq 101
A-->-- INFO -->--B CSeq 2
A--<-- 500 --<--B CSeq 2
...
While working on a SIP handling code, we put a validation for CSeq of a SIP INFO message for a dialog to be greater than the one sent for the INVITE.
However, as shown in the above SIP flow, one of the remote SIP gateways is sending it to be lower, ie 2 instead of the expected 102 or higher.
The RFC https://www.ietf.org/rfc/rfc3261.txt states that
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one) in
each direction
So, is the observed behavior a violation of the RFC?
Yes, it is. You paraphrased the correct text.
The RFC on SIP INFO messages states CSeq header values follow the mechanism in RFC3261:
The Info Package mechanism does not define a delivery order
mechanism. Info Packages can rely on the CSeq header field [RFC3261]
to detect if an INFO request is received out of order.
However, keep in mind you can't rely on the received CSeq number being only one higher than the previously received one (https://www.rfc-editor.org/rfc/rfc3261#section-12.2.2):
It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one. This is not an error condition, and a UAS SHOULD be
prepared to receive and process requests with CSeq values more than
one higher than the previous received request. The UAS MUST then set
the remote sequence number to the value of the sequence number in the
CSeq header field value in the request.
If a proxy challenges a request generated by the UAC, the UAC has
to resubmit the request with credentials. The resubmitted request
will have a new CSeq number. The UAS will never see the first
request, and thus, it will notice a gap in the CSeq number space.
Such a gap does not represent any error condition.
This question is regarding the ACK request in SIP (Session Initiation Protocol). Quoting RFC-3261 - 18.1.1 Sending Requests
If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP.
This looks OK for the INVITE and other non-invite request except ACK. Below are the points why i think the above statement may not be applicable for ACK.
ACK is just a request and not transaction. So the SIP transaction State Machine must not be applicable for ACK request. Since State Machine is the only place which talks about the retransmission, So the 18.1.1 is not applicable for ACK request. Quoting 3261 - "17.1 Client Transaction" - in favour for above argument.
There are two types of client transaction state machines, depending
on the method of the request passed by the TU. One handles client
transactions for INVITE requests. This type of machine is referred
to as an INVITE client transaction. Another type handles client
transactions for all requests except INVITE and ACK. This is
referred to as a non-INVITE client transaction. There is no client
transaction for ACK. If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.
ACK can be re-transmissted only if next B-party retransmits the final response.
Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?
Quoting 3261 - "17.1 Client Transaction" -
If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.
Q:- What does TU wishes mean? Does it mean that TU can send any time it wish OR it means whenever final response come then only TU sends?
Regards,
Sudhansu
1) Let's go back to basic stuff
"If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP."
My comments :-
"SHOULD retry the request" --> It says SHOULD retry not MUST retry request.
So this is not mandatory at all to send ACK request.
2)
Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?
Quoting 3261 - "17.1 Client Transaction" -
If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission.
comments :- This clearly states if TU ( Transaction user ) wishes to {not must} pass ACK request to transport layer for tranmission.
So as per statement, it's application wish that don't do anything once you pass that to ACK to transport layer. OR if on another side if application wants if there any TCP error (ICMP) then it can retransmit same ACK request over UDP.
See RFC will never exclude ACK from this, it is application responsibility & how it is implemented.
Also please can also ask question at Sip-implementors mailing list. You will get more like minded people.
First some clarifications. From [RFC3261 Section 6][1]:
SIP Transaction: A SIP transaction occurs between a client and a
server and comprises all messages from the first request sent
from the client to the server up to a final (non-1xx) response
sent from the server to the client. If the request is INVITE
and the final response is a non-2xx, the transaction also
includes an ACK to the response. The ACK for a 2xx response to
an INVITE request is a separate transaction
So an ACK to a non-2xx is part of the same transaction as the INVITE, any 1xx responses and the final response. In particular it has the same CSeq and the same branch tag. ACKs to non-2xx responses are hop-by-hop.
An ACK to a 2xx is a new transaction (although this is a special ACK transaction, and there are no responses). It has the same CSeq, but a different branch tag. ACKs to 2xx responses go all the way from the client to the server.
On your specific point, section 17 is about the transaction Layer. Here ACKs are only ever re-transmitted in response to a re-transmitted final response. When the Transaction Layer decides it needs to send an ACK, it sends it to the Transport Layer, and it is the Transport Layers job to deliver it.
Section 18 is about the Transport Layer. An ICMP error or a TCP reset are Transport Layer errors, they are not covered by the SIP transaction model. If the Transport Layer needs to promote a message from UDP to TCP, or to fall-back from TCP to UDP, that is separate from the Transaction Layers model. In fact, if the TCP socket cannot be established, the ACK has not been transmitted yet. In this case the Transport Layer isn't retransmitting it, it is attempting to transmit it for the first time, by a different protocol.
In practise, this case is going to be rare. For the size of the ACK to be a problem for UDP, it has to be larger then both the INVITE and the final response - these have already succeeded via UDP. In the usual case the INVITE and final response contain an SDP body; in every success case the 2xx contains a body. The only case where the ACK is going to be larger is if there was no SDP in the INVITE and the ACK adds to the headers or body.
If you hit this case - TCP not supported and ACKs too big for UDP, you may be heading for failure anyway.
[1]: https://www.rfc-editor.org/rfc/rfc3261#section-6
I've transfer a data via SCP and get some messages in picture above (in black color).What relation about these messages (TCP ACKed...,TCP Zerowindow and TCP Prev...).
Thank you very much and sorry about language from network newbie.
ACK on a TCP packet gives the sequence number the other machine shall use next:
SYN (seq=1) -> received
recived <- SYN, ACK (seq=101, ack=2)
"hi" (seq=2, ack=102) -> received 2 bytes
received <- ACK (seq=102, ack=4)
recived 2 bytes <- "ho" (seq=103, ack=4)
i.e. ACK is sent on every packet to the other machine saying: "The next sequence number i expect from you is this number".
ACKs are never increased if part of data was never seen. Has "hi" not been received in the above example (by network congestion for example) the right side will reject all packets until a packet with seq=2 is received. TCP deals with that internally by repeating the seq=2 packet.
Your wireshark log suggests that some packet was not seen by it. The packet might have goen through the network normally (and probably it did, otherwise it would have been repeated) but wireshark did not capture it. That is a completely possible scenario, in busy networks wireshark often fails to capture every packet.
In Spray, for chunked response we can send chunked message with an ack like
peer ! MessageChunk(buffer).withAck(MyAck(k))
and we can get ack message back which confirms the message delivery to the OS network layer. Do we have something like timeouts for these acks ?
I don't think there is an Ack Timeout feature built in to spray.
It should be possible, for the Chunking Actor to keep track of sent messages & timeouts if your Ack contains details about the sent chunk. See ChunkingActor[T] used to marshall Stream[T] in the spray source code to get an idea of how this could be done. You may choose to have this actor keep track of the last chunk sent along with the time sent. If an Ack does not come back for that chunk during the set timeout, you can handle the case where chunk delivery has "timed out".