Upload
lauren-shelton
View
224
Download
5
Tags:
Embed Size (px)
Citation preview
Open Issues in bis12/6/2001 5:28 PM
Jonathan Rosenberg
dynamicsoft
Resolved since last time:
• #7: CANCEL for non-INVITE– MUST be prepared to
receive– SHOULDNOT send for
anything but INVITE– New methods can define
usage– Not in spec yet, will be in -
06
• #10: Stripping maddr: OK?– Yes, in -05
• #11: record-routing non-INVITE mid-call?– Proxy can, UA ignores– In –05
• #20: mixing multicast/unicast in offer/answer– Disallowed, in –05
• #21: granularity of multicast in SDP– Will fix in offer-answer-01
Resolved since last time:
• #23: dynamic PT reuse– Disallowed
– Clarifications in offer-answer-01
• #26: should we specify how to handle misaligned SDP?– No; removed in bis-05
• #58: Rejecting mid-call SDP where offer is in 2xx– Make it so it never is
needed– Already in bis-05
• #71: RTT Estimation: how?– Algorithm now
specified in bis-05
Resolved Since Last time:
• #72: Multicast CANCEL– Multicast allowed, but
works “like unicast”
– Means CANCEL is responded to even over multicast
– In bis-05
• #73: Respond to held SDP w/ Held SDP– Don’t; in offer-answer-00
• #84: CANCEL/Request race condition– Wait till 1xx; in bis-05
• #107: e/p lines in SDP– Offer-answer-01
indicates its not mandatory, in line w/ sdp-new
Resolved Since Last Time
• #118: 481 then BYE– Is call down on 481, or only
after you send a BYE?
– Bis-05: send a BYE
• #121: Reason codes in BYE/CANCEL?– Separate extension
• #122: CANCEL on 2xx MUST/MAY/SHOULD?– MUST in bis-05
• #130: BYE v. CANCEL– CANCEL before 2xx
– BYE afterwards
– In bis-05
• #133: On hold indication– Use a=inactive instead
of 0.0.0.0
Resolved Since last time
• #138: Fork or not to fork– Fork
• #163: Where to put SDP stuff– In separate I-D
• #216: Directionality of Alert-Info– Can be both request and
response
– In bis-05
Open Issue #24/#146: re-use disabled streams
• Spec says that once you’ve disabled a stream (port zero) you can’t reuse it– Result is that SDP size
increases as you disable/add streams
• Why?– MUST maintain implicit
ordering of codecs
• Problem is increasing size of SDP– Issue for 3gpp it seems
• Proposal– Can never remove a
disabled stream
– But, if you add a new one, it can take disabled streams’ “slot” within SDP
• Can be totally different media
– This keeps ordering without increasing size of SDP
Open Issue #81: Caching of SIP Proxy Credentials
• Spec says a UA should cache its credentials for a proxy, and reuse next time it sends to that proxy
• How does UA know what proxy its sending to?– No easy way for initial
requests– For re-INVITES, depends if
that proxy record-routed – no easy way to know!
– If proxy didn’t record-route, Proxy-Auth never stripped
• Proposal– MAY use any cache strategy– RECOMMENDED to place
credentials in request if it has same call-id as a request you got a challenge for that realm on (next slide)
– MAY have configured local outbound realm – cache credentials to it
– MAY reuse UA credentials if To field in request is same as previous
– What you are really caching is the nonce
Issue #81 Flow UA1 P1 P2 UA2 |INVITE | | | |------------------>| | | |407 Realm: A | | | |<------------------| | | |INVITE Realm: A | | | |------------------>| | | | |INVITE | | | |------------------>| | | |407 Realm: B | | | |<------------------| | |407 Realm: B | | | |<------------------| | | |INVITE Realm:A,B | | | |------------------>| | | | |INVITE Realm:B | | | |------------------>| | | | |INVITE | | | |------------------>| | | |200 | | | |<------------------| | |200 | | | |<------------------| | |200 | | | |<------------------| | | |ACK Realm: A,B | | | |-------------------------------------->| | | | |ACK Realm: B | | | |------------------>|
Issue #88: Addressing Proxy w/ OPTIONS
• Bis-05 says the target is in the r-uri, which can be a proxy or UAS. What URI for a proxy?
• Solution: sip:domain, much like registrations.
Issue #109: Allow in non-INVITE
• Two questions:– Is it allowed outside of
INVITE/OPTIONS
– What URL does it refer to in an OPTIONS response? Subsequent request may get routed elsewhere!
• Answer one:– No – has no useful meaning
• Answer 2:– General problem, for
Accept, Accept-Encoding, etc., even Authorization
– State that it refers to request URI in original request
Issue #113: Overlapping Forward Transactions
• Current SIP model– One INVITE at a time
– Within an INVITE, other non-INVITEs
– Each non-INVITE cannot overlap
• This has limitations– Non-INV throughput
1/RTT
– Cannot update INVITE (early media)
INVITE
INFO
PRACK
INFO
Why did we do it?
• INVITE: Confusion about most recent session description– Cannot determine
ordering of SDP in both responses
• Non-INVITE– Cannot guarantee
sequence delivery
• Proposal?– Disallow overlapping
INV
– Allow overlapping non-INV
• Notion of “full state” nonsensical
• Strict sequencing within content
Open Issue #126: Behavior on no ACK to 2xx to re-INVITE
• Current text says to re-INVITE to re-establish session state– Could get complicated
– what if that fails too?
• For initial INVITE, you send a BYE– For conformity,
shouldn’t it be the same for re-INVITE?
• Proposal:– Send a BYE in this
case
Open Issue #128: 503 Handling
• Should SRV processing continue with the next element if you got a 503 when trying one of them?
• Yes
Open Issue #131: Challenging gateways
• If a proxy or UAS challenges a UAC that is a gateway, is the challenge– For the gateway– For the user through the
gateway
• In the latter case, the gateway might play a prompt to ask for the password
• How to tell the difference?
• Proposal– Realms
– Gateway knows realm it has credentials on, answers challenges for it
– Gateway could ask user for password for realms it doesn’t know, these may be for user
Open Issue #139: INVITE glare
• A INVITEs B at same time B INVITEs A
• Problem:– No way for B to order
INVITE from A and 2xx from A
– Same for A
• Ordering needed to know which is most recent SDP
• Current text recommends a 5xx with Retry-After– Problem is that its slow– Apparently is happening in real
usage
• Proposal:– Be explicit– Define a 491 response code to
indicate this– Two cases:
• INV from far side beats 491 to your INV
– Send 491– Retry randomly in 0-3s
• 491 from far side beats INV from far side
– Respond 2xx
Two cases of 491INV INV
491
491
INV INV
491
200 OKINV
2xx
#140: Remove URL from call-leg definition
• Why do that?– Helps overlap dialing – can
change the To field in re-invites on the same leg
– Can use actual URL in From field in re-INVITE in reverse direction
– Faster UA lookups
• Drawbacks:– Backwards compatibilty
issues – would need a Supported header
– Could still be an issue for proxies
• Discussion– Overlap point is moot if
overlapping INVITE not allowed
– Can do faster lookups without a spec change
– From field in reverse re-invite not useful for policy anyway, not authenticated
• Proposal– Change nothing
#144: Branch ID = Transaction ID
• Transaction ID computation is challenging– Many fields
– Conditional inclusion (tags)
• Bis-05 already has branch ID as unqiue for each transaction
• Proposal: Allow branch ID to be the transaction ID– Clients MAY insert– Cookie in value to indicate
its unique
• Would improve performance, simplify interop, little cost since you must still fallback
• Recommendation: accept proposal
#145: Stateless SRV Part I
• Bis-05 says that all requests with the same call-id go to the same next-hop
• That is a problem for proxies, which are either stateless or just transaction stateful!
• Call-ID granularity chosen for overlap dialing
• Stateless algorithm would need to:– Alphabetize DNS answer
• HGS suggests order by weight
– Choose index as H(Call-ID)– Ugly
• Proposal:– Revert to only requiring
requests within a transaction to same next hop
– Stateless proxies need to do what they need to do
#150: Saying “don’t send”
• Spec has many ways to say “don’t send me media”:– A=sendonly– A=inactive– Bw=0– Port zero– 0.0.0.0
• Do we need all of these??
• Answer: no, but we need several:– A=sendonly stops receipt of
media
– A=inactive stops RTP/RTCP in both directions
– Port zero terminates media stream (stop tools)
– All others not needed
• OK?
Open Issue #140: Call Leg w/o URLs
• Problem:– Call leg ID includes a
combination of To/From/Call-ID, which includes URLs
– SIP URLs make lousy identifiers
• Must canonicalize• Long
• Problem:– From field in reverse re-
INVITEs may not be the sender of the request!
– Loss of idempotency
• Proposal:– Re-define call-leg ID with
tags/Call-ID ONLY– Needs Supported header in
INVITE/2xx• No impact on proxies
though
– Benefits• Re-INVITEs can carry
real identity• Faster call leg lookups• Glare scenario improved• Replaces header easier
#164: Proxy-Authentication-Info
• Defined (barely) in rfc2617, used for mutual auth between UAC and proxies
• Problem: missing realm parameter– Makes it hard for client
to figure out which header is for which client
• Approaches:– Give up
– Add realm
– Use nonce
• Proposal:– Use nonce
– Client supplies unique cnonce in each request
– Response has cnonce mirrored, so it can be used to match
#178: Deprecate absolute times
• Expires header and expires param can be in absolute time
• Absolute time requires time sync between client and server– Not always the case– Would need to include Date
header to tell other side what they thought date is
– Result is effectively always delta time
• Proposal: deprecated absolute times in Expires, expires
• Two variants– Remove entirely (if no
one is using)– MUST be prepared to
receive, but MUST NOT send (backwards compatible)
#179: Multicast to unicast REGISTER
• Multicast REGISTER refreshes– Multicasting them also may
be useful for replication– Unicasting useful if
multicast was only for discovery
• How to do first REGISTER multicast, rest unicast?– 301 to unicast URL– Sip:foo.com;maddr=1.2.3.4
• If it fails, you need to try multicast again– General issue for cached
redirects – try the original URI
• Proposal– Add text to 301 section,
saying try original URI on failure
– Add text to registration section, detailing this case
#181: Stock splits? No – forking OPTIONS
• OPTIONS can fork• You’ll get only one
200 OK back• Who knows which UA
it corresponds to• Ideally, would like to
hear from all UA it reached
• Could use an approach similar to SUBSCRIBE– Reverse OPTIONS
from each server back to client
– Too complex
• Proposal:– Document limitation
#184: Size does matter
• Sub-problem 1: MTU and fragmentation– We’re seeing sip messages
bigger than ethernet mtu– Solutions
• Deprecate UDP• Deprecate UDP inter-server• Define sip fragmentation• Use UDP IFF size < 1500,
else TCP– Add response code that
means “response is too big to actually fit” so client retries with TCP
• Ignore
• Sub-problem 2: Maximum field sizes– Spec says nothing on
maximum header or parameter sizes
– People often impose a limitation in their implementation
– Has resulted in interop issues– What to do?
• Specify no limits• Define limits• Ignore
#188: Reply-To• You know what it means. We
don’t have it.– Not the same as Contact (that’s
a host address)– Not the same as From (might
not want return calls back to me)
• Issues– Use Remote-Party-ID instead?– Separate extension?– Privacy implications?
• Need to strip off at edge or something?
• Have an R-P-ID equivalent?
• Proposal:– Its simple.
– Its understood.
– We need it.
– Just put it in.
#197: Contact in OPTIONS response
• There are two types of Contact– 3xx/REGISTER
semantics
– INVITE/INV-2xx semantics
• Which one is OPTIONS response using?
• Odds are you can’t signal directly to the contact if it were the INV/2xx semantics– Firewall, nat
• Proposal:– 3xx semantics
#203: URL Params in To/From
• Table I allows port but not maddr in URL in To/From
• Should either be all transport related params, or none
• To/From should be logical addresses
• Proposal:– Neither port, transport, maddr, ttl
#204: Password in To/From
• Bis-05 allows URL password in the From field, but not in the To field.
• Seems inconsistent– Should either allow both or document why the
discrepancy exists
• Proposal– Discrepancy is because password is to identify the
originator in a simple way– Password for To would be wrong if request forwarded– Document these
#205: Header/Method params in Contact
• Bis-05 allows method and header params in URL in 3xx/register Contact
• Do we really want that?– Headers: yes; you could add a Subject for example to a
call to you– Method: no, except people have confused method and
methods for presence stuff
• Proposal:– Don’t specify things that are known wrong– Disallow method, allow headers
#207: Handling of media failures
• Spec is silent on what to do in SIP if session fails– ICMP errors– Lack of RTCP– Etc.
• Draft-rosenberg-sip-reconstitute suggests a re-INVITE to see if that helps– Will help if end system has
failed – will reconstitute session state at a backup
– Won’t help if network problem exists
• Most of text in reconstitute draft is not normative– Implementation guidelines
• Only normative text is to send this re-INVITE on failure– Needs to be in bis
• Proposal:– SHOULD re-INVITE– SHOULD send BYE if it
doesn’t help
#210: Timer D depends on client T1
• Timer D in INVITE Client transaction depends on Timer H in server transaction– See next slide
• Timers scale based on local RTT estimate T1
• So, client may have wrong value for timer at server
• Proposal– Define RTT
independent minimums (32s in this case)
FSM Dependencies
| | | | 300-699 V | | ACK sent +-----------+ | | +---------| | | | | | Completed | | | +-------->| | | | +-----------+ | | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+
| +-------------------+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V fail to TU | +-----------+ | | | | | Confirmed | | | | | +-----------+ |
Client INVITE Transaction Server INVITE Tranaction
Timer H = 64*T1Timer D = Timer H
#212: Applicability of RTT Estimates
• RTT Estimate is done using transactions, between client and server transactions– So, stateless proxies don’t
count
• Thus, RTT estimate to IP addr X might have X as a stateless proxy– That estimate would be wrong
for other R-URI
• What to do?• Proposal: Ignore
– Use IP address anyway
A
B
C
100ms
100ms
200ms
A sends to B, gets RTT estimate to IP X as200ms
A sends to C through X again, RTT estimateof 200ms is wrong; should be 300ms
#219/#221: SRV algorithm
• More work needed here
• TBD Jonathan
#220: Stateless SRV Pain II
• SRV processing algorithm retains state– Where each request in
a transaction goes– Set of failed servers!
• Second piece of state is a big problem– How does a stateless
proxy know that a server has failed?
• Possibilities– Each request starts at the top
and will take require detection of failure each time
– Problematic if server recovers mid-transaction
• Proposal– RECOMMENDED that
servers that use SRV are stateful
– Otherwise, start at the top as above
– Document issues that arise
#231: Stateless UAS
• Stateless UAS is not well defined in the spec but possible– Regenerates the
response for each request
– Never sends 1xx
• Works fine for both INVITE and non-INVITE transactions
• Why do you want this?– Needed for DoS SYN
attack prevention style attacks
– 401/407 should always be sent this way
• Issue: should we talk more about this behavior?
• Proposal– Yes – its needed for DoS
attack prevention
#232: TLS v. IPSec
• Bis-05 recommends TLS for transport layer security
• Issues– Need not have same thing
for u2p and p2p– UDP/IPSec has no
congestion control– IPSec has no useful keying
scheme– TLS allows application to
know authenticated ID of far side
• Many cases, IP address based policy is NOT what you want– Wholesale SIP “trunk”
• Proposal– Proxies MUST support TLS
for p2p operation
– Proxies MAY support IPSec
– U2p is a separate problem
#266: Heterogeneous Error Response Forking Problem
User A Proxy User B User C |INVITE | | | |-------->| | | | |INVITE | | | |-------->| | | |INVITE | | | |------------------>| | |415 | | | |<--------| | | |ACK | | | |-------->| | | |180 | | | |<------------------| |180 | | | |<--------| | | | |200 | | | |<------------------| |200 | | | |<--------| | | |ACK | | | |---------------------------->|
Reasons for the problem
• Proxy merging rules are best on “single best wins”
• Merging of 401/407 credentials only works when ALL elements generate a challenge!– Doesn’t allow for
merging across response codes
• Proposals– TBD
#281: URL as key to LS DB
• Bis-05 says that you use the entire URL as the key to store registration info in the Location Service DB– I.e., To field URL
• This URL is matched, using URL equality, against Request-URI of requests for routing
• Problem– R-URI may have
port/maddr/transport/ttl– These would not have been in
To of REGISTER– Thus, they don’t have URL
equality– 404 is getting sent by proxies
• Proposal– Make key a matter of local
policy– Need only be consistent
between registrar and proxy– Document guidelines
#282: Timer C needs default for proxies
• Timer C specifies time INVITE client transaction waits for final response after provisional
• Currently, spec says TU specifies it
• For UAC, represents how long the phone rings
• What is it for proxies?• Issues
– Need to specify a minimum
– If proxies give up early, calls will fail (proxies will cancel on giving up)
• Proposal– 32s
The Biggie: Routing
• Bugs #159, #161, #213, #218, #268
• Proposals:– TBD by Robert