24 Mar
2015
24 Mar
'15
11:19 p.m.
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.