Hi elias, I want to give an example.
Assume that there are 3 users - A,B and C and a B2BUA providing application services. Now suppose A makes a call and the B2BUA routes it to B, and after some time, the application on B2BUA decides to disconnect B and reconnect A to C, Now the sequence of messages can be like this. Now if you ignore the origin line checking, you can achieve the connectivity b/n A and C with these messages. A B2BUA C | | | | | INVITE NO SDP | | |--------------->| | | 18x | | |<---------------| | | 200 OK With SDP| | |<---------------| | RE-INVITE | | | with C's SDP | | |<---------------| | |200 OK with SDP | | |--------------->| | | |ACK with A's SDP| | |--------------->| | ACK | | |<---------------| | If you even consider the origin line checking, we need more number of messages to achieve the connectivity b/n A and C. Also i feel the checking of origin line in this case is not doing any value addition. Correct me if i am wrong. Rgds Krishna ----- Original Message ----- From: [EMAIL PROTECTED] Date: Friday, March 26, 2004 10:00 am Subject: Re: [Sip-implementors] A doubt in offer/answer model > > Hi Krishna, > > Yes. Points 2 and 3 will do. > > Point 1 is not required because > >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. > Elias > Hughes Software Syatems > http://www.hssworld.com > > > > > > KrishnaKanthT > > 70508 > > <[EMAIL PROTECTED] > To > .com> sip- > [EMAIL PROTECTED] > Sent by: > cc > sip-implementors- > > [EMAIL PROTECTED] > Subject > ia.edu Re: [Sip-implementors] A > doubt in > offer/answer model > > > > 03/26/04 04:24 AM > > > > > > > > > > > > > > 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 > examples and > >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
