pls take attention to "may decide to". And you said pjsip respond is 200 OK without SDP answer. So that re-Invite not failure. regards, Gang On Fri, Jun 26, 2009 at 9:45 PM, Mark Webster <mark.webster+pjsip at gmail.com<mark.webster%2Bpjsip at gmail.com> > wrote: > > > On Fri, Jun 26, 2009 at 4:34 AM, Gang Liu <gangban.lau at gmail.com> wrote: > >> RFC 3261 >> 14.1 UAC Behavior >> >> The same offer-answer model that applies to session descriptions in >> INVITEs (Section 13.2.1) applies to re-INVITEs. >> >> > Also from RFC 3261: > > During the session, either Alice or Bob may decide to *change the** > ** characteristics of the media session.* This is accomplished by > sending a re-INVITE containing a new media description. This re- > INVITE references the existing dialog so that the other party knows > that it is to modify an existing session instead of establishing a > new session. The other party sends a 200 (OK) to accept the change. > The requestor responds to the 200 (OK) with an ACK. If the other > party does not accept the change, he sends an error response such as > 488 (Not Acceptable Here), which also receives an ACK. *However, the** > ** failure of the re-INVITE does not cause the existing call to fail *- > the session continues using the previously negotiated > characteristics. > > They are the UAC here. They aren't changing any characteristics of the > media session at all, only using it for a keep-alive. Even if I am supposed > to reply with SDP despite there being no changes, the call should still not > fail, but they are hanging it up. Everything about this behaviour seems to > go against logic and the spirit of the RFCs. > > > >> It is another issue why pjsip detaching / re-attaching of media >> transport. We use external media stream implementation and only do media >> update when SDP offer or answer version is changing. >> > > It's fine to ignore in_media_update in this case because there are no > changes... > > -Mark > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090627/f9a8bb68/attachment.html>
