Even though the following draft was not adopted, you might find it useful. http://tools.ietf.org/html/draft-kaplan-sip-secure-call-id-00
> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Srikanth > satturi > Sent: Wednesday, October 19, 2011 5:29 AM > To: Brandon W. Yuille > Cc: [email protected] > Subject: Re: [Sip-implementors] rules for SIP call Id generation > > thanks all > > On Wed, Oct 19, 2011 at 2:05 PM, Brandon W. Yuille > <[email protected]>wrote: > > > ** > > Nope, as you see the callid field is defined as simply a word > followed by > > an optional '@' with a trailing word. Just stick to the defined > values that > > make up a word and you're all set. > > > > Since it seems you're looking for exact information then you should > just > > read rfc 3261 rather than asking for help multiple times within 10 > mins: > > > > 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 > > 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. > > > > Use of cryptographically random identifiers (RFC 1750 [12]) in the > > generation of Call-IDs is RECOMMENDED. Implementations MAY use > the > > form "localid@host". Call-IDs are case-sensitive and are simply > > compared byte-by-byte. > > > > Using cryptographically random identifiers provides some > > protection against session hijacking and reduces the likelihood > of > > unintentional Call-ID collisions. > > > > No provisioning or human interface is required for the selection > of > > the Call-ID header field value for a request. > > > > For further information on the Call-ID header field, see Section > > 20.8. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
