SIMPLE Open Issues
Jonathan Rosenberg
dynamicsoft
IETF 52
Open Issues in Presence-04
• Dependencies and duplication
• “Alerts”
• NOTIFY/200 race resolution
• Forking/migration
• Indicating subscription status
Dependencies
• Currently– Rfc2543 sip-events presence
• Problem– Sip-events is having to repeat more and more text from bis to
keep up– Presence duplicates a lot of text from sip-events
• Proposal– bis sip-events presence– Bis is nearing completion so timing is not going to be much
different– Requires cleanup of redundant text across all three docs – in
progress
Alerts
• Would be nice to only be notified of change in presence, not actual presence– Actual presence could then
be fetched with HTTP
• Why is this useful?– Large presence documents
wouldn’t get fragmented– Large presence docs could
be fetched when time is good (I.e., not in a call)
SUB sip:userAccept: application/uri-list, application/cpim-pidf+xml
200 OK
NOTIFYC-T:application/uri-listC-L: …
http://www.getit.com
200 OK
HTTP GET http://www.getit.com
Details
• SUBSCRIBE would have Accept header indicate support– Presence of
application/uri-list– Still have to support
application/cpim-pidf+xml
– Can use q values to indicate preferences
• Would need to baseline HTTP as minimum mandatory URL– HTTPS, SOAP would
be others
Issues with Alerts
• Broader than presence, probably belongs in sip-events– Presence would then state
that its allowed\
• Security issues– Just because SUB can be
authenticated, doesn’t mean HTTP can
• Transitive trust vs. e2e
• HTTP/SIP interactions– Requires a way for SIP
server to manipulate content on web server
• Duration of URL validity– Need to specify –
presumably subscription duration
• Proposal– Really useful, really simple– Add to sip-events and
presence
NOTIFY/200 Race
• ASSUME you want to only accept one NOTIFY
• Sip-events says you should accept the one that matches 2xx to SUBSCRIBE
• What if NOTIFY beats 2xx back?
SUB
SUB 2xx
NOTIFY
SUB
SUB 2xx
NOTIFY 2xx
Proposals
• Buffer NOTIFYs until 2xx– Then 481 all but
matching ones
• Accept all NOTIFYs– When 2xx arrives,
refresh all non-matching
– When those NOTIFY arrives, reject with 481
• Accept first NOTIFY– SUB 2xx is ignored
• Accept first message– SUB 2xx if its first
– NOTIFY if its first
• Probably also an issue for sip-events, not presence
Forking
• Definitely the biggest issue
• Some problems are not presence specific– HERFP
User A Proxy User B User C |SUB | | | |-------->| | | | |SUB | | | |-------->| | | |SUB | | | |------------------>| | |401 | | | |<--------| | | |200 | | | |<------------------| |200 | | | |<--------| | |
Allow Forking• Cons
– Burden on sub to merge presence docs
– Inability of sub to merge presence docs with proper watcher policy
• Especially for elements that are NOT per contact
– Heterogenous error response forking problem (not presence specific)
• Makes it hard to authenticate SUBSCRIBE
– Unknown billing models– No expectation that it is a
requirement to support
• Pros– May happen anyway– Avoids requirement for
proper network architecture to ensure functioning
– Allows more flexible operation in scenario where there is no network PA
• Multiple clients
Disallow Forking
• Pros– Simplified clients
– Correct operation• I.e., full and correct
presence state
• Cons– Need to mandate the
existence of an aggregator for proper operation
– May happen anyway, need to specify what to do
– Doesn’t allow for serverless distributed systems
• Will get partial presence or no presence
Proposal
• Domains SHOULD have aggregation in PA– Avoids forking through
network design– Provides most correct and
consistent operation
• If there is no PA, still works if there is just one PUA
• If there are multiple PUA, you get partial presence, no guarantees– Probably just one NOTIFY
anyway because of HERFP
• Subscribers SHOULD accept only one NOTIFY– Should only need to based on
the above
• But its SHOULD, not MUST– Burden is on the subscriber
to implement merging if it wants
– Won’t generally be needed based on domain requirement, and frequently won’t happen because of HERFP
Issue with this proposal
• Lets say we fix HERFP down the road– Can generate new spec
which talks about serverless distributed domains
– Warnings about policy issues
• How does presentity domain know subscriber won’t merge, so aggregation is needed anyway?
• Ideas– If it can’t merge,
includes caller-prefs no-fork
– It if can merge, include caller-prefs fork
Subscription Status
• NOTIFY needs to contain status of the subscription– Can’t rely on 2xx to subscribe
– May change later on (pending to accepted)• Want to be explicit
• Adam added Subscription-Expires with reason values to sip-events
• Issue: need to align with watcherinfo– They are both about the same thing!
Statuses in winfo/sip-events• Proposal for unification
– Deactivated• Subscription terminated• Retry again
– Probation• Retry again, but much later• Retry-After• Covers maintenance
– Rejected• Don’t bother retrying• Policy change
– Timeout• Retry again if you want• Wasn’t refreshed
– Giveup• Couldn’t obtain auth
sip-events watcherinfo
---------- -----------
migration <-> deactivated
maint <-> ?
refused <-> rejected
timeout <-> expired
? <-> timeout
Watcherinfo Open Issues
• Events leading to terminated– See previous discussion…
• State maintenance for pending/waiting– Possible Dos? Sub is authenticated…– -01 will talk about setting policy for this
• Tradeoff between user experience and state storage
• Elements in data format– Next slide
Elements in Data Format
•Watcherinfo data
–Uri of watcher
–Status of subscription
–Event which triggered notification
–Duration: time in last state
–First-subscribed
–Most-recently-subscribed
–Notify-address
–Expiration
IMTP(with A. Houri, C. Huitema, R. Osborne)
Motivations for IMTP
• Requirements for IM transport– Congestion Control
– Reliable, sequence delivery
– Arbitrary sized messages
– Framing
– Per-IM content typing
– E2e privacy, integrity, authenticity
– Works through NAT
– Rapid delivery
– Lightweight
– Parser Reuse
– Compressible
– Support for relay intermediaries
– Muxing
– Logging
– Per message ACKs
The hard configuration
Proxy
PC
Enterprise 1
Proxy
PC
Enterprise 2
Internet
How about SIP?
• Pros– Parser reuse
– Proxies as intermediaries
– NAT traversal easy
– Logging, framing, sequencing all done
• Cons– SIP has features that
would get in the way• Record-routing• Redirection• Forking
– Messages might go over UDP
– Performance of Proxy as pure forwarding intermediary is poor
Idea: SIP subset
• IMTP proper subset of SIP– Remove uneeded
features• Forking, redirection,
recursion, record-routing and route
– Introduce restrictions• Only TCP
• Change protocol field to IMTP/1.0 from SIP/2.0– Most proxies won’t route– BUT, one-liner to fix that– Want this to be explicit about
what protocol is running
• Proxy with proper configuration can route IMTP– No forking, no record-routing,
no redirect, TCP only
• Can use REGISTER to set up IMTP bindings!
User A Proxy IMTP Proxy IMTP User B P1 Relay P2 Relay R1 R2 | | | | | | | | | | | | |(1) INVITE | | | | |-------->| | | | | | |(2) REGISTER | | | | |-------->| | | | | |(3) 200 OK | | | | |<--------| | | | | |(4) INVITE | | | | |------------------>| | | | | | |(5) REGISTER | | | | |-------->| | | | | |(6) 200 OK | | | | |<--------| | | | | |(7) INVITE | | | | |------------------>| | | | |(8) 200 OK | | | | |<------------------| | | | |(9) REGISTER | | | | |-------->| | | | | |(10) 200 OK | | | | |<--------| | | |(11) 200 OK | | | | |<------------------| | | | |(12) REGISTER | | | | |-------->| | | | | |(13) 200 OK | | | | |<--------| | | | |(14) 200 OK | | | | |<--------| | | | | |(15) ACK | | | | | |-------->| | | | | | |(16) ACK | | | | | |------------------>| | | | | | |(17) ACK | | | | | |------------------>| |(18) MESSAGE | | | | |------------------>| | | | | | |(19) MESSAGE | | | | |------------------>| | | | | | |(20) MESSAGE | | | | |-------->| | | | | |(21) 200 OK | | | | |<--------| | | |(22) 200 OK | | | | |<------------------| | |(23) 200 OK | | | | |<------------------| | | | | | | | | | | | | | | |
Open Issues
• Is this the right approach?
• OPES-style authorization for intermediaries?