Hi, Giancarlo Murino wrote: > Hi, > So a Call - ID is unique within a session. Well. But a session is terminated > with a BYE message? Thanks >
As a UAC, you must include both tags in BYE (as for any other in-dialog request), which together with call's ID identify a dialog. Cheers. > > -------Messaggio originale------- > > Da: Bogdan Pintea > Data: 11/03/06 13:09:34 > A: [EMAIL PROTECTED] > Cc: Giancarlo Murino; [EMAIL PROTECTED]; > [email protected] > Oggetto: Re: [Sip-implementors] Rules about Call ID, From tag and To tag > > [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
