It wasn't stated who is doing the reinvite, and that can make a difference.
Also, there is nothing special about a reinvite used for session timer refresh vs any other reinvite. Only the sender of the reinvite knows why it was sent, and reinvites that are primarily for some other purpose also refresh (or cancel) the session timer. If the sender of the reinvite has no motivation for doing so other than refreshing the session timer, or simply verifying the state of the session, then it could: - send the same sdp it did the last time - send an offer reflecting how it would like the session to be What it should not do is make an offer that anticipates what it thinks the other party wants, based on what it has seen as responses from the other party. Doing so can get into some nasty states, not so much with codecs, but with other stuff, like sendonly/recvonly. Also, you can never be certain that circumstances haven't changed at the other end. So, if UA1 is sending the reinvite, if it still would prefer to use codec B or C, then it should probably offer them again, in addition to A. But it might prefer not to do that if the change would cause some added cost, pain, or poor user experience. For instance it it would require renegotiating QoS, that might be a reason not to offer a change. IF, after it decides what it wants to offer, that turns out to be the same as what it sent last, then it should set the o-line the same as last time. You should also check out http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt Thanks, Paul shamik.s...@wipro.com wrote: > Hi, > > I think you mean to say that the re-invite is send before the session > timer expires as otherwise the session will be terminated,I think this > re-invite should only contain codec A as it is the codec that has been > negotiated,and the media streams for the other codec has been rejected > by the far-end so your SDP can contain all the three codecs but only > codec A should be ACTIVE. > > Since the two-peer has locked down on codec A,I think this should be the > only active codec as the far end has not mentioned the other codec's in > his answer so we can be sure that there will be no change of codec on > the fly. > > To sum up,codec A can be the only active codec while B and C are > inactive. > > > > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Radha krishna > Sent: Tuesday, June 02, 2009 4:09 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SDP in Session Refresh Request > > > Hi All > > What should be the SDP in the following scenario. > > 1) UA1: Send INVITE with 3 codec's. A, B and C. > 2) UA2: Received 200 with Codec A. > 3) UA1: Session timer expired. > 4) UA1: Sending Re-INVITE what should SDP contain? > According to RFC we should not change SDP's, so o-line > version MUST be same as > initial INVITE, What about Codec? It should have A, B and C > or just A. > I think it should contain all three A, B and C right? > > Regards > S.Radha krishna > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The company > accepts no liability for any damage caused by any virus transmitted by this > email. > > www.wipro.com > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
