< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
Gustavo, thanks
for the hint! I
just wasn’t sure if I am allowed to delete the headerFieldValue and the SipFrag
immediately after ss->send. Unfortunately this method does not take shared
pointers. Best regards, Matthias Moetje
From: Gustavo Honorato
[mailto: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] 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] 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
From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias
Moetje 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
|