[inlined] [EMAIL PROTECTED] wrote: > > Communication powers the world. > Aricent powers communications. > > FLEXTRONICS SOFTWARE SYSTEMS IS NOW ARICENT. > > > > Hi, > > the Call-ID is unique for each SIP Request. Even though the on a same > session if you are going to use multiple requests (like invite ,subscribe > options .. etc ) you have to generate the a new call id for each request. >
AFAIK, this is quite false: the Call-ID is unique per session (or call), not request. INVITE and SUBSCRIBE are indeed session opening methods, case in which a unique ID is generated; but they can also be used for refreshing the session, case in which the ID (from initial request) is "reused". > In your case when you received a BY E that dialog is completed. The next > Invite request starts a new Dialog so you can;t use the old Call-ID. > > Refer the RFC 3261 Section 20.8 for more details. > > > In the old RFC the proxy is using the call-id to maintain the transaction > ,but as per the RFC 3261 both Call-ID and Tags are used to maintain the > transactions... > > Regds > Balaji.C > > > > > "Giancarlo Murino" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/03/2006 02:30 PM > > > To > <[email protected]> > cc > > Subject > [Sip-implementors] Rules about Call ID, From tag and To tag > > > > > > > Hi, > > I have a trouble about Call Id, From tag and To tag. On a Web site I read: > > > > Call-ID is so called call identifier. It must be a unique string that > identifies a call. A call consists of one or more dialogsi. Multiple user > agents may respond to a request when a proxy along the path forks the > request. Each user agent that sends a 2xx establishes a separate dialog > with > the caller. All such dialogs are part of the same call and have the same > Call-ID. > > >From tag is generated by the caller and it uniquely identifies the dialog > in > the caller's user agent. To tag is generated by a callee and it uniquely > identifies, just like From tag, the dialog in the callee's user agent. > > This hierarchical dialog identifier is necessary because a single call > invitation can create several dialogs and caller must be able to > distinguish > them. > > > > So, if I have understood, if there are parallel dialogs (as in forking > case) > I have to use the same Call-Id , but different to tag and from tag, > because > such dialogs are part of the same call. The session's identified only by the Call-ID; the dialogs by the tuple (Call-ID, From tag, To tag). > But if I have two sequencial > dialogs > like in the following flow: > > ------------->INVITE (start first dialog) > > <------------- OK > > --------------> BYE (end first dialog) > > ------------->INVITE (start second dialog) > > <------------- OK > > --------------> BYE (end second dialog) > > Are they a part of the same call, or they belong to two different calls? > According to the definition of call (a call is a group of one or more > dialogs), I think they are a part of the same call. So, must they share > the same Call-ID? If they aren't a part of the same call, why? > In case your first INVITE did not fork, your session only contains one dialog. When this dialog is teared down with BYE (whose final response is not depicted above, I guess as a flaw, rather than intention), the session goes down as well. If after sending the BYE you want another dialog with the same party you just BYEed, you have to start a new session, which means a new and unique Call-ID in the INVITE. Cheers. > Giancarlo_______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > *********************** Aricent-Private *********************** > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of > the individual to whom it is addressed. It may contain privileged or > confidential information and should not be > circulated or used for any purpose other than for what it is intended. If you > have received this message in error, > please notify the originator immediately. If you are not the intended > recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this > message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
