[SIP Beyond VoIP] Another case where Sylk would reject Notifications

Hadzhiev, Tihomir tihomir.hadzhiev at acision.com
Thu Nov 15 18:45:11 CET 2012


Hi Adrian,

Applying the workaround with the IP addresses does not look that feasible, since I have to change a lot in the whole setup that I have currently. There for I will wait for the fix indeed.

Will try to focus on the RLS server, as if I have this one configured then the problem with the Subscribe might not be there... who knows.

Indeed the VIA headers are fine, e.g. with IP addresses, but the Record-Route does the bad job.

Thanks,
Tiho

From: Adrian Georgescu [mailto:ag at ag-projects.com]
Sent: 15 November 2012 17:12
To: Hadzhiev, Tihomir
Cc: sipbeyondvoip at lists.ag-projects.com
Subject: Re: [SIP Beyond VoIP] Another case where Sylk would reject Notifications


On Nov 15, 2012, at 4:20 PM, Hadzhiev, Tihomir wrote:


Hi Adrian,

Once the XMPP guy logs to the XMPP server a presence stanza is triggered towards Sylk ( with provbe ) and that's OK.  Sylk then generates SUBSCRIBE towards  SIP proxy which forwards it to the PRESENCE SERVER ( to subscribe for Event: PRESENCE for the SIP/IMS User ) - that's also OK.

Then there is a response OK 202 from presence server coming towards the Sylk.

Presence server then generates NOTIFY with even presence towards Sylk with subscription state: active  - I guess that's OK isn't it ?

Then XMPP server sends again the presence stanza request towards Sylk

Sylk replies with xmpp tanza -> subscribed.


So in the above message flow I see nothing wrong, am I right or I'm missing something ?


You are not missing anything.

As for the RLS server you are right, I'm using KAMAILIO as a presence server only. And yes, the resource-list is uploaded there by the SIP/IMS client ( that's Mercuro RCS client ) What I noticed is that if the RLS is used, Mercuro won't trigger a SUBSCRIBE towards users in the resource-list if the RLS ( Netwrok Address Book is used ) to store the contacts.

Mercuro must subscribe to the the SIP server in a way that causes the RLS server to initiate the subscriptions for all recipients expanded from the list.

I really need to look at the Kamailio RLS module, as I had till now the presence enabled with RLS.

If I switch the RLS in that case a SUBSCRIBE for the guy on the XMPP domain will arrive and this will immediately cause Sylk to crash ( that's again the problem reported yesterday with the resolvers - I believe Saul is looking at it ).

Our software should not crash for this reason but you can work around it until is fixed.

You should put IPs in the Via headers, and not hostnames that need to be looked-up within a dialog.

Adrian


Cheers,
Tiho


From: Adrian Georgescu [mailto:ag at ag-projects.com]
Sent: 15 November 2012 15:07
To: Hadzhiev, Tihomir
Cc: sipbeyondvoip at lists.ag-projects.com<mailto:sipbeyondvoip at lists.ag-projects.com>
Subject: Re: [SIP Beyond VoIP] Another case where Sylk would reject Notifications


On Nov 15, 2012, at 2:34 PM, Hadzhiev, Tihomir wrote:




4.       Sylk will accept the NOTIFY with 200 OK and will reply correctly towards IMS Core -> Presence Server.

Now the problem here is that SYLK won't generate a Presence Stanza towards the XMPP server. Looking at the web site's sequence diagram, Sylk would expect a Subscribe,

I think you are confused a bit here. SylkServer got the Notify from SIP as a result of his own Subscribe generated as a result of the XMPP subscription being active. The payload if parsed correctly will trigger an XMPP stanza update back to XMPP world. If this does not happen there should be some exception in the logs.


which of course won't be sent from the IMS client if a network address book is used.

I speculate that what you call a "network address book "is the Presence Agent RLS function that must expand the resource-list uploaded by the SIP client into URIs and subscribe to them.

This RLS server must send the Subscribe  in behalf of its own users and for those that end up in XMPP world must be routed to sylkServer. If it does not do this you must fix it.


So my question is, is there something that could be done in that case?  I can simulate the SUBSCRIBE of course, e.g. to have the IMS client sending SUBSCRIBE towards the XMPP domain, however I know this is not working ( the problem I have reported yesterday ).

Your IMS server (its RLS component) must generate the Subscriptions for each individual URI uploaded by the SIP client in the XCAP resource lists document.


Thanks,
Tiho

________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

_______________________________________________
SIPBeyondVoIP mailing list
SIPBeyondVoIP at lists.ag-projects.com<mailto:SIPBeyondVoIP at lists.ag-projects.com>
http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip


________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.


________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20121115/1dd827ca/attachment-0001.html>


More information about the SIPBeyondVoIP mailing list