Thank you very much for quick answers, one more question though, I really need to get around this problem.
Is it possible to "translate" the buddy list into SIP and get the status/presence messages sent to the sip client in a notify message WITHOUT sending all these subscibe(´s).
Jabber send this big load of buddies to the Ser (see bellow in highlighted *2), who now just ignores them, but what if we split up all these buddies and send them in notify´s to the client.
Question: is it possible to send a lot of notify´s without sending "subscribe" to SER first.
Register from (msn)klient with icq transport
UAC
SER
Jabber
Register à
200 ok ß
200 acc ß
subscribe à
200 ok ß
Notify ß
200 ok à
start stream à
ok stream ß
get query auth à
result query auth ß
set query auth à
result ß
get query roster à
Notify ß
200 ok à
presence to b à
result query roster* ß
result query roster* ß
* I want these to get translated into SIP and sent further on to the client.
Register from (msn)client with icq transport
Serà Jab (start stream)
<stream:stream to='storstark.x.se' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams%27%3E
Jabàser (ok stream)
<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' id='3EC37D57' xmlns='jabber:client' from='storstark.x.se'>
seràJab (get query auth)
<iq id='00000000' type='get'><query xmlns='jabber:iq:auth'><username>a</username></query></iq>
Jabàser (result query auth)
<iq id='00000000' type='result'><query xmlns='jabber:iq:auth'><username>a</username><password/><digest/><resource/></query></iq>
seràJab (set query auth)
<iq id='00000001' type='set'><query xmlns='jabber:iq:auth'><username>a</username><resource>serXjab</resource><digest>cdca92ddc1414805e96e17ddb6a5900489d65467</digest></query></iq>
Jabàser (result)
<iq id='00000001' type='result'/>
seràJab (get query roster)
<iq type='get'><query xmlns='jabber:iq:roster'/></iq>
************************''
seràJab (presence to b)
<presence><status>Online</status><priority>9</priority></presence>
<presence to='u@storstark.x.se' type='subscribe'/>
*2)
Jabàser (result query roster)
<iq type='result' from='a@storstark.x.se/serXjab'><query xmlns='jabber:iq:roster'><item jid='32@icq.storstark.x.se' subscription='to' server='yes'/><item jid='16@icq.storstark.x.se' name='nbl@school' subscription='to' server='yes'><group>Contacts</group></item><item jid='20@icq.storstark.x.se' subscription='to' server='yes'/><item jid='41@icq.storstark.x.se' subscription='to' server='yes'/><item jid='17@icq.storstark.x.se' subscription='to' server='yes'/><item jid='15@icq.storstark.x.se' subscription='to' server='yes'/><item jid='92@icq.storstark.x.se' subscription='to' server='yes'/><item jid='66@icq.storstark.x.se' subscription='to' server='yes'/><item jid='10@icq.storstark.x.se' subscription='to' server='yes'/><item jid='u@storstark.x.se' name='u' subscription='both' server='yes'><group>Contacts</group></item><item jid='86@icq.storstark.x.se' subscription='to' server='yes'/><item jid='13@icq.storstark.x.se' subscription='to' server='yes'/><item jid='w@storstark.x.se' name='w' subscription='both' server='yes'><group>Contacts</group></item><item jid='24@icq.storstark.x.se' subscription='from' server='yes'/><item jid='51@icq.storstark.x.se' subscription='to' server='yes'/><item jid='icq.storstark.x.se/registered'
Jabàser (result query roster)
subscription='from' server='yes'/><item jid='11@icq.storstark.x.se' subscription='to' server='yes'/></query></iq>
Jabàser (presence from)
<presence from='u@storstark.x.se/TipicIM' to='a@storstark.x.se'><x xmlns='jabber:x:avatar'><hash>03d5f06d79b738d7f55aa03f054e6bc263f9f054</hash></x><priority>8</priority><x xmlns='jabber:x:delay' from='u@storstark.e-horizon.se/TipicIM' stamp='20030515T11:01:29'/><x xmlns='jabber:x:delay' from='u@storstark.x.se/TipicIM' stamp='20030515T11:01:29'/></presence>
***********************'
Jabàser (presence from)
<presence from='u@storstark.e-horizon.se/TipicIM' to='a@storstark.x.se'><x xmlns='jabber:x:avatar'><hash>03d5f06d79b738d7f55aa03f054e6bc263f9f054</hash></x><priority>8</priority><x xmlns='jabber:x:delay' from='u@storstark.e-x.se/TipicIM' stamp='20030515T11:01:29'/><x xmlns='jabber:x:delay' from='u@storstark.x.se/TipicIM' stamp='20030515T11:01:29'/></presence>
Jabàser (presence to)
<presence to='a@storstark.x.se' from='icq.storstark.e-horizon.se/registered'><status>Online</status><show>online</show></presence>
Jabàser (presence to)
<presence to='a@storstark.x.se' from='16@icq.storstark.e-horizon.se'/>
Anna, comments inline.
On 19-05 13:39, anna wrote:
Thank you very much for quick answers, one more question though, I really need to get around this problem.
Is it possible to "translate" the buddy list into SIP and get the status/presence messages sent to the sip client in a notify message WITHOUT sending all these subscibe(´s).
No, that is currently not possible. There is a draft on this topic, see draft-ietf-simple-event-list-00. It specifies how to send a single SUBSCRIBE for a collection of events.
But this is a very recent document and I haven't seen any user agent or server implementing it.
So it is not possible right now, it hasn't been standardized yet.
Jabber send this big load of buddies to the Ser (see bellow in highlighted *2), who now just ignores them, but what if we split up all these buddies and send them in notify´s to the client.
Question: is it possible to send a lot of notify´s without sending "subscribe" to SER first.
No, NOTIFY messages are sent by the server only if the user agent asked for it by sending a SUBSCRIBE to the server. What you propose is not feasible.
Why, actually, is the SUBSCRIBE a problem ?
Jan.
Hello, comments inline.
On 5/19/2003 1:39 PM, anna wrote:
Thank you very much for quick answers, one more question though, I really need to get around this problem.
Is it possible to translate the buddy list into SIP and get the status/presence messages sent to the sip client in a notify message WITHOUT sending all these subscibe(´s).
I am afraid it is not. The NOTIFY must be sent in the same dialog as the SUBSCRIBE.
Jabber send this big load of buddies to the Ser (see bellow in highlighted *2), who now just ignores them, but what if we split up all these buddies and send them in notify´s to the client.
Question: is it possible to send a lot of notify´s without sending subscribe to SER first.
The NOTIFYs are sent only when the SIP clients request that. Once the SIP client has no dialog to match a NOTIFY it will drop the message (sending back 481 Call/Transaction Does Not Exist). I have not tested with many SIP UACs, but for MSN Messenger is like that. You can tested by yourself, there is a tool 'udp_flood' which can send SIP messages from a file to a specific destination. You can find its sources in 'test' subdirectory -- to compile it just go in the directory and use 'gcc -o udp_flood udp_flood.c'. Giving -h option you are displayed a small help and you can find sample SIP messages in the same directory, too. Adapt one for your scenario and test to see if there is some SIP UA that accepts NOTIFYs outside a dialog.
Best regards, Daniel