Paul Thanks for the response. So it looks like it is not clearly defined as to what should be the behaviour and its more implementation specific. My specific concern was for DTMF mid call change where the UA is trying to change from out of band ( either INFO or NOTIFY ) to rfc 2833. If in the confirmed dialog state, the out of band dtmf ( in signaling path ) was selected but the UA wishes to change that to rfc 2833, then a mid call re-invite without the applicable INFO/NOTIFY headers and the SDP with rfc 2833 payload should work right? Would eleminating those optional headers do any good and switch back and forth between out of band in signaling to out of band in media ( or vice versa )?
Thanks Manpreet -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 29, 2006 7:25 PM To: Manpreet Singh Cc: [email protected]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Question regarding changing optional message header information Manpreet, The sad truth is that many things that are communicated in SIP headers have no well defined scope of applicability. At the minimum they may only reflect the value at the instant the message was sent. At the maximum they may declare an invariant. Take Supported. It isn't very helpful if it only applies at the time sent. At the least it ought to apply for the duration of the transaction. It is sometimes recommended that Supported list everything and be included in every message. But that isn't often done. I think sometimes it is assumed that Supported is included when the other end might want to make immediate use. The OPTIONS request returns a bunch of information, but that info isn't relevant to the processing of the transaction itself, so for it to be useful it must be expected to remain valid for some period of time beyond that. Since OPTIONS is usually done outside a dialog, dialog scope probably isn't right either. This is one of those things that seems to require formal clarification. Regarding Call-Info: there aren't many semantics attached to it anyway. I would say just send it again any time you want. If somebody has been caching the value, hopefully they will then replace the cache. Paul Manpreet Singh wrote: > Hi > > Whats the right way to change certain optional message headers in the > a call flow, be it early or confirmed dialog? Offer/answer model is > mainly concentrating on the SDP part but if a UA needs to do a mid > call change for certain mesaage headers, how can that be done. By > change it can be telling it doesnt support anymore or just changing the parameters for that header. > > One example would be the Call-Info Header. If the initial INVITE sent > this header then, would the following offers need to carry that too? > Also would excluding that header in future offers, either in an early > dialog state ( Prack or Update) or confirmed dialog state ( > re-invite), inform the terminating UA that that optional method is not supported? > > I hope I was clear in my explanation. > > Thanks > M. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
