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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090626/e2552fbc/attachment-0001.html>
