[SIPForum-discussion] RE: [Sip-implementors] Question regarding changing optional messa ge header information

[Manpreet Singh]

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:pkyzivat at cisco.com] 
Sent: Wednesday, March 29, 2006 7:25 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
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
> Sip-implementors at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20060330/2ff1a73d/attachment-0001.html>