[reSIProcate] Fwd: Handling NOTIFY with Content type: Mulipart/related; type = "application/rlmi+xml"
Byron Campen
bcampen at estacado.net
Fri Sep 21 14:56:33 CDT 2007
I am forwarding this to the devel list, because I think it exposes a
bug. The short version of this is that calling Contents::remove() (to
remove a header) does not trigger a parse of the Contents object. So,
encoding the Contents does not have the desired effect, since we
stream the raw buffer (which still has the headers we tried to
remove). Furthermore, when we _do_ trigger a parse after calling
remove, it just parses from the raw buffer, leaving the _parsed_
version with the headers that we thought we removed. It seems that we
should put a checkParsed() call in each of the remove functions.
Comments?
Best regards,
Byron Campen
Begin forwarded message:
> From: Byron Campen <bcampen at estacado.net>
> Date: September 21, 2007 2:47:13 PM CDT
> To: Subramanian Kasi Subramanian <subbu.subramanian at yahoo.com>
> Subject: Re: [reSIProcate] Handling NOTIFY with Content type:
> Mulipart/related; type = "application/rlmi+xml"
>
> I see what is going on here. The LazyParser behavior is biting
> you. When the Contents hasn't parsed itself, the way it will encode
> itself is from the raw buffer. It appears that removing headers
> doesn't trigger a parse, so when you encode it afterward, it just
> streams the raw buffer.
>
> So, to get this to work (for the time being; I will bring this up
> as a bug on the list), you'll need to cause the Contents to parse
> its headers (the non-exception-throwing way to do this is to call
> Contents::isWellFormed()). Then, the removal of the headers will
> actually work.
>
> Best regards,
> Byron Campen
>
>
>> Thank you for your response.
>> I was not setting the outbound proxy server after setting that it
>> works fine now.
>> I have another question though
>>
>> On the OnUpdate() callback funstion I want to remove the below
>> headers before i parse my XML data.
>> I tried the following:
>> Contents *body = notify.getContents();
>> body->remove(h_ContentTransferEncoding);
>> body->remove(h_ContentID);
>> body->remove(h_ContentType);
>>
>> std::string notifyMessage = resip::Data::from(*body).c_str();
>>
>> the notifyMessage still has these headers in them. Do you know
>> what I'am doing wrong?
>>
>>
>> Thanks again for your resopnses
>> Subbu
>>
>>
>>
>> ----- Original Message ----
>> From: Byron Campen <bcampen at estacado.net>
>> To: Subramanian Kasi Subramanian <subbu.subramanian at yahoo.com>
>> Sent: Thursday, September 20, 2007 4:15:55 PM
>> Subject: Re: [reSIProcate] Handling NOTIFY with Content type:
>> Mulipart/related; type = "application/rlmi+xml"
>>
>> I apologize for the delay, I've been completely swamped lately.
>>
>> I am not an expert on the "eventlist" package, so I can't say
>> whether your presence server is misbehaving or not. If it does
>> send a NOTIFY, you should be getting the onUpdate() callback
>> though. If it does not, you won't get the onUpdate() callback.
>>
>> Best regards,
>> Byron Campen
>>
>>> After solving that issue I am seeing another one. When I send a
>>> list subscription i expect to be notified when any one of those
>>> contacts on the list changes their presence state. What I notice
>>> is that I get a response/notify for the initial list subscription
>>> but do not get any when one of the contacts presence state
>>> changes. Should I be doing something additionally. I was under
>>> the impression that the OnUpdate() call back would get called as
>>> long as there was an active list subscription.
>>>
>>>
>>> Subbu
>>>
>>> Byron Campen <bcampen at estacado.net> wrote:
>>> I'm not seeing any code that discriminates based on the Content-
>>> Type that could be causing the behavior you're seeing. Can you
>>> post traces/logs? Looking at the code, this might be happening
>>> because of the absence of a Subscription-State header.
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>> Hi
>>>> I was wondering if anyone has experience with handling the
>>>> following content type:
>>>>
>>>> Content-Type:multipart/related;type="application/rlmi+xml";
>>>>
>>>> I have suceeded in sending SUBSCRIBE messages to
>>>> <resourcelistidetifier>@<presence server IP>
>>>>
>>>> I can see that the presence server is replying with a NOTIFY
>>>> which has the content type:
>>>> Content-Type:multipart/related;type="application/rlmi+xml";
>>>>
>>>>
>>>> I have updated incoming notifications to handle these types:
>>>>
>>>> clientDum.getMasterProfile()->addSupportedMimeType(NOTIFY,
>>>> Pidf::getStaticType());
>>>> clientDum.getMasterProfile()->addSupportedMimeType(NOTIFY,
>>>> Rlmi::getStaticType());
>>>> clientDum.getMasterProfile()->addSupportedMimeType(NOTIFY,
>>>> MultipartRelatedContents::getStaticType());
>>>> clientDum.getMasterProfile()->addSupportedMimeType
>>>> (NOTIFY,Mime("application", "simple-message-summary"));
>>>> clientDum.getMasterProfile()->addSupportedMimeType(NOTIFY,
>>>> Mime("application", "cpim-pidf+xml"));
>>>>
>>>>
>>>> But the onUpdateActive(ClientSubscriptionHandle is,const
>>>> SipMessage& notify, bool outOfOrder)
>>>> callback in the ClientSubscriptionHandler does not get called
>>>> when I recieve this NOTIFY message.
>>>>
>>>> Does someone know if I need to do anything else for this
>>>> callback to get called when I handle this content type.
>>>>
>>>> When I try sending a simple SUBSCRIBE to single user. I get
>>>> back a NOTIFY message of the type "application/pidf+xml". When
>>>> I recieve this type of NOTIFY the call back function
>>>> onUpdateActive gets successfully called.
>>>>
>>>> Help from anyone on this topic will be appreciated.
>>>>
>>>> Thank you
>>>> Subbu
>>>>
>>>> Park yourself in front of a world of choices in alternative
>>>> vehicles.
>>>> Visit the Yahoo! Auto Green Center.
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel at list.resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>>
>>>
>>> Shape Yahoo! in your own image. Join our Network Research Panel
>>> today!
>>
>>
>>
>> Be a better Heartthrob. Get better relationship answers from
>> someone who knows.
>> Yahoo! Answers - Check it out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070921/c1867a29/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070921/c1867a29/attachment.bin>
More information about the resiprocate-devel
mailing list