sip wg open issues jonathan rosenberg. record-routing problem: spec omits anything about routing in...
TRANSCRIPT
SIP WG Open Issues
Jonathan Rosenberg
Record-Routing
• Problem: spec omits anything about Routing in reverse direction
• Lots and lots and lots of discussion on list
• Source of unending confusion to implementors
• Meeting at bakeoff among:– J. Lennox, N. Deason,
R. Sparks, J. Rosenberg, B. Biggs, B. Engelhom
– yielded consensus!!!
Proposal
• Proxies can only use SIP URL in RR
• MAY insert any SIP URL they like, so long as it routes back to that proxy
• SHOULD insert a URL that, based on configuration/logic in server, routes to correct user– Open on how to do this
• UAS reflects RR, including RR-params, in 200 OK
• UAS builds route by taking all URLs, appending Contact else From
• UAC builds route by reverseing RR URLs, appending Contact
Proposal
• Proxy MAY modify RR URL in response– Simple procedure to
find your URL by pushing/popping tags will be specified
• No transport param allowed in RR URL
• Preferences for UDP/TCP/TLS obtained ala SRV
• No special handling of rfc2543 only clients that don’t insert Contact– Few of them– Works more or less
anyway
Meaning of Call-ID
• Issue: what is the meaning of receiving an INVITE with a Call-ID matching an existing call, but different From?
• Possibilities– Additional party for an
existing call
– Replaces existing call (transfer types of function)
– Nothing – new call as if Call-ID where different
Meaning of Call-ID
• Problems with “new member semantic”– Use of call-id as
conference ID problematic for two party calls that need to merge to multiparty
– Overloading of semantics
• Proposal– KISS
– Call-ID has no conferencing semantics
– Define formal ways to define (1) a conference and (2) replace call, if needed
Tag issues
• How is tag computed?– Unique within end
system? Unique in each call?
• Depends on usages:– (1) Reject incoming
requests, like unRouted BYE, that are not for UAS since UAS rejected call previously
– (2) Differentiate multiple 200 OK responses to INVITE
– (3) Identify a new call as for a UAS as one that is a re-INVITE for an old call after crash/restart
Solutions
• All three can be solved if tag is unique within UA instance, if that UA wishes to survive crash and reboots, else unique across calls
• BUT, there is a problem when a user calls themselves– Same tag in To/From, same
To/From URI, can’t tell for which leg an incoming call is for
• Proposal:– If you don’t care about
recovery from crash/reboot, its unique within a call
– If you do care, you must• Have two tags, each one a
function of the UA (port + machine name)
• Always insert one into To, other into From
• Incoming calls with new Call-ID, but either of my tags, are for old calls
But More Problems
• A calls B, no tag in From. B answers, tag in To.
• A crashes.• B sends re-INVITE. Now
there is a tag in the From (the one B put in To).
• A gets re-INVITE. No tag in To field. Thinks its new call, adds tag in To field!
• B confused, since response now has a tag
From: aTo: b
From: aTo: b;tag=1
INV
200
From:b;tag=1To: aINV
From:b;tag=1To:a;tag=2 200
Tag headaches continue
• Solutions– Mandatory From tags
• Completely solves
• What about clients that don’t do it?
– Allow tags to change• Yucky to implement,
multiple keys needed
• Most robust
– Disallow change• Mandatory tags +
unlikelihood = who cares
• General issue:– If From didn’t have tag
originally, can it be updated later?
– If request is answered by a stateless device (I.e., proxy) may happen!
Tag Migraines Now
• What about receiving BYE after crash and reboot?– Call-ID new, tag is one
used by UA
• Should it send 200 OK or 481?
• 200 OK probably better
• General solution:– If you get a request
with new Call-ID, old tag, basically use it to create a call and then execute message
– Does that work?
SDP Semantics
• What exactly is SDP exchange procedure?– Can you have SDP in
INV/200 and ACK?– If no SDP in INV, can
you have SDP in 183 then PRACK?
– Can you send additional 183, each with new SDP? How may it differ?
• Need to define a general process for SDP exchange
• SDP in PRACK for 3pcc + preconditions
Meaning of re-INV w/o SDP
• Should be the same for INVITE and re-INVITE
• Like to maintain idempotency of requests
• Two possibilities– No change– No media
• No change implies loss of idempotency
• No media makes more sense
• Is it better to have no SDP, or SDP with no m lines?– No SDP = other side should
offer– SDP with no m lines, no
media, can only add in re-INVITE
mid-Call Redirects
• Primary issue is handling of Route headers and proxy behavior
• UAC behavior:– Can abandon route set
completely
– Can use old Route set, and add Contact to end
– Can use old Route set, replace last entry with new Contact
• Problems if new Contact is not UAS– Request may be proxied after
last route entry– Request can then collect RRs– 200 OK has new RRs– Can’t update route set at UAC!
• Two solutions– Abandon route set– Mandate that mid-call redirects
are to UAS only– Either way, recursion in
proxies is bad
Pros/Cons
• Abandoning Route set– Allows route set to be
updated
– But, proxies on original path may be confused
• Redirect to UAS only– Hard to enforce, otherwise
ideal
– Argues for replacing bottom Route entry with new Contact
• Usage scenarios?– MGC about to come
down for maintenance• Existing call state
transferred to standby
• Incoming re-INVITEs/ BYEs redirect to standby
• Realistic? Can be done at lower layers
IPv6 in SIP
• IPv6 in URLs not a problem– RFC2732
• Usage of IPv6 addresses problematic in– Via– Warning– Extension params
• Defined as tokens– But v6 addresses can
have :, which is a separator
• Solutions– Quote all v6 addresses
• Doesn’t work for warning, via
– Convert : to –
– Redefine BNF for Warning, Via, extension params as token | host
• May break really picky parsers?
• Proposal: third approach
Response Authorization
• Specification allows for response authentication– Challenge placed in
WWW-Authenticate in request
– Response placed in Authorization in response
• Not implemented?• Not clear there aren’t
security issues• No easy way to handle two
pass proxy to UAS Authorization
• Inconsistent with rfc2617 Authorization-Info
• Proposal:– Deprecate– Allow Authorization-Info– Use PGP-MIME, S/MIME for
PKI stuff
Overlapping Transactions
• Can you initiate a new transaction while one is in progress? What does it mean?
• Needed for a few cases:– PRACK for provisional
responses
– COMET for qos assured
– INFO to send ISUP before call completes?
• Proposal:– Allow overlapping
transactions under specific conditions
– Final response for new transaction not dependent on final response of previous
– Transactions do not affect state of each other
– Can only do them once tags/route obtained from provisional response
• Too general? Too hard to use concretely?
Multiple From
• Some folks want to allow multiple addresses to identify sender– Telephone number, email
like SIP URL
• Not supported in current SIP spec
• Network authentication of addresses was desired– Cross-domain signing
issues
• Proposal was made to add Sender header, or equivalent, listing extra addresses
• My proposal– Don’t add– KISS– No demonstrated need– Security issues
unsolvable
Early Media
• Many issues with early media– No way to modify once it
starts, since re-INVITE while INVITE in progress is disallowed
– Can’t easily get transferred while on hold
– Can’t put early media on hold
– Difficult to reconcile with forking
– Early media may not match code it comes in (180 + fast busy tone)
– Requires PRACK– Eliminates possibility of
sequential searches
• But, some kind of indication critical for ISUP mappings
• Two proposals– Live with it, widely used
already– Deprecate, define separate
billing related message to signal start of billing
Related: Media handling
• Should UAC be prepared to receive media right after sending INVITE?– If yes, why 183 needed?
– RTCP Port
– Indicate sendonly/recvonly
• Should UAC be prepared to receive media after 183 or 200?
• If 183 comes with SDP, is that always for reverse media only?– Can it contain SDP and
establish bidirectional media?
• Security implications– Receive media without
message in other direction = big hole for attackers
– 183 could contain info for IPSec or TLS connection establishment
Transfer out of Consultation
• Scenario on right– (1) A calls B– (2) A calls C– (3) A wants to transfer B to
C• sends REFER to B, with
Refer-To of C
• Problem– How do we guarantee call
from B reaches same instance of C A is talking to?
A
B
C
12
3 REFER
Approaches
• Use Contact of A-C conversation in Refer to B– Contact may not be
globally routable (ACD)
– NAT
• Use From/To of A-C call with Accept-Contact– To/From may not be usable
if C called A
– Routing logic may change during call
• Proposal– Hard problem
– Use hybrid approach, try Contact then try From/To with Accept-Contact
– Other suggestions?
REFER Timeouts
• REFER transaction must complete in 32 s
• INVITE it triggers may not complete in 32 s
• REFER may time out• Basic problem is that
non-INVITE is meant for rapid responses
• Solutions– REFER completes
immediately, REFERDONE or otherwise sent when request finishes
– Punt– Respond to REFER
within 16s if no final response comes, using 202
BYE/Also
• Expired draft• Replaced by REFER• Some people still have
it implemented• Want it put into bis
draft for “backwards compatibility”
• IMHO, BAD– Interop/maintenance
nightmare
– That’s the pain of implementing/shipping products based on experimental –00 drafts
Request URI Parameters
• Whats allowed, whats not allowed, and whats recommended?
• Maddr and port and transport are a MUST if they exist in the URI and you don’t send request there
• Unknown URI params are allowed– Needed for getting state
back
• Currently, header params not allowed– Makes sense; using this
URL would cause those params to be put into actual header
• Same with method param
Reinvite Glare
• Reinvite glare = both sides reinvite at same time
• Can be confusing since session state depends on order of 200 OK and INVITE from single participant
• Current solution is 5xx w/ random Retry-After if you get re-INVITE while reinviting
• Retry-After has second granularity
• May take time to resolve
Reinvite Glare
• Proposal I– Meaning of Retry-After is
choose a number from zero to this value
– Changes existing semantics
• Proposal II– Include Cseq of last
received INVITE in INVITEs I send
– Allows recipient to detect problem and one side to back off
• Proposal III– Granularity not an
issue– Probability sufficiently
low to ignore
• Suggestion– Proposal III
Preloaded Route Headers
• Can you send an initial INVITE with Route headers?
• Issues– Where does Route
headers come from• Orthogonal
– Route headers stripped out, so route not rebuilt!
• Solution– Proxies really
SHOULD re-insert RR in each request, even when Route present
– Needed here plus several other places
– So, will only work with bis proxies
SRV randomization issues
• Stateless proxies can send retransmissions of same request to different next hops
• Spec now says that stateless proxies use hash of Call-ID as index to randomization algorithm
• Two issues– Consistent selection of
server for a transaction also for stateful proxies
– Algorithm may still fail if results of DNS query returned in different order or change in zone
– Need to alphabetize?
Message/Header lengths
• 1500 message limit exceeded frequently
• Many implementations limit header sizes or parameters
• What should spec say about these things, if anything?
• Proposal:– SHOULD allow any
message up to 64k
– SHOULD allow any number of each header
– SHOULD allow headers of any size (not beyond message size limit)
THANKS! TO:
• Tom Taylor• Bert Culpepper• Ben Campbell• Igor Slepchin• Balaji Narayanan