Alice --- INVITE (SDP) --> Bob
Alice <-- 100 Trying --- Bob
Alice <-- 200 OK (SDP) --- Bob
What can be the reason of missing 18x response before 200 OK ?
Is this a normal scenario?
Thanks in advance.
Since a provisional response (1xx) is optional the answerer can reply directly by sending a final response (2xx). An example of such a case is where the answerer is an application and not a human. There is no need to have the target phone ringing when an automated process handles the incoming call.
More information can be found in RFC3261 and especially here
Related
I have confusion that, Im using 202 status code, when I receive a POST request from a client (A) and B is processing it , passing the output to another endpoint(C).
In this case I use 202 status code when B receives the request from A.( I have added the sample message flow.)
B is not sending any other response back to A. So is that right using 202 or it should be 200 ?
My understanding is, we use 200 for GET calls, and for POST we use 202 if processing is pending.
Here i have pending the processing and i forward that output to C. Not to A.
So here is my confusion to use 202 or 200 is right?
Edit
If it is a call back endpoint, (eg: in this picture B), would it be appropriate to have 200?
The main purpose of using 202 instead of 200 is for a server to communicate to a client: "From what I can tell, the request looks good. However, we haven't fully dealt with your request yet and we aren't 100% certain it's going to succeed".
So if someone does a request, the server immediately responds and then forwards the request elsewhere, a 202 makes sense to me. If the request fails at the C endpoint, A it will be too late for A to find out about this.
If you respond with 200, it tells a client that the request fully succeeded.
Can a GET request message ever return a HTTP status code of 201?
A conforming HTTP server should never do this. GET is a safe method, and is not supposed to have any side effects.
201 means a new resource was created on the server, which really is a side-effect.
So if a GET results in a 201, something is wrong. However, if you are building a client want to know in advance which success codes you might get, you should simply support every code between 200 and 299 (inclusive) and treat them all as success codes.
Yes. The API has control over what status code to send.
In practice, the status code is meant to communicate the status of the response - so it’s unlikely that a 201 (“Created”) should be returned from a GET request.
201 - created.
We can return code 201 for GET, but normally we use POST to send some data in server. So I don't think it is good to return 201 for GET
I have been trying to create a REST/Json Virtual service on CA LISA 7.5 (we can’t update), using request response pairs. The request response looks like the following:
Name-req
GET /cods_party_web/party/111700 HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
x-abc-outlet-id: 017879
x-abc-user-id: CTM
x-abc-consent-level: 2
x-abc-application-id: 00028
x-abc-outlet-id-type: OU_ID
x-abc-user-id-type: 1
x-IBM-Client-Id: XXX....
x-IBM-Client-Secret: XXX...
Name-rsp
HTTP/1.1 200 {"party":{"partyId":111700,"foreNames":["Julie","Pamela",""],"lastName":"Duncan","initials":["J"],"...lots of content......."type":"EMAIL"}],"associatedOU":null}
When I try to build the virtual service image, no matter what options I select, my VS image response is either in hex as shown below or it is blank.
I remember having this problem 1 year ago, and was able to get the reponse to look like below but I can’t remember how I did it.
Success response
Not found response.
Many thanks in advance
It's not returning hex - those are just column numbers for an empty binary response. I think the problem is your response document is not properly formed HTTP - there's no reason phrase in the status line, and you need two line feeds after the status line. Try this:
HTTP/1.1 200 OK
{"party":{"partyId":111700,"foreNames":["Julie","Pamela",""],"lastName":"Duncan","initials":["J"],"...lots of content......."type":"EMAIL"}],"associatedOU":null}
I understand that you can't upgrade, so this doesn't really help you, but LISA 9.5 doesn't have this issue -- the response looks like it's supposed to.
On the other hand, CA has released a free, simpler version of LISA that also successfully generates a VS from your example. Check it out here:
http://educationcontent.ca.com/A01/index.html
I'm newbie in SIP field. So, please forgive if there is old/easy questions.
Please take a basic call-flow as below to analysis.
phone A -- calls -- phone B -- (transfer to ) -- phone C
A, B, C are extension on same PBX.
Question 1. So, in INVITE message, the History-info will contain:
At B
`History-info : <sip: user A #domain.com>`
At C:
`History-info : <sip: user A #domain.com>`
`History-info : <sip: user B #domain.com>`
`History-info : <sip: user C #domain.com>`
Question 2. And, the PAI header will generate in INVITE message of C
and the format is :
P-Asserted-Identity: <sip:user A #domain;user=phone>.
Question 3. I just want to know when does 2 SIP headers: History-info and P-Asserted-Identity (PAI) occur in SIP message ? and which case ?
Question 4. The difference between 2 SIP headers above and the purpose of them. Are they generated on INVITE message or others ?
Please help me make these concerns clearly.
Q1: Not sure what the question is, but if all UAs (extensions) are sending the calls through the PBX, the PBX may add the History-info fields in any request not associated with an established dialog (INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH, SUBSCRIBE, ..)
Q2: The PAI field should be set with the identity of the calling party, which is still extension A for internal calls. In another scenario, like A is calling B and B is redirected to an outside line, the PAI might be overwritten by the PBX with B's outbound number before the call is sent through the external SIP trunk.
Q3: History-info (RFC4244) is an application specific header field, not always present and most commonly injected by your PBX for internal reasons (checking routing, detecting redirect loops, charging, etc). Being an optional field, its availability and purpose in extensions may vary.
PAI field (RFC3325) contains the identity of the caller.
Q4: Q3 explains the difference between them, PAI holds the identity while histinfo fields are holding the indexed tracking of SIP URIs through which the message passed and any additional info.
PAI can appear in INVITE/OPTIONS/SUBSCRIBE/NOTIFY, for histinfo see Q1.
I am sometimes getting 102 response from a web server. This response indicates that the server is processing the request but is not the final response for it (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#1xx_Informational). The request(>) response (<) sequence might look like this:
>GET some_url
<HTTP/1.1 102 Processing
<HTTP/1.1 102 Processing
<HTTP/1.1 102 Processing
<HTTP/1.1 200 OK
The server can be considered reliable in the sense that the final response is ultimately sent.
Using LWP::UserAgent (6.02) I can recognise that I've received a 102 using HTTP::Status::is_info() but what I then need to do is consume at least one and maybe more subsequent responses for the original request and I can't see a way to do that once I have the response.
I thought I might be able to do it with a handler (http://metacpan.org/pod/LWP::UserAgent#Handlers) which I use successfully elsewhere, but I can't find a way to force continuing to listen.
I've also looked for a way to turn on "102 awareness" within LWP and just have the library take care of listening for the final response which it then returns, but I can't see that either.
Tell me I'm missing something obvious, please.