Thanks, Klaus. That made me actually read the 3262 :-)
For the sake of closure, I'll summarize: - 100 Trying is hop-by-hop and is NOT possible to do reliable
- RFC3262: "An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of that transaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannot generate reliable provisional responses to requests sent within the context of a dialog." As SER does not have specific support for provisional responses, 181 Call Is Being Forwarded and 181 Queued cannot be sent to the UAC reliably
- Any other reliable provisional messages will go between UAC and UAS, and SER will not interfere
g-)
Klaus Darilion wrote:
Greger V. Teigre wrote:
I think the idea is that a proxy can send a provisional response to the UAC and thus take responsibility for the transaction towards the (real) UAS, just like sending a 100 Trying... before forwarding. The UAS has not yet received the INVITE (or whatever message we are talking about) and thus to tag is not yet set.
This is the standard transaction stateful call setup - there is no reliability of provisional responses.
regards klaus
g-)
Klaus Darilion wrote:
Hi Kamal!
I reconsidered by previous answer and found that there is no Cseq Problem as CSeq may have gap.
But reading your snippet: I've never seen any client yet sending provisional responses without to-tag. Thus, even if the proxy could generate reliable responses it wouldn't be used often.
regards klaus
Kamal.Mann@t-systems.com wrote:
Hi Darilion Please check the following snippet from rfc-3262 "An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of that transaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannot generate reliable provisional responses to requests sent within the context of a dialog. Of course, unlike a UAS, when the proxy element receives a PRACK that does not match any outstanding reliable provisional response, the PRACK MUST be proxied."
Regards Kamal Mann
-----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Thursday, October 19, 2006 3:03 PM To: Greger V. Teigre Cc: Mann, Kamal; serusers@lists.iptel.org Subject: Re: [Serusers] rfc 3262 support
AFAIK PRACK is a client feature and is end to end. Thus, ser supports PRACK as any other generic SIP request.
Maybe you could fake PRACK requests or responses between a PRACK capable
client and the proxy, but this will cause end-to-end CSeq mismatch and would require a dialog stateful proxy to adapt the CSeqs.
regards klaus
Greger V. Teigre wrote:
AFAIK, this RFC is not implemented yet. As for a list, there is none right now, but it's on the to-do list :-) g-)
Kamal.Mann@t-systems.com wrote:
Hi All
Do SER supports 'rfc 3262 Reliability of Provisional Responses in SIP'? Is there any list of standards supported by SER available??
Regards
Kamal Mann
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers