Hello,
On Fri, 5 May 2006, Pekka Pessi wrote:
My idea was to re-use the usename and password used in REGISTER
request. While the keepalive OPTTIONS is just a hack, I think STUN
with rfc3489bis uses digest authenticatio, too. Now the problem is
that there is no single nua event which application could use to
prompt authentication from user.
ok. The STUN msg authentication seems to be an open issue in the outbound
specs (in the case the messages are interleaved with SIP traffic), but
yeps, it might be needed.
REGISTER is challenged with a certain realm and the application
provides NUA with username and password for the realm.The keepalive
OPTIONS uses the same username and password if it is challenged using
the same realm.
The above is the theory, but the code has never been tested. Caveat emptor.
Thanks for the explanation. I've been testing against a SER based service
from behind a NAT that does address and port dependent filtering. And with
the latest devel tree, it now works as you describe above - yay! :) It's
actually pretty nice, as connections would not simply work before with
this setup.
There are still some odd problems. As the NAT does address+port restricted
filtering, my contact is only valid for packets sent by the SIP proxy I'm
communicating with It seems that some calls+IMs sent to me are still lost
on the way. I assume this is due to load balancing of the proxies. Oh
well, to solve this, you'd need a proxy with sip-outbound support or some
SBC voodoo done on the way.
Anyway, here's some example messages how it works now:
1) We register, notice we are behind a NAT, and then reregister
with the contact learn from received+rport in the 200 response
to our initial register. This is all done transparently from
app developer point of view -- you just do one nua_register()
and it's all taken care of.
2) An options probe is sent (note the subject field). We are challenged
with a 407, but the stack takes care of it automatically using
the credentials for initial REGISTER.
--cut--
[sent to 195.x.y.z]
OPTIONS sip:[EMAIL PROTECTED] SIP/2.0
v:SIP/2.0/UDP 192.168.2.2;rport;branch=z9hG4bK4prrK6jDZtm1c
f:<sip:[EMAIL PROTECTED]>;tag=13K5p0UcHBvvc
t:<sip:[EMAIL PROTECTED]>
i:7Y1qTv1rQvfGAggCQr3dSq24eSf
Accept:application/vnd.nokia-register-usage
CSeq:67505544 OPTIONS
Proxy-Authorization:Digest
username="username",realm="foobar.domain",nonce="4461be700ba95b41b68e4e7fbc192c3702553d2c",algorithm=MD5,uri="sip:[EMAIL PROTECTED]",response="e500bd8fe1e7a1772bdfefef16db44e6"
s:REGISTRATION PROBE
l:0
--cut--
3) If the OPTIONS probe is succesfully sent, we continue with keep-alive
OPTIONS (note the max-forwards fields). Server replies with a 483
as the destination cannot be reached with the specified number
of hops, but this is completely ok as we've already refreshed the NAT
bindings which is the whole purpose of this signaling.
--cut--
send 517 bytes to udp/[195.x.y.z]:5060 at 10:24:27.294848:
OPTIONS sip:[EMAIL PROTECTED] SIP/2.0
v:SIP/2.0/UDP 192.168.2.2;rport;branch=z9hG4bK5ZHHN13gv3amr
Max-Forwards:0
f:<sip:[EMAIL PROTECTED]>;tag=13K5p0UcHBvvc
t:<sip:[EMAIL PROTECTED]>
i:7Y1qTv1rQvfGAggCQr3dSq24eSf
s:KEEPALIVE
Accept:application/vnd.nokia-register-usage
CSeq:67505545 OPTIONS
Proxy-Authorization:Digest
username="username",realm="foobar.domain",nonce="4461be700ba95b41b68e4e7fbc192c3702553d2c",algorithm=MD5,uri="sip:[EMAIL
PROTECTED]",response="e500bd8fe1e7a1772bdfefef16db44e6"
l:0
recv 566 bytes from udp/[195.x.y.z]:5060 at 10:24:27.366053:
SIP/2.0 483 Too Many Hops
v:SIP/2.0/UDP
192.168.2.2;rport=5060;branch=z9hG4bK5ZHHN13gv3amr;received=62.x.y.z
f:<sip:[EMAIL PROTECTED]>;tag=13K5p0UcHBvvc
t:<sip:[EMAIL PROTECTED]>;tag=b51ece8fd8c195776737473dd6552d43.6d2e
i:7Y1qTv1rQvfGAggCQr3dSq24eSf
CSeq:67505545 OPTIONS
Content-Length: 0
--cut-
... and yay, it works! :)
--
under work: Sofia-SIP at http://sofia-sip.sf.net
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
