[reSIProcate] Bug with Multiple Accept headers
Scott Godin
sgodin at sipspectrum.com
Thu May 20 16:11:26 CDT 2010
The accept header is indicating what body types the endpoint is willing to
accept in the response. The validateAccept code is following RFC3261
checking. I would recommend that you just disable Accept header validation
as it reduces interoperability - by setting
MasterProfile::validateAcceptEnabled to false.
Scott
On Thu, May 20, 2010 at 5:02 PM, <aron_rosenberg at logitech.com> wrote:
> So I found the issue. We had strict mimetype checking on and
> MasterProfile.cxx doesn't add application/sdp for BYE. But this brings up an
> interesting question...Should the stack be validating Accept for an inbound
> request on a message that has no body?
>
>
> -Aron
>
> Aron Rosenberg
> Logitech Inc, (SightSpeed Group)
>
> __________________
>
>
> So adding just
>
> m.header(h_Accepts).push_back(resip::Mime("application","sdp"));
>
> to the onReadyToSend for InviteSession if its a BYE, causes the stack to
> issue a 406 when receiving it. Let me step debug inside resiprocate to
> figure out whats going on.
>
>
> Aron Rosenberg
> Sr. Director, Engineering
> Phone: +1 (510) 713-5801
> Logitech Inc, (SightSpeed Group)
>
> [image: Inactive hide details for Scott Godin ---05/20/2010 01:39:17
> PM---The easiest way to decorate the BYE message is to use the onR]Scott
> Godin ---05/20/2010 01:39:17 PM---The easiest way to decorate the BYE
> message is to use the onReadyToSend InviteSession callback.
>
> From: Scott Godin <sgodin at sipspectrum.com>
> To: aron_rosenberg at logitech.com
> Cc: resiprocate-devel <resiprocate-devel at list.resiprocate.org>
> Date: 05/20/2010 01:39 PM
> Subject: Re: [reSIProcate] Bug with Multiple Accept headers
> Sent by: slgodin at gmail.com
> ------------------------------
>
>
>
> The easiest way to decorate the BYE message is to use the onReadyToSend
> InviteSession callback.
>
> Scott
>
> On Thu, May 20, 2010 at 3:42 PM, <*aron_rosenberg at logitech.com*<aron_rosenberg at logitech.com>>
> wrote:
>
> I'll try and a get full resip log to see whats going on, but the
> hardware endpoint is in India. I have noticed, that resiprocate doesn't
> include the Accept header in the BYE's it generates, is there a way perhaps
> to force that?
>
> -Aron
>
>
>
>
> Aron Rosenberg
> Logitech Inc, (SightSpeed Group)
>
> [image: Inactive hide details for Scott Godin ---05/20/2010 12:11:25
> PM---The code in validateAccept looks right to me - it should be s]Scott
> Godin ---05/20/2010 12:11:25 PM---The code in validateAccept looks right to
> me - it should be searching all Accept headers. In order
>
> From: Scott Godin <*sgodin at sipspectrum.com* <sgodin at sipspectrum.com>>
> To: *aron_rosenberg at logitech.com* <aron_rosenberg at logitech.com>
> Cc: resiprocate-devel <*resiprocate-devel at list.resiprocate.org*<resiprocate-devel at list.resiprocate.org>
> >
> Date: 05/20/2010 12:11 PM
> Subject: Re: [reSIProcate] Bug with Multiple Accept headers
> Sent by: *slgodin at gmail.com* <slgodin at gmail.com>
> ------------------------------
>
>
>
>
> The code in validateAccept looks right to me - it should be searching
> all Accept headers. In order to get into the code block you mentioned the
> following call would have to be returning false:
> if(request.exists(h_Accepts))
> Given that you see the Accept headers in the BYE message, I'm not sure
> why this is failing offhand. Perhaps the SIPMessage failed to parse
> properly? Maybe the resip logs would reveal more.
>
> Scott
>
> On Thu, May 20, 2010 at 2:19 PM, <*aron_rosenberg at logitech.com*<aron_rosenberg at logitech.com>>
> wrote:
> So we have an interop issue with another SIP stack relating to that
> stack sending multiple "Accept" headers. Resiprocate is bouncing the BYE
> message with a 406 Not Acceptable error.
>
> The brief snippet from a pcap shows Accept being listed in this
> exact order.
>
> Accept: application/sdp,application/media_control+xml\r\n
> Accept: application/presentation_token_control+xml\r\n
>
> The same set of headers is allowed in the initial INVITE.
>
> I believe what is happening is that
> DialogUsageManager::validateAccept(const SipMessage& request)
> isn't properly searching multiple Accept header lines and it's falling into
> this block of code
>
> // If no Accept header then application/sdp should be assumed for
> certain methods
> else if(method == INVITE ||
> method == OPTIONS ||
> method == PRACK ||
> method == UPDATE)
> {
> if(getMasterProfile()->isMimeTypeSupported(request.header(h_RequestLine).method(),
> Mime("application", "sdp")))
> {
> return true;
> }
> }
>
> But in this case, BYE is not an option, so it bounces the
> message.
>
> A very simple fix would be to add BYE to that list, but are
> multiple Accept headers legal? If so, then the logic higher up in
> validateAccept needs to be changed to search more than just the last header
> line.
>
> Which is the right approach?
>
> Aron Rosenberg
> Logitech Inc, (SightSpeed Group)
>
> _______________________________________________
> resiprocate-devel mailing list*
> **resiprocate-devel at resiprocate.org*<resiprocate-devel at resiprocate.org>
> *
> **https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> *<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
>
>
> _______________________________________________
> resiprocate-devel mailing list*
> **resiprocate-devel at resiprocate.org*<resiprocate-devel at resiprocate.org>
> *
> **https://list.resiprocate.org/mailman/listinfo/resiprocate-devel*<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100520/32678b20/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100520/32678b20/attachment.gif>
More information about the resiprocate-devel
mailing list