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.
Related
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.
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
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.
i am receiving multiple 2** responses for a call. The problem is that once the call is connected and the server receives the "ACK" packet and the call starts successsfully, server again sends the "OK" response packet back to the callee and recieves the "ACK" packet again for it. This happens multiple times before the call gets terminated automatically. Can somebody explain to me why this is happening that my server is sending the "OK" response even after the call is connected successfully and what can be the possible solution for the problem? Thanks in advance for any help.
A SIP UAS will retransmit the 2xx response multiple times until it receives the ACK request from the UAC. See the SIP RFC chapter "13.3 UAS Processing" for the gory details.
Most often this sort of problem happens when the ACK sent by the UAC is invalid and thus prevents the UAS from matching it to the INVITE transaction. ACK requests have special rules about their construction see 13.2.2.4 2xx Responses. To make things even more difficult the construction of the ACK request differs for 2xx and non-2xx final responses.