[reSIProcate] ClientSubscriptionHandler

Matthias Moetje moetje at terasens.com
Fri May 25 16:41:46 CDT 2007


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 at terasens.com <mailto:info at terasens.com> 
www.terasens.com <http://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 



TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone:
Fax:
e-mail:
Web:

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070525/9579e273/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: image001.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070525/9579e273/attachment.jpg>


More information about the resiprocate-devel mailing list