Great!
Daniel
On 05/08/15 18:31, M S wrote:
> yes, using set_contact_alias() fixed the problem.
>
> Many thanks and kind regards.
>
>
>
> On Wed, Aug 5, 2015 at 4:18 PM, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> Use set_contact_alias()/handle_uri_alias() instead of
>
yes, using set_contact_alias() fixed the problem.
Many thanks and kind regards.
On Wed, Aug 5, 2015 at 4:18 PM, Daniel-Constantin Mierla
wrote:
> Use set_contact_alias()/handle_uri_alias() instead of fix_nated_contact().
>
> Cheers,
> Daniel
>
>
> On 03/08/15 13:49, M S wrote:
>
> Ah OK, i se
Use set_contact_alias()/handle_uri_alias() instead of fix_nated_contact().
Cheers,
Daniel
On 03/08/15 13:49, M S wrote:
> Ah OK, i see the issue now. The contact is "sip:@",
> which is changed by NATHelper to "sip:@".
> Since user is a webrtc end-point so it can never send me correct
> contact he
Ah OK, i see the issue now. The contact is "sip:@", which
is changed by NATHelper to "sip:@". Since user
is a webrtc end-point so it can never send me correct contact header,
therefore i have to tweak things in NATMANAGE route. Is that correct, or
is there anything else possible?
Thank you.
On
Look at the trace when the SUBSCRIBE is handled, because the R-URI in
NOTIFY is the Contact from SUBSCRIBE.
Cheers,
Daniel
On 03/08/15 12:51, M S wrote:
> Yes in sip trace i do see notify being sent using udp transport rather
> then tls.
>
> --
> U 2015/08/03 10:30:53.213962 X.X.X.X:5060 -> Y.Y.Y
Yes in sip trace i do see notify being sent using udp transport rather then
tls.
--
U 2015/08/03 10:30:53.213962 X.X.X.X:5060 -> Y.Y.Y.Y:57526
NOTIFY sip:1234567890@Y.Y.Y.Y:57526 SIP/2.0
...
--
I also notice that R-URI domain part is destination user's IP, instead of
his/her domain, which i am af
Hello,
can you look at SIP trace and see what is the Contact address of the
subscription? You can use ngrep to sniff on port 5060 (for tcp) on
kamailio server.
Also, are you using and routing enforcement for NOTIFY (e.g., you have a
chain of proxies or use event_route[tm:local-request] with force