Thank you Brett, Dale and Paul for your valuable comments.
On Wed, Aug 24, 2016 at 9:05 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > I agree with Brett on all points. If you are writing a test suite for sip, > then I think you should reject the invite. 481 seems like a reasonable > response, but may not be sufficient to indicate the problem. > > OTOH, if you are simply trying to build a system that maximally > interoperates with other stuff then you may find it worth your while to > accept this as creating a new dialog. If you are careful about how you > manage your dialog state you should not have trouble doing this. > > Thanks, > Paul > > > On 8/24/16 9:16 AM, Brett Tate wrote: >>> >>> There is a connected call with dialog id as (callid1, >>> from tag ftag1, to tag ttag1). When BYE is received at >>> UA1 it responds with 200 ok and starts running Timer J >>> timer(32 seconds). After 5 seconds a new INVITE is >>> received by UA1 having same callid as previous call(callid1) >>> and new from tag. >>> >>> UA1 is responding with 481 response? is it correct behaviour.? >>> please suggest if anything is there in RFC. >> >> >> In my opinion if the device doesn't want to support it, it can reject the >> request (although there might be a better failure response). However, >> there might be interoperability reasons to support it. >> >> In my opinion, you are experiencing a non-compliant reuse of Call-ID; >> however some vendors have interpreted RFC 3261 differently. It has been >> many years since I've seen the topic debated; thus I'm not sure if anyone >> or sipcore is currently defending such Call-ID reuse as compliant. >> >> RFC 3261 section 8.1.1.4: >> >> "In a new request created by a UAC outside of any dialog, the Call-ID >> header field MUST be selected by the UAC as a globally unique >> identifier over space and time unless overridden by method-specific >> behavior. All SIP UAs must have a means to guarantee that the Call- >> ID header fields they produce will not be inadvertently generated by >> any other UA. 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." >> >> Some vendors have intentionally violated (or interpreted differently) the >> globally unique mandate for correlation reasons. For instance, they use >> the same Call-ID with different From tag when originating a conference or >> recreating a persistent call. I'm not sure if any devices violate that >> mandate for mischievous reasons. >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
