See inline.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Iñaki Baz
Castillo
Sent: Thursday, August 16, 2012 7:05 AM
To: [email protected]
Subject: [Sip-implementors] Should a proxy relay a second 200 for a SUBSCRIBE?
Hi, if a UAC sends a SUBSCRIBE and the proxy does parallel forking to two
servers, it could occur that both servers reply a 200.
[Neel]
Reading Section 16.7, RFC 3261, it is clear for INVITE. Any 2xx for INVITE
should be forwarded upstream. For other non-dialog forming requests, my
understanding is, the proxy should absorb the any other forked 200 OK.
RFC 3261 Section 16.7: page 109
After a final response has been sent on the server transaction,
the following responses MUST be forwarded immediately:
- Any 2xx response to an INVITE request
A stateful proxy MUST NOT immediately forward any other
responses. In particular, a stateful proxy MUST NOT forward
any 100 (Trying) response. Those responses that are candidates
for forwarding later as the "best" response have been gathered
as described in step "Add Response to Context".
Any response chosen for immediate forwarding MUST be processed
as described in steps "Aggregate Authorization Header Field
Values" through "Record-Route".
This step, combined with the next, ensures that a stateful
proxy will forward exactly one final response to a non-INVITE
request, and either exactly one non-2xx response or one or more
2xx responses to an INVITE request.
Should the proxy relay the second 200 to the UAC? or should it absorb it?
Anyhow I do know that the UAC must be ready to receive an in-dialog NOTIFY with
an unknown Totag (the NOTIFY generated by the second
server) so the UAC should generate a second subscription dialog then and should
manage it (as RFC 6665 mandates).
Thanks a lot.
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
