Re: [reSIProcate-users] Subscription is not automatically refreshed
Initial subscribe is sent to
sip:1001@xxxxxxxxxxxxx, the subscription refresh is trying to be sent to
sip:1002@xxxxxxxxxxxxx:5061.
192.168.1.108:5061 is the subscribers IP and port. This causes the re-subscribe to try to be routed to itself. This ends up failing because the OS instructs the stack to send to the loopback interface, and resip is not bound to this interface.
The problem is that the subscription server is returning the user's contact (
sip:1002@xxxxxxxxxxxxx:5061) as the servers Contact in the 202 (refer accepted), and notify messages, instead of a proper contact address for the server (
sip:1001@xxxxxxxxxxxxx).
One other note - you may want to avoid binding your UDP transport port to 5061, since port 5061 is the default TLS port and this may end up confusing some SIP endpoints.
Scott
On Tue, Mar 17, 2009 at 12:55 PM, Richard Stellingwerff
<remenic@xxxxxxxxx> wrote:
I have updated to SVN head, and attached a new debug.txt (zipped due to size).
At timestamp 20090317-174954.857, the same thing occurs.2009/3/17 Scott Godin
<sgodin@xxxxxxxxxxxxxxx>
The following line in the logs points to a problem. resiprocate can't route the subscription refresh for some reason.
INFO | 20090317-165815.712 | VoIP | RESIP:DUM | 2928 | ClientSubscription.cxx:433 | Refresh subscription: <sip:1002>
WARNING | 20090317-165815.759 | VoIP | RESIP:TRANSPORT | 2928 | TransportSelector.cxx:1179 | Can't find matching transport [ V4 127.0.0.1:0 UDP target domain=192.168.1.108 connectionId=0 ]
What version of resiprocate are you using? I noticed the line numbers from your log do not match SVN head. Perhaps this is a bug that has already been fixed. A DEBUG level resip trace, and the pcap trace would help to track this down further, if a code update doesn't help.
Scott
On Tue, Mar 17, 2009 at 12:00 PM, Richard Stellingwerff
<remenic@xxxxxxxxx> wrote:
Yes it sends a notify, and from debug.txt I can see that the timer is started. Yet the SUBSCRIBE message is never sent (it doesn't show up in wireshark). I have attached debug.txt.
Richard.
2009/3/17 Scott Godin
<sgodin@xxxxxxxxxxxxxxx>
DUM (ClientSubscription.cxx) starts the subscription refresh timer after receiving the first notify. Is the server you are testing with sending an initial notify immediately after subscribing?
Scott
Hi,
I am having some trouble with subscriptions. It seems that when the subscription timeout has passed, the callback ClientSubscriptionHandler::onTerminated(ClientSubscriptionHandle, const SipMessage& msg) is automatically called.
However, I would like the subscription to be refreshed when (or preferably before) the timout has passed.
I create the subscription like this:
_uacDum->send(_uacDum->makeSubscription(target, resip::Data("presence"), 60));
Is there something I'm not doing, or doing wrong in order to get dum to automatically refresh subscriptions?
Kind regards,
Richard Stellingwerff.
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/