Re: [sipX-dev] Record Route Processing in Requests
> -----Original Message-----
> From: Dale Worley [mailto:dworley@xxxxxxxxxxx]
> Sent: Monday, August 18, 2008 6:19 PM
> To: Nair, Arjun (CAR:9D30)
>
> I think the name might better be "responseMayBeDialogForming"
> -- the problem is that the sender doesn't always know whether
> the response will be dialog-forming or not, and we can only
> omit Record-Route processing if we *know* that the response
> is not dialog-forming. This also bears on whether the
OK, I agree on the premise that it is better to have a
non-dialog-forming Response echo back the Record-Route headers, than
have a dialog-forming Response not do so.
> default value should be FALSE. At least in principle, the
> default should be to handle Record-Route.
True, while it makes sense to handle Record-Routes by default, there
already exists so much code that is based on it not being handled by
default - 200 OKs to BYE, 202 ACCEPTED to in-dialog NOTIFYs, etc. Now,
if handling Record-Routes in non-dialog-forming Responses are truly
inconsequential, then we can go ahead and set the default to TRUE,
otherwise, I would suggest we raise a separate issue and make this
change across the board..
>
> (How is this done for INVITEs?)
INVITE Responses are handled explicitly in the stack using functions
such as SipMessage::setInviteOkData(),
SipMessage::setInviteRingingData() etc. The dialog-forming 200 OK
Response to an INVITE has the Record-Route headers in it because the
function - SipMessage::setInviteOkData() - explicitly adds them when
building the response..
>
>
> Dale
>
Thanks for the comments,
Arjun
