reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
  Thread Index  

[reSIProcate] Fwd: Handling NOTIFY with Content type: Mulipart/related; type = "application/rlmi+xml"

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@xxxxxxxxxxxx>
Date: September 21, 2007 2:47:13 PM CDT
To: Subramanian Kasi Subramanian <subbu.subramanian@xxxxxxxxx>
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@xxxxxxxxxxxx>
To: Subramanian Kasi Subramanian <subbu.subramanian@xxxxxxxxx>
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@xxxxxxxxxxxx> 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



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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature