Hi, your solution is possible - separated presence server from other SIP communication. For forwarding you need cfg like this:

if (method=="...") { # here put method name which should be forwarded if (!t_newtran()) { log(1, "newtran error\n"); sl_reply_error(); break; }; if (!t_forward_nonack("machine.domain.com", 5060)) { log(1, "forward failed\n"); t_reply("500", "Forward failed"); } break; }

I'm using SER as proxy and other SER as presence server. Proxy forwards presence related messages to presence server, it looks like:

route { # XML RPC if (method == "POST" || method == "GET") { create_via(); dispatch_rpc(); break; }

# initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route();

# subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (uri==myself) { if (method=="REGISTER") { if (!www_authenticate("test-domain.com", "credentials")) { www_challenge("test-domain.com", "0"); break; }; save("location"); break; }; # ... process other messages here ...

if ((method=="SUBSCRIBE") || (method=="PUBLISH")) { log(1, "Forwarding request\n"); if (!t_newtran()) { log(1, "newtran error\n"); sl_reply_error(); break; }; if (!t_forward_nonack("presence-server.mydomain.com", "5060")) { log(1, "Forward to PS failed\n"); t_reply("500", "Forward failed"); } break; };

# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; } route(1); }

route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }

On Tue, Mar 28, 2006 at 11:13:05AM +0300, ?lker Aktuna (Koç.net) wrote:

Hi,

I already have a SIP proxy which handles SIP registers and acts as RTP proxy. But that one does not handle presence messages as SUBSCRIBE and PUBLISH. Is it possible to use Ser together with my Sip proxy ?

What I mean:

• SIP clients will send all messages to SER.
• SER will forward SIP messages like REGISTER, INVITE, NOTIFY to my SIP proxy with no modification to the message.
• SER will also handle SIP messages related to presence and resource lists.

Is this possible ? What kind of configuration is needed ?

Thanks, ilker

http://387555.sigclick.mailinfo.com/sigclick/040A0404/02044D00/024E0117231711.jpg _____________________________________________________________________________________________________________________________________________ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _____________________________________________________________________________________________________________________________________________

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers