Hi karthik, If you consider that session match will not occur for sdp if the origin line changes in offer sdp, then a session match should not occur if the when the origin line changes in the answer sdp. Correct me if i am wrong.
Rgds Krishna ----- Original Message ----- From: Karthik M <[EMAIL PROTECTED]> Date: Friday, March 26, 2004 9:25 am Subject: Re: [Sip-implementors] A doubt in offer/answer model > Hi krishna, > The sdp sessions may be created with the "<username>, <session > id>,<network type>, <address type> and <address> " as id. In > that case, > version field is the only way to say the change in sdp for that > particularsession. Or else the sdp message will go different sdp > session but that sip > session already has some sdp session assoicated. Since sdp can be > sent email > or any other means, this is more of a sdp requirement than sip > requirement.Correct me if I am wrong. > > > Thanks > Karthik > > > > > ----- Original Message ----- > From: "KrishnaKanthT 70508" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, March 26, 2004 6:54 AM > Subject: Re: [Sip-implementors] A doubt in offer/answer model > > > > Hi elias, > > > > Are you saying that the restriction was imposed only for the > sole reason > to identify if the remote party has changed his sdp or not. Cant > the same > logic be like this:- > > 1. If the origin line in the offer has been changed, then it > means that > the sdp has been changed > > 2. If the origin line is same, then check the version field, If > it has > been incremented, then sdp has been changed > > 3. If the version is not incremented, then the sdp has not > changed. In > this case the party receiving the sdp must just verify that that > sdp has not > been changed. > > > > Correct me if am wrong. > > > > Rgds > > Krishna > > > > Elias wrote: > > > > >"When issuing an offer that modifies the session, the "o=" line > of the > new > > >SDP MUST be identical to that in the previous SDP, > > >except that the version in the origin field MUST increment by > one from > the > > >previous SDP. If the version in the > > >origin line does not increment, the SDP MUST be identical to > the SDP with > > >that version number." > > > > > >- study along with the next statement. If there is a change in the > session > > >then the offerer increments the version # in the o line to > denote the > > >session change. But the other fields in the o line remain the same, > because > > >it is from the same offerer. > > > > > >"The answer to an offered session description is based on the > offered> >session description. If the answer is > > >different from the offer in any way (different IP addresses, ports, > etc.), > > >the origin line MUST be different in > > >the answer, since the answer is generated by a different > entity. In that > > >case, the version number in the "o=" > > >line of the answer is unrelated to the version number in the o > line of > the > > >offer." > > > > > >- Answer is generated by a different entity, so the o line is > bound to be > > >different. > > > > > >Have a look @ draft-johnston-mmusic-offer-answer-examples for > examplesand > > >flows. > > >-Elias > > >Hughes Software Syatems > > >http://www.hssworld.com > > > > >KrishnaKt wrote: > > > > >>Hi all, > > >> > > >>I have one doubt in rfc 3264. Section 8 of rfc3264 says that > > >> > > >>"When issuing an offer that modifies the session,the "o=" line > of the > new > > >>SDP MUST be identical to that in the previous SDP" > > >> > > >>1. Is there any specific reason to enforce this condition? > > >>2. Why isn't the same restriction enforced while giving an > answer SDP. > > >> > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
