Ok, good comment. Yes indeed we have a SIP proxy between the subscriber and
opensips (which is only acting as presence server in this scenario).
I thought there were two problems (one at proxy and one at presence server
side). We will work on proxy side now to solve this issue.

Many thanks for your time.
Pascal


On Thu, Mar 11, 2010 at 4:22 PM, Anca Vamanu <a...@opensips.org> wrote:

> Hi Pascal,
>
> Only now I observed that there is a Route header in the Notify - so the
> first hop is in fact the address in the route and not the RURI. So it is
> correct to send the Notify on udp, and the proxy at the next hop should
> switch to tcp.
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
>
> Pascal Maugeri wrote:
> > Anca
> >
> > I got the following logs when subscribing:
> >
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:presence:build_dlg_t: CONTACT =
> >     sip:watc...@79.149.10.246:5060;transport=tcp
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]: DBG:tm:t_uac:
> >     next_hop=<sip:213.151.105.170:6666;lr=on>
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:core:mk_proxy: doing DNS lookup...
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:dlg2hash: 42964
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:print_request_uri: sip:watc...@79.149.10.246:5060
> ;transport=tcp
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:set_timer: relative timeout is 500000
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:insert_timer_unsafe: [4]: 0x7f8fa84c0068 (4508500000)
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:set_timer: relative timeout is 30
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:insert_timer_unsafe: [0]: 0x7f8fa84c0098 (4538)
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     INFO:presence:send_notify_request: NOTIFY
> >     sip:watc...@test.genaker.net <sip%3awatc...@test.genaker.net>
> >     
> > <mailto:sip%3awatc...@test.genaker.net<sip%253awatc...@test.genaker.net>>
> via
> >     sip:213.151.105.170:6666;lr=on on behalf of
> >     sip:present...@test.genaker.net <sip%3apresent...@test.genaker.net>
> >     
> > <mailto:sip%3apresent...@test.genaker.net<sip%253apresent...@test.genaker.net>>
> for event presence
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:tm:t_unref: UNREF_UNSAFE: after is 0
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:core:destroy_avp_list: destroying list (nil)
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3258]:
> >     DBG:core:receive_msg: cleaning up
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3259]:
> >     DBG:core:parse_msg: SIP Reply  (status):
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3259]:
> >     DBG:core:parse_msg:  version: <SIP/2.0>
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3259]:
> >     DBG:core:parse_msg:  status:  <200>
> >     Mar 11 15:28:40 test /usr/local/sbin/opensips[3259]:
> >     DBG:core:parse_msg:  reason:  <OK>
> >
> >
> > What log could I add to your patch so we can get more details ?
> >
> > I recompiled the whole opensips and its modules just to make sure your
> > patch is activated.
> >
> > Cheers
> > Pascal
> >
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to