23 Mar
2015
23 Mar
'15
5:43 p.m.
Hello Daniel,
Look like transactions are not match when it send reply for NOTIFY. I think it should
reuse connection.
Here SDP output where cseq are match and asterisk does retransmissions until time out.
Also I wonder where Path route is reused I see %* instead ; as delimiter between transport
and port.
Retransmitting #8 (NAT) to 10.18.130.46:5060:
NOTIFY sip:191@192.168.88.246:5062;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6939f20d;rport
Max-Forwards: 70
Route:
<sip:inbound@10.18.130.46;lr;received=sip:client_public_ip:5062%3Btransport%3Dtcp>
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To: <sip:191@192.168.88.246:5062;transport=tcp>
Contact: <sip:canlpbx02@10.18.130.51:5060>
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
User-Agent: FPBX-12.0.43(12.8.1)
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 89
Messages-Waiting: yes
Message-Account: sip:*97@10.18.130.51
Voice-Message: 24/0 (0/0)
---
Retransmitting #9 (NAT) to 10.18.130.46:5060:
NOTIFY sip:191@192.168.88.246:5062;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6939f20d;rport
Max-Forwards: 70
Route:
<sip:inbound@10.18.130.46;lr;received=sip:99.251.238.38:5062%3Btransport%3Dtcp>
right here
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To: <sip:191@192.168.88.246:5062;transport=tcp>
Contact: <sip:canlpbx02@10.18.130.51:5060>
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
User-Agent: FPBX-12.0.43(12.8.1)
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 89
Messages-Waiting: yes
Message-Account: sip:*97@10.18.130.51
Voice-Message: 24/0 (0/0)
---
<--- SIP read from UDP:10.18.130.46:5060 --->
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6939f20d;rport=5060;received=10.18.130.51
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To:
<sip:191@192.168.88.246:5062;transport=tcp>;tag=dc299d9ac16f3377ac0b8dfa22eaf0a6-2fe2
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
Server: kamailio (4.2.3 (x86_64/linux))
Content-Length: 0
<------------->
Mar 23 08:45:47 canlvprx01 /usr/sbin/kamailio[20143]: ERROR: <core>
[tcp_main.c:4338]: tcpconn_main_timeout(): connect client_pub_ip:5063 failed (timeout)
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "Slava Bendersky" <volga629(a)networklab.ca>
Cc: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Monday, March 23, 2015 4:21:47 AM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
as you can see the 408 is for another request, because the cseq is 103. The first one has
cseq 102, but has no Record-Route header, which is mandated by new RFCs.
In kamailio, if you added in request_route when handling the NOTIFY, you can try to add
record route via reply_route if the client is not keeping it in reply, kind of following
fix:
reply_route {
if(is_method("NOTIFY")) {
if(!is_present_hf("Record-Route")) {
insert_hf("Record-Route: < sip:yourserverip:port;transport=...\r\n ");
}
}
Cheers,
Daniel
On 22/03/15 18:11, Slava Bendersky wrote:
Hello Daniel,
I still can't understand clearly why when asterisk send NOTIFY to client through
kamailio it coming back with with 408. I
I tried different case event change Contact:, but no luck can't I see what the issue
all routes in first SUBSCRIBE looks ok .
Any though or help will be really appreciate.
This what I see on asterisk debug
Reliably Transmitting (NAT) to 10.18.130.46:5060:
NOTIFY sip:102@192.168.88.243:5068;alias=client_pub_ip~5068~2 SIP/2.0
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK5dd3f266
Max-Forwards: 70
Route: <sip:10.18.130.46:5060;lr=on;ftag=3b27a2a409;nat=yes> --->Kamailio route
From: "canlpbx02" <sip:canlpbx02@10.18.130.51> ;tag=as56402f92
To: <sip:102@192.168.88.243:5068;alias=client_pub_ip~5068~2> ;tag=3b27a2a409
Contact: <sip:canlpbx02@10.18.130.51:5060>
Call-ID: b1edde040d695988
CSeq: 102 NOTIFY
User-Agent: FPBX-12.0.43(12.8.1)
Event: message-summary
Content-Type: application/simple-message-summary
Subscription-State: active
Content-Length: 88
Messages-Waiting: yes
Message-Account: sip:*97@10.18.130.51
Voice-Message: 5/0 (0/0)
---
<--- SIP read from UDP:10.18.130.46:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.18.130.51:5060;rport=5060;branch=z9hG4bK5dd3f266
From: "canlpbx02" <sip:canlpbx02@10.18.130.51> ;tag=as56402f92
To: <sip:102@192.168.88.243:5068;alias=client_pub_ip~5068~2> ;tag=3b27a2a409
Call-ID: b1edde040d695988
CSeq: 102 NOTIFY
Allow: ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, REFER, SUBSCRIBE, UPDATE
Server: Media5-fone/4.1.6.3283 Android/5.1
Supported: eventlist, replaces, timer
Content-Length: 0
<------------->
--- (10 headers 0 lines) ---
<--- SIP read from UDP:10.18.130.46:5060 --->
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6386387f;rport=5060
From: "canlpbx02" <sip:canlpbx02@10.18.130.51> ;tag=as00936a6d
To: <sip:102@192.168.88.243:5066;alias=client_pub_ip~5066~2> ;tag=a3aea18741
Call-ID: 5a66b87a618d1042
CSeq: 103 NOTIFY
Server: kamailio (4.2.3 (x86_64/linux))
Content-Length: 0
<------------->
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users"
<sr-users(a)lists.sip-router.org>
Sent: Friday, March 13, 2015 1:28:33 PM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
that function might be in textopsx module.
Cheers,
Daniel
On 13/03/15 14:25, Slava Bendersky wrote:
BQ_BEGIN
Hello Daniel,
Where possible find updated version of options for textops.
[sr_module.c:701]: find_mod_export_record(): find_export_record: <remove_hf_value>
not found
Specially Record-Route manipulation.
Slava.
From: "Slava Bendersky" <volga629(a)networklab.ca>
To: miconda(a)gmail.com
Cc: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Friday, March 13, 2015 8:54:26 AM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello Daniel,
Here paste for first SUBSCRIBE.
http://fpaste.org/197545/25118514/
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "Slava Bendersky" <volga629(a)networklab.ca>
Cc: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Thursday, March 12, 2015 5:09:17 AM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
can you get the sip traffic from the network (from the first subscribe of this presence
dialog)? It will help to see the Route set.
Cheers,
Daniel
On 12/03/15 00:36, Slava Bendersky wrote:
BQ_BEGIN
Hello Daniel,
Here debug of the notify which failing. Look like transaction miss match
http://fpaste.org/196896/61168591/
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users"
<sr-users(a)lists.sip-router.org>
Sent: Wednesday, March 11, 2015 5:44:05 PM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
it doesn't matter if there is a mix of transports. If the UA is mirroring the
Record-Route headers in the response to the NOTIFY, it should work fine.
Cheers,
Daniel
On 11/03/15 21:40, Slava Bendersky wrote:
BQ_BEGIN
Hello Daniel,
Is this matter that UDP and TCP transport in mix ?
Slava.
From: "Slava Bendersky" <volga629(a)networklab.ca>
To: miconda(a)gmail.com
Cc: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Wednesday, March 11, 2015 4:21:39 PM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello Daniel,
I have record route in WITHINDLG for NOTIFY, but it not helped behaviour is the same it
loosing route for NOTIFY.
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "Slava Bendersky" <volga629(a)networklab.ca> , "sr-users"
<sr-users(a)lists.sip-router.org>
Sent: Wednesday, March 11, 2015 2:14:02 PM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
you have to do record_route() for all NOTIFY requests -- there are new specs requiring
that (RFC 6665) and perhaps asterisk is following them.
If you look in the default kamailio.cfg for v4.2, inside route[WITHINDLG], then you will
see how it is done.
Cheers,
Daniel
On 11/03/15 14:22, Slava Bendersky wrote:
BQ_BEGIN
Hello Daniel,
Here fresh paste
http://fpaste.org/196616/42608006/
I see proper routing headers on SUBSCRIBE, but then NOTIFY loose it.
Slava.
From: "Daniel-Constantin Mierla" <miconda(a)gmail.com>
To: "sr-users" <sr-users(a)lists.sip-router.org>
Sent: Tuesday, March 10, 2015 5:31:51 PM
Subject: Re: [SR-Users] kamailio asterisk NOTIFY
Hello,
fpaste link doesn't show anything.
Can you check if the NOTIFY coming to Kamailio has two Route headers?
Cheers,
Daniel
On 10/03/15 18:44, Slava Bendersky wrote:
BQ_BEGIN
Hello Everyone,
Having issue with NOTIFY, is not forwarded to client properly.
asterisk ---> private kamailio public ----> soft client
http://fpaste.org/196257/99948714/
I see kamailio trying connect always with private IP to the client when NOTIFY is come is
in. Is this something to do with
rr_advertise_address ?
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) ERROR: <core> [tcp_main.c:4338]:
tcpconn_main_timeout(): connect 192.168.88.246:5064 failed (timeout)
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) DEBUG: <core> [tcp_main.c:4362]:
tcpconn_main_timeout(): tcp_main: timeout for 0x7fbbb64e2800
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) DEBUG: <core> [io_wait.h:610]:
io_watch_del(): DBG: io_watch_del (0x9dbf00, 33, -1, 0x10) fd_no=24 called
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) DEBUG: <core> [tcp_main.c:4320]:
tcpconn_main_timeout(): tcp_main: entering timer for 0x7fbbb64eb6c0 (ticks=839577436,
timeout=839634956 (3595 s), wr_timeout=839577436 (0 s)), write queue: 798 bytes
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) ERROR: <core> [tcp_main.c:4338]:
tcpconn_main_timeout(): connect 192.168.88.246:5066 failed (timeout)
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) DEBUG: <core> [tcp_main.c:4362]:
tcpconn_main_timeout(): tcp_main: timeout for 0x7fbbb64eb6c0
Mar 10 13:44:23 canlvprx01 kamailio: 16(24971) DEBUG: <core> [io_wait.h:610]:
io_watch_del(): DBG: io_watch_del (0x9dbf00, 34, -1, 0x10) fd_no=23 called
Mar 10 13:44:42 canlvprx01 kamailio: 5(24960) DEBUG: tm [t_reply.c:1294]:
t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408
Mar 10 13:44:42 canlvprx01 kamailio: 5(24960) DEBUG: tm [t_reply.c:1812]: relay_reply():
DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0
Mar 10 13:44:42 canlvprx01 kamailio: 5(24960) DEBUG: <core> [mem/shm_mem.c:111]:
_shm_resize(): WARNING:vqm_resize: resize(0) called
Mar 10 13:44:42 canlvprx01 kamailio: 5(24960) DEBUG: tm [t_reply.c:1294]:
t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408
Mar 10 13:44:42 canlvprx01 kamailio: 5(24960) DEBUG: tm [t_reply.c:1812]: relay_reply():
DEBUG: relay_reply: branch=0, save=0, relay=0 icode=0
I have in configuration in WITHINDLG
if (is_method("NOTIFY")) {
record_route();
}
and in NATDETECT
if(is_method("INVITE|SUBSCRIBE|UPDATE|NOTIFY")) {
set_contact_alias();
}
Slava.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
BQ_END
--
Daniel-Constantin Mierla http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
24 Mar
24 Mar
3:18 a.m.
New subject: kamailio asterisk NOTIFY
Hello,
not sure you mean transaction as used inside kamailio (tm module), but a
SIP transaction doesn't have anything to do with routing. Kamailio will
be able to route requests/replies even when not creating transactions
(i.e., when it is stateless forwarding).
It looks like you get the sip packets from the asterisk box. Use ngrep
on kamailio server to see what happens there, like:
ngrep -d any -qt -W byline port 5060 or port 5062
You will see if the packets get to kamailio and if they are attempted to
be sent further.
Cheers,
Daniel
On 23/03/15 13:43, Slava Bendersky wrote:
Hello Daniel,
Look like transactions are not match when it send reply for NOTIFY. I
think it should reuse connection.
Here SDP output where cseq are match and asterisk does retransmissions
until time out.
Also I wonder where Path route is reused I see %* instead ; as
delimiter between transport and port.
Retransmitting #8 (NAT) to 10.18.130.46:5060:
NOTIFY sip:191@192.168.88.246:5062;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6939f20d;rport
Max-Forwards: 70
Route:
<sip:inbound@10.18.130.46;lr;received=sip:client_public_ip:5062%3Btransport%3Dtcp>
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To: <sip:191@192.168.88.246:5062;transport=tcp>
Contact: <sip:canlpbx02@10.18.130.51:5060>
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
User-Agent: FPBX-12.0.43(12.8.1)
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 89
Messages-Waiting: yes
Message-Account: sip:*97@10.18.130.51
Voice-Message: 24/0 (0/0)
---
Retransmitting #9 (NAT) to 10.18.130.46:5060:
NOTIFY sip:191@192.168.88.246:5062;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 10.18.130.51:5060;branch=z9hG4bK6939f20d;rport
Max-Forwards: 70
Route:
<sip:inbound@10.18.130.46;lr;received=sip:99.251.238.38:5062%3Btransport%3Dtcp>
right here
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To: <sip:191@192.168.88.246:5062;transport=tcp>
Contact: <sip:canlpbx02@10.18.130.51:5060>
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
User-Agent: FPBX-12.0.43(12.8.1)
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 89
Messages-Waiting: yes
Message-Account: sip:*97@10.18.130.51
Voice-Message: 24/0 (0/0)
---
<--- SIP read from UDP:10.18.130.46:5060 --->
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP
10.18.130.51:5060;branch=z9hG4bK6939f20d;rport=5060;received=10.18.130.51
From: "canlpbx02" <sip:canlpbx02@10.18.130.51>;tag=as4b212049
To:
<sip:191@192.168.88.246:5062;transport=tcp>;tag=dc299d9ac16f3377ac0b8dfa22eaf0a6-2fe2
Call-ID: 14c7c8cc7335adf60f2be634132d3b2f@10.18.130.51:5060
CSeq: 102 NOTIFY
Server: kamailio (4.2.3 (x86_64/linux))
Content-Length: 0
<------------->
Mar 23 08:45:47 canlvprx01 /usr/sbin/kamailio[20143]: ERROR: <core>
[tcp_main.c:4338]: tcpconn_main_timeout(): connect client_pub_ip:5063
failed (timeout)
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
3:24 a.m.
New subject: kamailio asterisk NOTIFY
On Monday, March 23, 2015 11:18:01 PM Daniel-Constantin Mierla wrote:
Hello,
not sure you mean transaction as used inside kamailio (tm module), but a SIP
transaction doesn't have anything to do with routing. Kamailio will be able
to route requests/replies even when not creating transactions (i.e., when
it is stateless forwarding).
It looks like you get the sip packets from the asterisk box. Use ngrep on
kamailio server to see what happens there, like:
ngrep -d any -qt -W byline port 5060 or port 5062
You will see if the packets get to kamailio and if they are attempted to be
sent further.
Cheers,
Daniel
This may or may not be related, but I am also having issues with NOTIFY for
MWI from Asterisk.
In my case I am using the TOPOH module and it appears Asterisk may be
truncating the Request-URI on NOTIFYs *after* the 1st one. Where the 1st one
is if a user gets NOTIFY immediately upon the first SUBSCRIBE, such as when
there is already a VM in their mailbox.
https://issues.asterisk.org/jira/browse/ASTERISK-24877
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
3:26 a.m.
New subject: kamailio asterisk NOTIFY
Hello Anthony,
On 03/23/2015 06:24 PM, Anthony Messina wrote:
In my case I am using the TOPOH module and it appears
Asterisk may be
truncating the Request-URI on NOTIFYs*after* the 1st one. Where the 1st one
is if a user gets NOTIFY immediately upon the first SUBSCRIBE, such as when
there is already a VM in their mailbox.
Can you provide a capture to this effect?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
3:34 a.m.
New subject: kamailio asterisk NOTIFY
On Monday, March 23, 2015 06:26:50 PM Alex Balashov wrote:
Hello Anthony,
On 03/23/2015 06:24 PM, Anthony Messina wrote:
Attached. -A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
In my case I am using the TOPOH module and it
appears Asterisk may be
truncating the Request-URI on NOTIFYs*after* the 1st one. Where the 1st
one is if a user gets NOTIFY immediately upon the first SUBSCRIBE, such
as when there is already a VM in their mailbox.
Can you provide a capture to this effect?
3:42 a.m.
New subject: kamailio asterisk NOTIFY
Anthony,
The Contact presented by the subscriber in the initial subscription is:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme>;+sip.ice
And the subsequent NOTIFY is correctly targeted to this RURI:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme
SIP/2.0
The subscriber returns this Contact in the 200 OK response for the NOTIFY:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O>;+sip.ice
And subsequent NOTIFYs appear to use this RURI instead of the original
Contact of the subscriber:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O
SIP/2.0
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O
SIP/2.0
etc.
A SUBSCRIBE is a dialog-creating event, so in-dialog messages (e.g.
NOTIFYs) should be targeted at a Request URI corresponding to the
Contact URI of the SUBSCRIBE-er. It seems to me that this is the problem
here, rather than truncation.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
12:28 p.m.
New subject: kamailio asterisk NOTIFY
On 23 Mar 2015, at 23:42, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Anthony,
The Contact presented by the subscriber in the initial subscription is:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme>;+sip.ice
And the subsequent NOTIFY is correctly targeted to this RURI:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme
SIP/2.0
The subscriber returns this Contact in the 200 OK response for the NOTIFY:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O>;+sip.ice
And subsequent NOTIFYs appear to use this RURI instead of the original Contact of the
subscriber:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O
SIP/2.0
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJDAa4TliwC84O
SIP/2.0
etc.
A SUBSCRIBE is a dialog-creating event, so in-dialog messages (e.g. NOTIFYs) should be
targeted at a Request URI corresponding to the Contact URI of the SUBSCRIBE-er. It seems
to me that this is the problem here, rather than truncation.
I think that changed recently. The NOTIFY is a dialog-creating event, since a
SUBSCRIBE can fork to many destinations.
/O
25 Mar
25 Mar
2:08 a.m.
New subject: kamailio asterisk NOTIFY
On Monday, March 23, 2015 06:42:59 PM Alex Balashov wrote:
Anthony,
The Contact presented by the subscriber in the initial subscription is:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJ
DAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme>;+sip.ice
And the subsequent NOTIFY is correctly targeted to this RURI:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJD
Aa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme SIP/2.0
The subscriber returns this Contact in the 200 OK response for the NOTIFY:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJ
DAa4TliwC84O>;+sip.ice
And subsequent NOTIFYs appear to use this RURI instead of the original
Contact of the subscriber:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJD
Aa4TliwC84O SIP/2.0
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJD
Aa4TliwC84O SIP/2.0
etc.
A SUBSCRIBE is a dialog-creating event, so in-dialog messages (e.g.
NOTIFYs) should be targeted at a Request URI corresponding to the
Contact URI of the SUBSCRIBE-er. It seems to me that this is the problem
here, rather than truncation.
Alex, good catch! I see that now. I was too focused on the request URI. My
trouble in tracking the real source of this issue was that both the client
SUBSCRIBE-er (CSipSimple) and Asterisk (13.2.0) are using PJSIP. It does
appear that CSipSimple may be truncating the contact in the 200 OK response to
the first NOTIFY (though that may not be the real issue).
I'll need to dig into the TOPOH hiding of the contact header.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
2:19 a.m.
New subject: kamailio asterisk NOTIFY
On Tuesday, March 24, 2015 04:08:16 PM Anthony Messina wrote:
On Monday, March 23, 2015 06:42:59 PM Alex Balashov
wrote:
And if it helps to know my "learning Kamalio journey," I started out with [1]
and am slowly working my way toward maximizing Kamailio and minimizing
Asterisk where users register, etc. in Kamailio and Asterisk is used only as
an application server for voicemail, conferences, DAHDI/PSTN integration, etc.
[1] http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
I guess I need to find a way for the Kamailio user to end up as the Contact
header:
m: "Test User" <tuser(a)example.com>
So Kamailio can properly route the NOTIFYs.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
Anthony,
The Contact presented by the subscriber in the initial subscription is:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDd
yJ DAa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme>;+sip.ice
And the subsequent NOTIFY is correctly targeted to this RURI:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdy
JD Aa4TliwC84OC82LK-2ehwl7NYDdNYDxNYlFUAm6UYzm0gme SIP/2.0
The subscriber returns this Contact in the 200 OK response for the NOTIFY:
m: "Test User"
<sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDd
yJ DAa4TliwC84O>;+sip.ice
And subsequent NOTIFYs appear to use this RURI instead of the original
Contact of the subscriber:
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdy
JD Aa4TliwC84O SIP/2.0
NOTIFY
sip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdy
JD Aa4TliwC84O SIP/2.0
etc.
A SUBSCRIBE is a dialog-creating event, so in-dialog messages (e.g.
NOTIFYs) should be targeted at a Request URI corresponding to the
Contact URI of the SUBSCRIBE-er. It seems to me that this is the problem
here, rather than truncation.
Alex, good catch! I see that now. I was too focused on the request URI.
My trouble in tracking the real source of this issue was that both the
client SUBSCRIBE-er (CSipSimple) and Asterisk (13.2.0) are using PJSIP. It
does appear that CSipSimple may be truncating the contact in the 200 OK
response to the first NOTIFY (though that may not be the real issue).
I'll need to dig into the TOPOH hiding of the contact header.
3341
days inactive
3342
days old
8 comments
5 participants
participants (5)
-
Alex Balashov -
Anthony Messina -
Daniel-Constantin Mierla -
Olle E. Johansson -
Slava Bendersky