The 200 OK of the PRACK is received later at the UAC than the 200 OK of the INVITE provided that the UAS had sent them in proper order..what should be the behavior of the UAC? Will it silently drop the packet? Or will it establish the dialog ?
I see nothing in standard that somehow bounds 200 OK for INVITE and 200 OK for PRACK on the client side. UAC should handle 2xx response to INVITE according to
RFC 3261 - 13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due to a forking proxy. Each response is distinguished by
the tag parameter in the To header field, and each represents a
distinct dialog, with a distinct dialog identifier.
If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog MUST be transitioned to
the "confirmed" state, and the route set for the dialog MUST be
recomputed based on the 2xx response using the procedures of Section
12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2.
And it has to handle response to PRACK based on RFC 3262
Note that the PRACK is like any other non-INVITE request within a
dialog.
There is requirement for UAS
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response until
those provisional responses are acknowledged.
So it would seem that UAC receiving 2xx response could decide that UAS has received the PRACK and stop its retransmissing - But there is nothing like that stated in the RFC. So even after receiving 2xx response to the INVITE UAC should continue retransmitting PRACK till it is acknowledged.
Related
I have a question about SIP, when read RFC [3311] UPDATE request, it doesn't mention that it's not invalid behavior in SIP. Here is the call flow:
UAC sends INVITE request
UAS sends 1xx INVITE to UAC
UAC sends UPDATE request
UAS send 2xx INV
UAS send 2xx UPDATE
I supposes some reasons that made the 200OK for INVITE come first then 2xx response for UPDATE request coming after. Is this case a pass case in SIP call follow ?
Thank you guys.
Yes, that's perfectly OK.
This can happen when the UPDATE request and the 2xx INVITE response are sent 'simultaneously' and thus cross each other.
After the UAS has sent the 2xx INVITE response it will receive the UPDATE request and immediately send the 2xx UPDATE response. This means the session that was established due to the INVITE request/response will have a short lifespan since its session parameters will be updated according to the UPDATE session parameters.
What are all the possible scenarios for an originating system to receive a 487 (Request Terminated) message from the destination end in response to an Invite message, before receiving 18X messages from the destination, and without any CANCEL message sent by the originator after sending the INVITE message?
The 487 Request terminated is created only as reaction to the CANCEL request. Nevertheless the CANCEL may be generated by a stateful proxy. See the RFC-3261 chapter 16.10. A stateful proxy may generate the CANCEL due to timer expiration for example.
The CANCEL request must not be sent before a provisional response is received. But the provisional response do not need to be a 18x response. UAC or proxy may send CANCEL even after 100 Trying is received. And moreover it is sufficient that the proxy receives a provisional response.
So there is the answer:
There are almost infinite number of all possible scenarios because there are plenty of SIP proxy implementations and their configurations and they may have a lot of reasons to cancel a transaction.
Invite carries offer from the network.
Can we send Update with sdp before the PRACK for first 18x is pending from the network, 18x sent was reliable provisional response?
RFC 3261 says
"After the first reliable provisional response for a request has been
acknowledged, the UAS MAY send additional reliable provisional
responses. The UAS MUST NOT send a second reliable provisional
response until the first is acknowledged. After the first, it is
RECOMMENDED that the UAS not send an additional reliable provisional
response until the previous is acknowledged. The first reliable
provisional response receives special treatment because it conveys
the initial sequence number. If additional reliable provisional
responses were sent before the first was acknowledged, the UAS could
not be certain these were received in order."
PRACK and UPDATE requests are both extensions to the core SIP RFC so there is no guarantee that they will be widely supported. I'd expect support for the UPDATE request in particular to be pretty limited in among various SIP implementations.
Looking at the UPDATE request RFC there is no requirement that PRACK requests be supported or that the UAS must wait for a PRACK before sending an UPDATE request. So the answer to your question is no the UAS does not have to wait for a PRACK before sending any UPDATE requests.
There are rules in the UPDATE RFC that state how UPDATE requests are handled if there are outstanding offers that have been sent in a PRACK request but that's a different thing,
As per RFC 6337 section 4.2, UAC should not send update if PRACK is still not received. Even though it is regarding reINVITE, I think it is relevant in your case also
Initially I was looking for an answer to why ACKs to 2xx responses form a separate SIP Transaction, while ACKs to non 2xx responses don't. Google gave me this:
"When the UAC receives 200 OK, the client transaction is destroyed at TL.
This is done because, the TL is unaware of the above core. The above
core can be a Proxy or an UAC core.
In case of proxy, the 200 OK is forwarded whereas in case of UAC, an
ACK is generated. Now this ACK has to
create a new transaction (transaction created by INVITE had been
destroyed)at TL for its transmission, hence the ACK for 200 OK is
outside the INVITE transaction.
For other non-2xx final responses, the client transaction at TL is not
destroyed and the ACK is generated by TL.
Hence in this case, the ACK is within the transaction."
http://sipforum.org/pipermail/discussion/2011-June/008499.html
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies? (so proxies will never know if the INVITE transaction is actually completed).
Another possibly related issue I am having is that I don't understand why retransmission of 200 OK is done end-by-end. Is there a reason why retransmission is not done in hop-by-hop manner?
The philosophical answer as to why SIP uses different ACK mechanisms is to discreetly torture anyone foolish enough to dig into the bowels of the SIP standard.
Why is 200 OK retransmission handled by UAS?
The answer is detailed in the SIP RFC Chapter 17 Transactions (which is also referenced in the sipforum link your provided).
The reason for this separation is rooted in the importance of
delivering all 200 (OK) responses to an INVITE to the UAC. To deliver
them all to the UAC, the UAS alone takes responsibility for
retransmitting them (see Section 13.3.1.4), and the UAC alone takes
responsibility for acknowledging them with ACK (see Section
13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.
Putting it another way the SIP designers were worried about the reliability of 2xx responses being delivered over UDP so they decided sending an ACK request from the client (UAC) to the server (UAS) was a good way to implement retransmissions.
I've never really understood why SIP couldn't just use the same mechanism for 2xx and non-2xx ACK's. It would make the job of implementors easier.
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies?
If the INVITE request traversed a SIP proxy or proxies then it's likely that the ACK request will traverse the same proxies (a 2xx response can change the proxies used in subsequent requests within the same SIP dialog so in theory the ACK could traverse different proxies). So no the ACK request handling at the client (UAC) is not designed to handle requests travelling different SIP routes.
Another possibly related issue I am having is that I don't understand
why retransmission of 200 OK is done end-by-end. Is there a reason why
retransmission is not done in hop-by-hop manner?
Because the SIP standard mandates that the responsibility for INVITE response retransmissions is handled by the UAS. A stateless SIP proxy does not have UAS capabilities, it simply passes any requests or responses it receives through to the next SIP agent.
However just to confuse things, a stateful SIP Proxy or a B2BUA may very well implement UAS functionality and in those cases the retransmission will occur on a hop-by-hop basis although in that case each INVITE transaction is between the UAC and the UAS in the Proxy or B2BUA rather than a UAS in the destination SIP client.
Tried to explain the same in the following link
https://abhishekchattopadhyay.wordpress.com/2010/09/21/why-ack-is-a-separate-transaction-for-invite-with-a-successful-200-ok%C2%A0response%C2%A0/
As such the question "why ack is a separate transaction in case of a 200 OK" is not a question at all. This is already explained in 3261. 200 OK (for that matter any final response) is supposed to end the transaction. And so new request would be a new transaction. no surprises!!
the real and uncomfortable question is why is ACK part of the invite transaction if the response is anything but a 200 OK. Read the above link the reason is put down there.
Thanks.
Why is 200 OK retransmission handled by UAS?
The answer in clear for me in RFC 3261 page 128:
"The handling of this response depends on whether the TU is a proxy
core or a UAC core. A UAC core will handle generation of the ACK for
this response, while a proxy core will always forward the 200 (OK)
upstream. The differing treatment of 200 (OK) between proxy and UAC
is the reason that handling of it does not take place in the
transaction layer."
I also think this question for a while and it's clear for me when I think about proxy in the communication path. As we know, non-2xx response take place in the transaction layer. The transaction layer on proxy will response a ACK for the non-2xx response. Also the transaction layer will resend ACK when receive non-2xx again.
Let's suppose, if 200 OK take place in the transaction layer. The proxy transaction layer will response a ACK. The session will be created on UAS. This is no problem if 200 OK can reach to UAC finally. But, that's not the result we wanted as 200 OK may not reach UAC for some other reason.
Please tell me when a SIP call return 487 Request Terminated?
Is it a termination issue?
The 487 Response indicates that the previous request was terminated by user/application action. The most common occurrence is when the CANCEL happens as explained above. But it is also not limited to CANCEL. There are other cases where such responses can be relevant. So it depends on where you are seeing this behavior and whether its a user or application action that caused it.
15.1.2 UAS Behavior==> BYE Handling in RFC 3261
The UAS MUST still respond to any pending requests received for that
dialog. It is RECOMMENDED that a 487 (Request Terminated) response
be generated to those pending requests.
It's the response code a SIP User Agent Server (UAS) will send to the client after the client sends a CANCEL request for the original unanswered INVITE request (yet to receive a final response).
Here is a nice CANCEL SIP Call Flow illustration.