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@gmail.com To: "Slava Bendersky" volga629@networklab.ca Cc: "sr-users" sr-users@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@gmail.com To: "Slava Bendersky" volga629@networklab.ca , "sr-users" sr-users@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@networklab.ca To: miconda@gmail.com Cc: "sr-users" sr-users@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@gmail.com To: "Slava Bendersky" volga629@networklab.ca Cc: "sr-users" sr-users@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@gmail.com To: "Slava Bendersky" volga629@networklab.ca , "sr-users" sr-users@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@networklab.ca To: miconda@gmail.com Cc: "sr-users" sr-users@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@gmail.com To: "Slava Bendersky" volga629@networklab.ca , "sr-users" sr-users@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@gmail.com To: "sr-users" sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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)
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
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?
On Monday, March 23, 2015 06:26:50 PM Alex Balashov wrote:
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?
Attached. -A
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.
On 23 Mar 2015, at 23:42, Alex Balashov abalashov@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
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"And the subsequent NOTIFY is correctly targeted to this RURI:
NOTIFYsip: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:
NOTIFYsip:172.16.4.7;line=sr-D8G7CE2.5PUeK-xuarl7NYDdNYDxNYlFUYoeUeQ8Cw.6DE2vDdyJD Aa4TliwC84O SIP/2.0
NOTIFYsip: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.
On Tuesday, March 24, 2015 04:08:16 PM Anthony Messina wrote:
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.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
NOTIFYsip: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.
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@example.com
So Kamailio can properly route the NOTIFYs.
-
Alex Balashov -
Anthony Messina -
Daniel-Constantin Mierla -
Olle E. Johansson -
Slava Bendersky