"Solving HERPF" in general does not appear to be something we are willing to do.
However, having 199 carry useful information such as "why the dialog was terminated", to me, seems like something that ought be allowed. PS: I think including the reason should be mandatory. > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2008 16:49 > To: Christer Holmberg > Cc: Audet, Francois (SC100:3055); IETF SIP List > Subject: Re: [Sip] How to make draft-ietf-sip-199 more useful > > > > Christer Holmberg wrote: > > Hi, > > > >>> The agreement in Dublin was to not say anything about > sipfrag. But, > >>> I am ok with putting it back, especially if people want > more use-cases. > >>> I guess it could be optional for the UAC to inidicate support of > >>> sipfrag. > >> It doesn't have to be sipfrag. Just the plain value of the error > > response code would work too. Whatever is easier. > > > > Maybe the Reason header could be used? Or a new parameter. I agree > > that sipfrag is a little too "heavy" for sending a response code. > > Well, with REFER sipfrag is typically used to carry only the > response code. Sending more is optional. If something is to > be sent then I think this is a good mechanism for doing so. I > think the question would be whether sending the sipfrag with > at least the reason is MUST, SHOULD, or MAY. > > OTOH, I thought this was removed from the draft because some > people thought this smacked too much of solving the HERFP > problem when it didn't really do the job fully. Has anything changed? > > Thanks, > Paul > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
