[SIPForum-discussion] Is SDP body is required for RefreshInvites.........?

[Ayyanar PK]

 If you do not wish to send SDP for Session refresh then use UPDATE method without SDP as alternative method. Refer RFc 4028 for this mechanism.Also nothing as below is provided in RFC4028 for differentiating a session refresh ReINVITE"There is a parameter which differentiate the "ReInvites" with the "session refresh Invite" request i.e "SessionVersion". ( SV increments for each ReInvite but remains constant for all the session refresh requests ). "Thanks,Ayyanar Original message From:Govindraj.B.H @ Gkk< govindrajh at yahoo.co.in >Date: 25 Nov 09 12:05:10Subject:[SIPForumdiscussion] Is SDP body is required for RefreshInvites.........?To: discussion at sipforum.orgHi, As per my knowledge, the main intention of Session Refresh Requests is to inform the intermidiate elements about the session aliveness. Which can be served by normal Invite. Why do we need to send the session body along with all the session refresh Invite requests there by increasing the traffic density. There is a pa
 rameter which differentiate the "ReInvites" with the "session refresh Invite" request i.e "SessionVersion". ( SV increments for each ReInvite but remains constant for all the session refresh requests ). Is there any other reason behind sending the body in Session Refresh Invites.........? [ If it is the only reason ( SessionVersion ) to differentiate the Reinvites with the Refresh Invites, then there is no point in sending the Body params along with the session refresh Invites. Still we can differentiate both the requests. Invite with "ContentLength = 0" is a Refresh Invite and "CT = Nonzero" is an ReInvite. So with this implementation we can reduce the traffic overhead. ] All, plz provide me your inputs/suggestions for the above discussion.The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20091126/c76b281a/attachment-0002.html>