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