SIP WG Open IssuesIETF 50

Jonathan Rosenberg

dynamicsoft

Subset vs. No Subset

• Rfc2543 inconsistent on whether SDP in response is subset of INVITE or not– Normative says

SHOULD

– Examples don’t, text in examples says MAY

• Minimal Subset– + Helps reduce set of

codecs you need to worry about

– - Can’t represent sendonly codecs for a bidirectional stream (DTMF)

• What should spec say?– List receive codecs – more

flexible

Cseq incrementing

• Rfc2543 says Cseq increments are “contiguous”

• Some list discussion may have said that it need not increment by 1.

• Incrementing by 1 important for ordering– Especially with all these

new methods mid-call

• Clarification:– MUST increment Cseq

by 1 for each transaction in a leg

– If you receive a Cseq that is larger than previous by more than 100, reset

• Helps for crash recovery

TCP Connection Handling

• Spec says– If server closes connection

before final response, = 500– If client closes before final

response, = CANCEL

• New CANCEL rules will cause proxy to reopen connection to send 487!

• Really bad for persistent connections between proxies

• Huge implementation nightmare

• Eliminates possibility of failover and high availability in TCP SIP networks

• Proposal:– Closing of TCP connections

has no impact on SIP states

• Issue: are there clients or servers that use these features on purpose?

TCP Connection Issues

• Spec doesn’t say much about usage of persistent connections

• Recommend adding specific text about it

• Proposal– Connections indexed by

[IP,port,transport]– Resolve URI, determine next

hop tuple– Look for existing connection

to tuple, and reuse

• Keep connections open until inactivity for some amount of time, configurable, recommended 30s

• Recommend persistent TCP when:– There are explicitly configured

next-hops– Common in intra-domain cases

• When possible, has nice congestion control properties, message efficiencies

Response Failover

• Would like to survive failures of proxies mid-transaction

• Usage of received tag prevents this– Response always sent to

server it came from

• Spec recommends domain name in sent-by to provide feature, but it doesn’t work!

• Proposal:– Send response to received

param– If failure

• ICMP• Timeout for invite non-200

OK• TCP connection gone

– Use domain lookup processing on host in sent-by

• Only works for stateful proxies

• Bad if crashed proxy forks!

More tag issues

• From tags not mandatory– Last IETF, determined

cases where this could result in problems

– Need to make mandatory

• Spec says it SHOULD be unique within UA instance

• But, there are benefits to unique for each call leg– Ensures that Call Leg ID

includes unique identifier contributed by both sides

– Allows Call leg ID to be used for billing ID in half-trusted models

• Proposal:– Tags unique per call– MAY contain ID to associate

them with UA instance– Best of both worlds

409 and Multiple Contacts

• Spec says that registrar responds with 409 if UA tries to register Contact with an action different from current

• Proposal was made to remove that restriction

• Cons:– What is behavior? If

there is no standardized behavior, will make things very confusing

• Pros:– Simpler for client?

• Proposal– No change to spec

Record Routing

• Still awaiting more comments on new text…

• Issue: what about unknown methods?

• New text says you can’t RR on them– If you don’t know what

it is, you have no business RR

• Issue is proxies that are there for FW/NAT traversal– They don’t need to know

method, but need to be on path

• Proposal:– Allow RR on any method

– UA ignores RR if it arrives in a method its not supposed to

Meaning of re-INV w/o SDP

• Should be the same for INVITE and re-INVITE

• Like to maintain idempotency of requests

• Three (not two!) possibilities– No change

– No media

– You offer

• No change implies loss of idempotency

• No media violates m line matching models

• “You offer” seems to work– A INVITEs B w/o SDP– B returns SDP in response,

generally same thing it is already using

– A returns its answer is ACK

• Needed for latest 3pcc flows

Still an Issue: Early Media

• Results from interim meeting– UAC should be prepared to

receive media on INVITE (clipping) -> not early media

– UAS should be prepared to receive media on 200 OK

– Move rest of early media to another draft

• Usage of 183/PRACK has problems– Bandwidth constraints

– Turning of streams on hold

– Overloading of PRACK/183

• Desperately need an early media draft

One possible solution

• Reverse INVITE!• When A calls B, and B

wants to setup early media to A– B sends INVITE to A for

new call– This call is associated to

original

• Since its its own call, we can– Hang them up– Put them on hold

• SDP negotiations now limited to INV/200/ACK, no PRACK or others

• Drawback:– Weird

– Not compatible with what people are doing now

• Lets see some drafts on alternate proposals..

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?

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?