6/9/23, 9:44 AM
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`Paul Kyzivat <pkyzivat@cisco.com> Tue, 09 June 2009 13:08 UTCShow header
`
`Adam,
`
`I will agree with you on this one.
`
`Yet I want to emphasize the need for conservatism on the originating
`side. I have repeatedly seen cases where somebody says on of:
`- I can reuse the same callid because the from and to tags will
` make the dialog id unique
`- I can reuse the same from tag because the callid and to tag will
` make the dialog id unique
`- I can reuse the same to tag because the callid and from tag will
` make the dialog id unique
`
`Of course nobody agrees on which ones really must be unique.
`
`When you reason this way you are betting that everybody else involved
`has made compatible assumptions to the one you are making.
`
`Thanks,
`Paul
`
`Adam Roach wrote:
`> [as an individual]
`>
`> This is an excellent example of where Postel's Maxim would address the
`> problem. (For the unaware, Postel's Maxim is "be conservative in what
`> you do, be liberal in what you accept from others"). For the failure
`> Glenn is describing, it takes the efforts of two misbehaving systems to
`> cause a failure.
`>
`> There is nothing in RFC3261 that normatively assigns semantics to a
`> Call-ID by itself. It is meaningful only when combined with other
`> identifiers, such as To: and From: tags. If you have software that is
`> failing when it sees duplicate Call-IDs, then that is a bug that should
`> be resolved.
`>
`> However, this misbehavior wouldn't happen if the sending party were a
`> bit more conservative in what it sent -- if it were more vigorous in
`> generating new Call-IDs for new attempts.
`>
`> If we're seeing real-life failures due to this behavior, I'd say both
`> sides are at fault. It takes two to dance this "Failure Tango".
`>
`> /a
`>
`>
`> Hisham Khartabil wrote:
`>> The via branch is used to match transactions. The state machine doesnt
`
`https://mailarchive.ietf.org/arch/msg/sipcore/upW9qQwKWVxqxYMqPfEJ8gLdaZY/
`
`1/4
`
`ERICSSON EXHIBIT 1030
`Ericsson Inc. v. Koninklijke KPN N.V.
`IPR2022-00557, Page 1
`
`
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`Paul Kyzivat <pkyzivat@cisco.com> Tue, 09 June 2009 13:08 UTCShow header
`
`Adam,
`
`I will agree with you on this one.
`
`Yet I want to emphasize the need for conservatism on the originating
`side. I have repeatedly seen cases where somebody says on of:
`- I can reuse the same callid because the from and to tags will
` make the dialog id unique
`- I can reuse the same from tag because the callid and to tag will
` make the dialog id unique
`- I can reuse the same to tag because the callid and from tag will
` make the dialog id unique
`
`Of course nobody agrees on which ones really must be unique.
`
`When you reason this way you are betting that everybody else involved
`has made compatible assumptions to the one you are making.
`
`Thanks,
`Paul
`
`Adam Roach wrote:
`> [as an individual]
`>
`> This is an excellent example of where Postel's Maxim would address the
`> problem. (For the unaware, Postel's Maxim is "be conservative in what
`> you do, be liberal in what you accept from others"). For the failure
`> Glenn is describing, it takes the efforts of two misbehaving systems to
`> cause a failure.
`>
`> There is nothing in RFC3261 that normatively assigns semantics to a
`> Call-ID by itself. It is meaningful only when combined with other
`> identifiers, such as To: and From: tags. If you have software that is
`> failing when it sees duplicate Call-IDs, then that is a bug that should
`> be resolved.
`>
`> However, this misbehavior wouldn't happen if the sending party were a
`> bit more conservative in what it sent -- if it were more vigorous in
`> generating new Call-IDs for new attempts.
`>
`> If we're seeing real-life failures due to this behavior, I'd say both
`> sides are at fault. It takes two to dance this "Failure Tango".
`>
`> /a
`>
`>
`> Hisham Khartabil wrote:
`>> The via branch is used to match transactions. The state machine doesnt
`
`https://mailarchive.ietf.org/arch/msg/sipcore/upW9qQwKWVxqxYMqPfEJ8gLdaZY/
`
`1/4
`
`ERICSSON EXHIBIT 1030
`Ericsson Inc. v. Koninklijke KPN N.V.
`IPR2022-00557, Page 1
`
`
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`6/9/23, 9:44 AM
`>> care about call-id or tags when matching transactions (if it is
`>> RFC3261 compliant that is). So a question to Glenn. Is the branch also
`>> the same?
`>>
`>> The transaction layer will pass the request to the UAS Core if there
`>> is no match in the transaction (branch in top via header). In that
`>> case, the core will not find a dialog match (since it rejected the
`>> original request) and will process the new request as a new request.
`>>
`>> Hisham
`>>
`>> 2009/6/6 Dean Willis <dean.willis@softarmor.com>:
`>>
`>>> On Jun 5, 2009, at 10:18 AM, Cahall, Glenn wrote:
`>>>
`>>>
`>>>> Paul,
`>>>>
`>>>> Thanks for the response.
`>>>>
`>>>> Once I read your response, I felt that I needed to explain the
`>>>> situation
`>>>> in more detail.
`>>>>
`>>>> Customer is sending us an INVITE, our response is a 486 BUSY. This
`>>>> exact
`>>>> scenario (all with same TNs) repeats itself 100+ times over the next 90
`>>>> seconds or so. All 100+ INVITEs contain the same Call-Id. However,
`>>>> tag
`>>>> value in the From field is different.
`>>>>
`>>>> So....now that you know more about the situation....is this in
`>>>> violation
`>>>> of the RFC?
`>>>>
`>>>> Also, during our discussions on the topic, we argued whether or not
`>>>> Call-Id could be reused. In short, as stated before, even if the
`>>>> initial
`>>>> call was successful, they believed that as soon as that call was
`>>>> completed,
`>>>> they were free to use the exact same Call-Id on the very next call.
`>>>>
`>>>
`>>> The From: tag SHOULD be invariant if the Call-ID is re-used in
`>>> response to a
`>>> 4xx, else the transaction won't match. And the CSeq SHOULD increase,
`>>> since
`>>> it is a new INVITE. This is specified in paragraph 6 of section
`>>> 8.1.4.5 in
`>>> RFC 3261. In practice, state matching fails if this isn't honored, so it
`>>> really could have been specified as a MUST; that is, we should probably
`>>> rewrite RFC 3261 to say something like:
`>>>
`>>> "The UAC MAY retry a transaction following certain 400-class
`>>> responses, If
`>>> the UAC retries such a transaction, it MUST retain the To, From,
`https://mailarchive.ietf.org/arch/msg/sipcore/upW9qQwKWVxqxYMqPfEJ8gLdaZY/
`
`2/4
`
`ERICSSON EXHIBIT 1030
`Ericsson Inc. v. Koninklijke KPN N.V.
`IPR2022-00557, Page 2
`
`
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`
`6/9/23, 9:44 AM
`>>> Call-ID and
`>>> Request-URI of the original transaction, and MUST increment the CSeq.
`>>> Failure to observe these two operational requirements is likely to
`>>> result in
`>>> proxies or the UAS not matching the retried transaction to any retained
`>>> state from previous transactions, which could result in errors
`>>> ranging from
`>>> erroneous log entries to denial-of-service scenarios, and it is in
`>>> extremely
`>>> poor taste too."
`>>>
`>>> In other words, the tag should be the same, the CSeq should
`>>> increment, and
`>>> you spank the customer for being annoying.
`>>>
`>>> Failing that, how's the Retry-After: header field on your 486 populated?
`>>> Perhaps you could crank it up to about 60 seconds, THEN spank them
`>>> for being
`>>> annoying it if they ignore it.
`>>>
`>>> --
`>>> Dean
`>>>
`>>>
`>>>
`>>> _______________________________________________
`>>> sipcore mailing list
`>>> sipcore@ietf.org
`>>> https://www.ietf.org/mailman/listinfo/sipcore
`>>>
`>>>
`>> _______________________________________________
`>> sipcore mailing list
`>> sipcore@ietf.org
`>> https://www.ietf.org/mailman/listinfo/sipcore
`>>
`>
`> _______________________________________________
`> sipcore mailing list
`> sipcore@ietf.org
`> https://www.ietf.org/mailman/listinfo/sipcore
`>
`
`[sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn
`Re: [sipcore] Reuse of Sip Call-Id question.. Byron Campen
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Attila Sipos
`Re: [sipcore] Reuse of Sip Call-Id question.. Attila Sipos
`Re: [sipcore] Reuse of Sip Call-Id question.. Byron Campen
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Byron Campen
`Re: [sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn
`
`https://mailarchive.ietf.org/arch/msg/sipcore/upW9qQwKWVxqxYMqPfEJ8gLdaZY/
`
`3/4
`
`ERICSSON EXHIBIT 1030
`Ericsson Inc. v. Koninklijke KPN N.V.
`IPR2022-00557, Page 3
`
`
`
`6/9/23, 9:44 AM
`
`Re: [sipcore] Reuse of Sip Call-Id question..
`Re: [sipcore] Reuse of Sip Call-Id question.. Dale Worley
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Bob Penfield
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Dean Willis
`Re: [sipcore] Reuse of Sip Call-Id question.. Dean Willis
`Re: [sipcore] Reuse of Sip Call-Id question.. Dale Worley
`Re: [sipcore] Reuse of Sip Call-Id question.. Dean Willis
`Re: [sipcore] Reuse of Sip Call-Id question.. Bob Penfield
`Re: [sipcore] Reuse of Sip Call-Id question.. Dale Worley
`Re: [sipcore] Reuse of Sip Call-Id question.. Hisham Khartabil
`Re: [sipcore] Reuse of Sip Call-Id question.. Adam Roach
`Re: [sipcore] Reuse of Sip Call-Id question.. Dean Willis
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Re: [sipcore] Reuse of Sip Call-Id question.. Dean Willis
`Re: [sipcore] Reuse of Sip Call-Id question.. Paul Kyzivat
`Hide Navigation Bar
`
`
`
`
`
`Date
`
`Thread
`
`v2.15.0 | Report a Bug | By Email
`
`
`
`
`
`https://mailarchive.ietf.org/arch/msg/sipcore/upW9qQwKWVxqxYMqPfEJ8gLdaZY/
`
`4/4
`
`ERICSSON EXHIBIT 1030
`Ericsson Inc. v. Koninklijke KPN N.V.
`IPR2022-00557, Page 4
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
