Re: [reSIProcate] Help on SUBSCRIBE behaviour in TCP
It looks like somewhere in ClientSubscription.cxx, somebody is
checking the value of h_SubscriptionState without first checking to
see if it exists. This should be easy to find/fix.
Note that upon receipt of the 503, the subscription will be terminated
and it would not be correct behavior for dum to attempt to retry the
subscription. You will have to implement this behavior above dum in
the application.
Jason
On 6/14/06, parimala.gopalakrishna@xxxxxxxxx
<parimala.gopalakrishna@xxxxxxxxx> wrote:
Hi,
I am using SUBSCRIBE-NOTIFY mechanism in my module.
I am using Resiprocate Stack.
I am writing an application as a Subscriber and initiating a Subscription.
I have derived from ClientSubscriptionHandler and defined the callbacks.
Scenario:
When I am running Subscriber in TCP mode an when Notifier is not running:
Subscriber tries to open a socket for TCP connection and fails as Notifier
is not running.
But here 503 Service Unavailable response is received and an exception is
caught telling: "Subscription-State" Header is missing in the Response.
I have attached the log file:TCP_log.txt, please have a look at it.
Subscription State Header is not mandatory in the Error Responses.
The match is done based on CallId, From tag and CSeq No. according to
RFC3265
Why is it throwing the Exception?
--------------
My purpose is: The Subscriber should keep on trying to send SUBSCRIBE till
the Notifier comes up or starts listening.
Should I run a new timer in my application or can I reuse from the stack.
Can someone explain the purpose of onRequestRetry() callback?
How should I proceed?
Please reply.
Regards,
Parimala
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel