> We're about to implement SIP 302 into our stack. > By looking at the RFC 3665 ( > https://tools.ietf.org/html/rfc3665#section-3.6), I see a > re-INVITE goes to proxy P3 (F4 in the flow) with the same CallID.
F4 is not a re-INVITE. More specifically, F4 is still a request which is outside of a dialog. The RFCs typically refer to a mid-dialog INVITE as a re-INVITE; however there is some ambiguity about if a re-SUBSCRIBE means only within dialog. > Due to some limitations from our side, we plan to do an INVITE > (vs a re-INVITE), by using a NEW Call-ID to P3. > So that will be 2 totally separated calls. First call will get > the 302 (which is a final response) and then we'll send a new > totally separated call to the Contact received in the 302 > response from call #1. > > Do you see any problem(s) by such an implementation? It shouldn't be a problem unless the devices involved have services relying upon following the RFC 3261 recommendation. I'm not sure if there is a HERFP (draft-mahy-sipping-herfp-fix) type reason to follow the recommendation for 3xx responses. <snip> > Any broken rules that will need us to change everything > when implementing a recent RFC? RFC 3261 section 8.1.3.4 indicates the following: "It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example." RFC 2119 defines RECOMMENDED. "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
