[asterisk-dev] SIP presence XML namespaces

Klaus Darilion klaus.mailinglists at pernau.at
Wed May 26 04:54:33 CDT 2010


Hi Olle!

Am 23.05.2010 11:17, schrieb Olle E. Johansson:
>
> 21 maj 2010 kl. 14.24 skrev Klaus Darilion:
>
>> Hi!
>>
>> I analyzed the XML documents sent by Asterisk (trunk) when "presence" is
>> subscribed:
>>
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <presence xmlns="urn:ietf:params:xml:ns:pidf"
>> xmlns:pp="urn:ietf:params:xml:ns:pidf:person"
>> xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status"
>> xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person"
>> entity="sip:klaus2 at 83.136.32.165">
>> <pp:person>
>> 	<status>
>> 		<ep:activities><ep:busy/></ep:activities>
>> 	</status>
>> </pp:person>y
>> <note>On the phone</note>
>> <tuple id="362">
>> 	<contact priority="1">sip:362 at 83.136.32.165</contact>
>> 	<status><basic>open</basic></status>
>> </tuple>
>> </presence>
>>
>>
>> I wonder where these namespaces come from? I can not find [1] any
>> standards describing
> As the code suggests, from early drafts and the early EyeBeam implementation. As usual, we just made it work. Does the current code break anything?

At least not with Eyebeam. I havn't tested other clients.

>>
>> xmlns:pp="urn:ietf:params:xml:ns:pidf:person"
>> xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" [2]
>> xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person"
>>
>> Maybe these namespaces are based on old drafts?
>>
>> The source code mentions:
>>    case PIDF_XML: /* Eyebeam supports this format */
>>
>> But also eyebeam uses other namespaces (the IETF defined ones), e.g:
>> <presence xmlns='urn:ietf:params:xml:ns:pidf'
>>   xmlns:dm      ='urn:ietf:params:xml:ns:pidf:data-model'
>>   xmlns:rpid    ='urn:ietf:params:xml:ns:pidf:rpid'
>>   xmlns:c       ='urn:ietf:params:xml:ns:pidf:cipid'
>>   xmlns:lt      ='urn:ietf:params:xml:ns:location-type'
>>
>> I think we should aligne this to the standardized namespaces.
>
> While maintaining backwards compatibility.
> The question here is if we break anything by changing...

I do not know - any SIMPLE experiences from your SIPit participation?

> So what's your detailed suggestion?

We could make it an option (not much to code - one if-else), maybe even 
on a per-peer basis, so we can support strict RFC conform and 
old-eyebeam-style-compatible clients.

regards
Klaus




More information about the asterisk-dev mailing list