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
