31 Mar
2006
31 Mar
'06
10:37 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers