Hi krishna,
I think what u saying is correct. Experts/Implementors please clarify
us why its mandated or is the RFC underspecified?
TIA,
Karthik
----- Original Message -----
From: "KrishnaKanthT 70508" <[EMAIL PROTECTED]>
To: "Karthik M" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 30, 2004 6:06 AM
Subject: Re: [Sip-implementors] A doubt in offer/answer model
> 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
