[reSIProcate] RES: ClientSubscriptionHandler

["Gustavo Honorato" <gustavo@xxxxxxxxxxxxx>]

Matthias,

 

Check if you must delete SipFrag pointer at the end of this operation. I think that you’re leaking memory.

 

Gustavo de Sá Carvalho Honorato

» Software Developer

» INOVAX Engenharia de Sistemas

» Contact: +55 21 81264643

» E-mail: gustavo@xxxxxxxxxxxxx

» Brazil, Rio de Janeiro

 

 

 

---

De: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Enviada em: sábado, 26 de maio de 2007 14:53
Para: Matthias Moetje; Gustavo Honorato; Ryan Kereliuk
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Assunto: RE: [reSIProcate] ClientSubscriptionHandler

 

Yes you are right - I just checked the code again - the NOTIFY that causes the subscription to end does not generate an onUpdateXXX calback, just an onTerminated callback.  I don't see any problems with what you are doing.

 

Scott

 

---

From: Matthias Moetje [mailto:moetje@xxxxxxxxxxxx]
Sent: Fri 5/25/2007 5:41 PM
To: Scott Godin; Gustavo Honorato; Ryan Kereliuk
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] ClientSubscriptionHandler

Scott, Gustavo and Ryan,

 

thanks very much for the information, this helped me a lot!

 

On the server side I am doing in onRefer(resip::InviteSessionHandle h, …

 

      ss->send(ss->accept(202));

 

      resip::Data daNotify("SIP/2.0 200 OK");

     

      Mime type("message", "sipfrag");

      HeaderFieldValue* hfv = new headerFieldValue(daNotify.c_str(),daNotify.size());

      SipFrag* frag = new SipFrag(hfv,type);

 

      ss->end(NoResource,frag);

 

I am not sure if this is right. Though our background is as follows: At the moment a refer is always successful because in case of an unavailable party or invalid number the PBX will fallback the refered call to another extension. Therefore we send the sipfrag with 200 OK immediately. This is passed via ss->end(…)

 

Is that correct? After reading the RFC I had the impression that the final response always ends the refer subscription. This does not trigger any onUpdatexxx callback on the client but only onTerminated, so I thought investigating the msg in the onTerminated would be sufficient to deal with the refer response…?

 

Thanks again,

 

Matthias Moetje

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone: Fax: e-mail: Web:

+49.89.143370-0 +49.89.143370-22 info@xxxxxxxxxxxx www.terasens.com

 

 

 

 

From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Freitag, 25. Mai 2007 18:29
To: Matthias Moetje; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] ClientSubscriptionHandler

 

 

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje
Sent: Friday, May 25, 2007 11:56 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] ClientSubscriptionHandler

 

Hi,

 

could someone please shed some light on the callback functions of the ClientSubscriptionHandler? Some are easy to understand but when are:

 

onUpdatePending, onUpdateActive and onUpdateExtension actually called?

[Scott] One of these are called when a notify is received.  The one that is called depends on the current subscription state.  I think Extension is used when the state is neither Pending or Active.  I don’t fully understand why these callbacks were separated this way, perhaps someone else can shed some light on that.

 

What should I return in onRequestRetry (should I return the retrySeconds value)?

[Scott] I would suggest returning some the min of retrySeconds and some application configured setting for subscription retry.

 

Am I correct that for dealing with a ClientSubscription which was implicitly created through REFER, it is sufficient to wait for ClientSubscriptionHandler::onTerminated, then create a SIP message from the sipfrag and use this message’s response code to determine if the REFER was successful or not?

[Scott] You can look for a SIP final response code (non-1xx) in the SipFrag bodies of the onUpdateXXX callbacks and checking for 2xx vs 3xx-6xx to determine success or failure.  However the subscription should be ended on the final response, so an onTerminated callback should immediately follow.

 

 

Thanks for any help,

 

Matthias Moetje

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone: Fax: e-mail: Web:

+49.89.143370-0 +49.89.143370-22 info@xxxxxxxxxxxx www.terasens.com