[reSIProcate] RES: ClientSubscriptionHandler

Wed May 30 13:02:32 CDT 2007

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 at inovax.com.br

» Brazil, Rio de Janeiro

  _____  

De: Scott Godin [mailto:slgodin at icescape.com] 
Enviada em: sábado, 26 de maio de 2007 14:53
Para: Matthias Moetje; Gustavo Honorato; Ryan Kereliuk
Cc: resiprocate-devel at list.resiprocate.org
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 at terasens.com]
Sent: Fri 5/25/2007 5:41 PM
To: Scott Godin; Gustavo Honorato; Ryan Kereliuk
Cc: resiprocate-devel at list.resiprocate.org
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 

 cid:809010616 at 21122006-3519
<https://owa.computer-talk.com/exchange/slgodin/Drafts1/RE:%20%5breSIProcate
%5d%20ClientSubscriptionHandler.EML/1_multipart/image001.jpg> 

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

Phone:
Fax:
e-mail:
Web:

+49.89.143370-0
+49.89.143370-22
 <mailto:info at terasens.com> info at terasens.com
 <http://www.terasens.com/> www.terasens.com

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Freitag, 25. Mai 2007 18:29
To: Matthias Moetje; resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] ClientSubscriptionHandler

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
Matthias Moetje
Sent: Friday, May 25, 2007 11:56 AM
To: resiprocate-devel at list.resiprocate.org
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 

 cid:809010616 at 21122006-3519
<https://owa.computer-talk.com/exchange/slgodin/Drafts1/RE:%20%5breSIProcate
%5d%20ClientSubscriptionHandler.EML/1_multipart/image001.jpg> 

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

Phone:
Fax:
e-mail:
Web:

+49.89.143370-0
+49.89.143370-22
 <mailto:info at terasens.com> info at terasens.com
 <http://www.terasens.com/> www.terasens.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070530/fffa6e59/attachment.htm>