SIP WG Open Issues

1
SIP WG Open Issues

• Jonathan Rosenberg

2
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

3
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

4
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

5
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

6
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?

7
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
• Dont add
• KISS
• No demonstrated need
• Security issues unsolvable

8
Early Media

• Many issues with early media
• No way to modify once it starts, since re-INVITE
  while INVITE in progress is disallowed
• Cant easily get transferred while on hold
• Cant 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

9
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

10
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?

C
B
2
1
3 REFER
A
11
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?

12
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
• Thats the pain of implementing/shipping products
  based on experimental 00 drafts

13
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 dont 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

14
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

15
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

16
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

17
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?

18
Overlap

• Current approach
• Each digit(s) are new INVITE with new To, R-URI,
  same Call-ID, increasing C-Seq
• Terminating GW sends 400 to old ones as new come
• Terminating GW sends 183 w/ RR headers, so INVITE
  can have preloaded Route

• Issues
• Multiple call legs is not clean and not standard
• Pre-loaded routes
• Alternate Proposal
• Same call leg
• Use INFO for extra digits
• INFO will never be seen by vanilla UAS, since it
  wouldnt be reached until all digits were present
• INFO only sent if UAS indicates it can do it

19
Pros/Cons

• INFO approach
• Uses single call leg
• Still compatible with normal UAS
• Hides overlap from sip networks (sort of)
• But, sip network never sees actual dialed number
• No way to provide apps to PSTN users

• Multiple Call Legs
• Very ugly
• Requires many non-standard behaviors
• But, allows sip network to see end to end
  addresses

20
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)

21
Timestamp Header

• Issue Spec says to reflect timestamp header in
  response, but doesnt say which response
• Answer depends on purpose
• For Retransmit timing
• Want RTT between client and next stateful server
• That means ONLY 100 response!

• Other applications?
• Solution
• Mandate in all responses, 100 to 600

22
THANKS! TO

• Tom Taylor
• Bert Culpepper
• Ben Campbell
• Igor Slepchin
• Balaji Narayanan