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>                     [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

Reply via email to