2009/7/29 Scott Lawrence <scott.lawre...@nortel.com>: > RFC 3261 section 8.1.1.4 Call-ID: > > ... Note that when requests are retried after certain > failure responses that solicit an amendment to a request (for > example, a challenge for authentication), these retried requests are > not considered new requests, and therefore do not need new Call-ID > header fields; see Section 8.1.3.5. > > and then section 8.1.3.5 Processing 4xx Responses: > > Certain 4xx response codes require specific UA processing, > independent of the method. > > If a 401 (Unauthorized) or 407 (Proxy Authentication Required) > response is received, the UAC SHOULD follow the authorization > procedures of Section 22.2 and Section 22.3 to retry the request with > credentials. > > [...] > > In all of the above cases, the request is retried by creating a new > request with the appropriate modifications. This new request > constitutes a new transaction and SHOULD have the same value of the > Call-ID, To, and From of the previous request, but the CSeq should > contain a new sequence number that is one higher than the previous. > > Note that RFC 2119 defines SHOULD: > > 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.
Wow! what could I reply now...? Ok, if it would be a "MUST" you'd convince me XD (joking) However, it'd also work even if the client uses a different call-id/from-tag in the second INVITE (with credentials). For example, a proxy doesn't store the "failed dialog status" so when receives an INVITE with credentials it doesn't check call-id/from-tag values against a previous attemp. Regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
