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

Saúl Ibarra Corretgé saul at ag-projects.com
Thu Nov 15 15:27:16 CET 2012


Hi,

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

> Hi Guys,
>  
> I hit another wall in here ( even though I have applied a workaround, but not sure to what extend it works ).
>  
> So the short story
>  
> 1.       IMS client logs in the SIP proxy ( IMS core )
> 2.       Whole world of notifications flies around and that’s fine
> 3.       Of course before the notifications there is the PUBLISH sent across which reaches the Presence server. The PUBLISH has in the XML part the following:
>  
> 

[snip]

>  
> The important tag here is the <pdm:person id=”USVMMSSM”>
>  
> 4.       As Expected IMS Core doesn’t have a problem with this string, as well the presence Server.
> 5.       As I have finally kind of a working subscription ( by manually Authorizing the XMPP guy in the Presence server, e.g. changing the status=1 ) the presence server sends NOTIFY against SYLK.
>  
> At this very moment SYLK would complain with the following error:
>  
> warning: [xmppgateway] Error parsing PIDF document: Element '{urn:ietf:params:xml:ns:pidf:data-model}person', attribute 'id': 'USVMMSSM' is not a valid value of the atomic type 'xs:ID'., line 35
>  
> 6.       The same would happen if the XMPP guy logs in and checks for presence towards Sylk -> Presence server
>  
> Now I have investigated the problem and digged upto the XML schemas in sipsimple, e.g. data-model.xml
>  
> The guilty one here is:
>  
>       <xs:attribute name="id" type="xs:ID" use="required"/>
>  
> Now I’m not sure if the above record for ID is really an invalid one, but it might well be.
>  
> There for I made a short test, e.g. change the:
>  
>       <xs:attribute name="id" type="xs:ID" use="required"/>
>  
> To
>  
>       <xs:attribute name="id" type="xs:string" use="required"/>  on both places in data-model.xml
>  
> In that case if the XMPP guy will login, the problem won’t appear, and I will get confirmation from Sylk that the XMPP guy is subscribed for Alice’s presence ( Alice the IMS user ) -> so far so good which means that the whole chain of communication is there, e.g. XMPP Server <-> Sylk <-> Presence Server and the notifications are correct
>  

We do validate XML schemas, that's what they are useful for :-) The lxml library takes care of the validation, and apparently that is not a valid xs:ID element. Our schemas are taken from the RFC, so if your documents don't validate against them, the endpoint must be doing something wrong.

>  
>  
> What else bothers me is the following scenario, where a presence server is used.
>  
> In case a presence server is used ( in case both IMS and XMPP guys have authorized each other’s already  and the XMPP GUY is already ONLINE, e.g. SUBSCRIBED for the IMS’s part for presence ) when the IMS client would login the following scenario is happening:
>  
> 1.       IMS client logs in – sends SUBSCRIBE only to the presence server ( where Netwrok Address Book is used )
> 2.       The subscribtion is accepted and everything looks fine, NOTIFY comes bad to the IMS client and so on.
> 3.       At this point the PRESENCE SERVER would generate a NOTIFY which will be routed from the IMS core towards the Sylk. The Notify would look the following way:
>  

[snip]


> 
>  
> 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, which of course won’t be sent from the IMS client if a network address book is used.
>  
> 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 ).
>  

Not sure if I'm following in this second case. SylkServer will translate NOTIFY payloads into stanzas if a subscription dialog exists. So, assuming there is a dialog between whomever and SylkServer and a NOTIFY is sent over it, SylkServer would translate it to XMPP. If SylkServer is unable to process the payload, however, no translation will be made. The payload you pasted can't be processed for 2 reasons:

a) USVMMSSM is not a valid xs:ID identifier.

b) It's repeated within the document. xs:ID elements must be unique across the document.

If you want to debug it further add debug statements in sylk/applications/xmppgateway/presence.py, where the NOTIFY payload is processed, but I can advance you that the one you pasted is not valid.


Regards,

--
Saúl Ibarra Corretgé
AG Projects





More information about the SIPBeyondVoIP mailing list