`
`Mail Archive
`
`Re: [Sip] Reuse of Sip Call-Id question...
`Martin Larochelle <martin@macadamian.com>
`UTC | Show header
`
`| Fri, 05 June 2009 15:45
`
`This is right, although it does not mean that each call attempt must use a
`new call-id.You wrote that "We have customer UAs that are reusing the same
`Sip Call-Id for multiple call attempts into our network.", if by attempt,
`you mean trying to make a call that fails with a error that can be retried
`(as 407, 422) then in that case, it is acceptable to use the same call-id (
`with an incremented C-Seq and empty to-tag)
`--
`Martin Larochelle
`Software Architect
`
`On Fri, Jun 5, 2009 at 11:15 AM, Attila Sipos
`<attila.sipos@vegastream.com>wrote:
`> you will get the same response here as on sip-core.
` SIP call-id should be unique for each call, it cannot be re-used
` Regards,
` Attila
`
`>>
`
`>>
`
`>>
`
`>>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`------------------------------
`> *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of
`*Cahall,
`> Glenn
`> *Sent:* 04 June 2009 17:46
`> *To:* chogg@nortelnetworks.com; jdrosen@dynamicsoft.com; zmolek@avaya.com;
`> Marie-Noelle.Mathieu@compaq.com; sip@ietf.org
`> *Subject:* [Sip] Reuse of Sip Call-Id question...
` Folks,
` I work for a VoIP company, Level3 Communications, and have been doing some
`> research on the internet about
` a specific condition that has arisen here dealing with the Sip protocol.
`> Your names came up during my research.
` Was hoping I could get some feedback about the reuse of Sip Call-Id.
` We have customer UAs that are reusing the same Sip Call-Id for multiple
`> call attempts into our network.
` After reviewing the Sip RFC 3261, both myself and my team concluded that
`> this was a clear violation of the spec. based
` on the following verbiage...
` 8.1.1.4 Call-ID
` The Call-ID header field acts as a unique identifier to group
` together a series of messages. It MUST be the same for all requests
` and responses sent by either UA in a dialog. It SHOULD be the same
` in each registration from a UA.
` 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
` However, some voice engineers are stating that the definition of
`> “globally unique over time and space” means only during the
` context of a given call. Therefore, once this context is over....Sip
`> Call-Id can in fact be reused in the very next context.
` What is your take on this?
`>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`>>
`
`https://mailarchive.ietf.org/arch/msg/sip/N6mmx-zA7lFAeSQmJ911lrGjvI8/[5/10/2023 1:50:13 PM]
`
`Koninklijke KPN NV - Exhibit 2028
`Ericsson Inc. v. Koninklijke KPN NV PTAB-IPR2022-00557
`Page 1 of 2
`
`
`
`Re: [Sip] Reuse of Sip Call-Id question...
`> Thanks,
` Glenn E. Cahall
` Sr. Architect
` Level3 Communications
`
`>>
`
`>>
`
`>>
`
`>>>>
`
`.
` _______________________________________________
`> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
`> This list is for NEW development of the core SIP Protocol
`> Use sip-implementors@cs.columbia.edu for questions on current sip
`> Use sipping@ietf.org for new developments on the application of sip
`
`>>
`
`Sip] Reuse of Sip Call-Id question... Cahall, Glenn
`Re: [Sip] Reuse of Sip Call-Id question... Attila Sipos
`Re: [Sip] Reuse of Sip Call-Id question... Martin Larochelle
`
`> [
`
`Hide Navigation Bar
`
`v2.14.0 | Report a Bug | By Email
`
`https://mailarchive.ietf.org/arch/msg/sip/N6mmx-zA7lFAeSQmJ911lrGjvI8/[5/10/2023 1:50:13 PM]
`
`Koninklijke KPN NV - Exhibit 2028
`Ericsson Inc. v. Koninklijke KPN NV PTAB-IPR2022-00557
`Page 2 of 2
`
`
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
