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