[asterisk-dev] Custom SIP headers and reinvites

[Bala Neelakantan]

Thanks,
Neel


> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of Kevin P. Fleming
> Sent: Tuesday, April 17, 2007 9:14 PM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Custom SIP headers and reinvites
> 
> Watkins, Bradley wrote:
> 
> > I guess what I'm looking for is some guidance on what the correct
> > behavior is here.  Obviously, these headers should be available one way
> > or the other.  The question is whether the reinvite should have the
> > custom headers or whether they need to have some more persistant storage
> > at the receiving end.  I'm inclined to say the latter, as it's possible
> > that you could have this same issue with other B2BUA's in a similar
> > scenario.
> 
> I would agree in principle that this is the receiving end's
> responsibility to handle. The first issue will be clearly defining which
> headers should be preserved throughout the life of the dialog even when
> subsequent INVITEs have been received. This could be just 'all headers
> that begin with X-' or it could be more complex than that, but the more
> complex it is the less likely it will get treated as a 'bug fix' or a
> simple enhancement :-)

I am answering from RFC point of view and not from current asterisk
implementation.

Looking at the RFC 3261:

12.2.1.1 Generating the Request

   A request within a dialog is constructed by using many of the
   components of the state stored as part of the dialog.

And the RFC lists all the mandatory headers.    Another reference in Section
8.1.1 provides those headers, and lastly talks about other headers.

8.1.1.10 Additional Message Components

   After a new request has been created, and the header fields described
   above have been properly constructed, any additional optional header
   fields are added, as are any header fields specific to the method.

So, in this case, my interpretation is that if the optional headers are to
be populated if needed, and it depends upon the semantics of the headers.

One place where you might want to remove headers is, if the Re-INVITE might
want to take out certain SIP features/capability.

Original INVITE negotiated with Session Timers.

After a while, the endpoints want to stop session refresh.  In this case,
the Session-Expires header, can be changed.  Also Supported: header might
change, if originally listed in INVITE.


> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev