Issues Meeting – SIP Bar BOF Tuesday, March 20, 2001

Notes taken by David Shrader

 Issues to Discuss

• Overlap
• Record Route
• Early Media
• Re-INVITE Glare
• Pre-loaded Route headers
• SRV Randomization issues
• 409
• Replaces Header
• Request-URI parmaeters

 Closed Issues from Previous Meetings

• Re-INVITE without SDP – closed
• The re-INVITE without SDP means “no change, keep whatever you already have”
• Refer-to issue

 Jonathan R indicated that he would re-issue the bis draft as soon as possible after the IETF meeting.

Issues Work

Record Route

• What methods do you Record-Route in?
• JR thought it meant only for session initiation methods, something that installs state
• RM Any transaction that has subsequent transactions in the same call leg.
• There is also a request to not shove garbage into SIP messages because we are using UDP. We would like to avoid fragmentation because there are problems with fragments.
• Go ahead and add RR in other messages that don’t need it, such as Options.
• There is also a comment about the difficulty of implementing exception cases.
• RS You should put RR in things that are useful, but MAY put it anywhere.
• JR added comment that the UA will ignore RR in methods that don’t use it.
• Note: when RR comes in subsequent messages. The receipt of it MUST NOT update the route set. “If you have a route set for this call leg and you receive a RR, don’t create it.” “If you don’t have a route set for a call leg and you receive a RR, install it.”
• “A RR in a 200 OK from a PRACK and COMET are both ignored.” “A RR that occurs inside an INVITE is ignored.” This is a little more difficult in that the RR within an INVITE may have a limited lifetime. This is added as issue “RR w/in pending INVITE”.
• JR – probably add text in bis about the overlap transaction limitations. In particular, the INVITE is the only transaction that allows overlap.
• Basic RR issue closed.

Re-INVITE Glare

• If you have an invite transaction in progress and you receive an INVITE, you should reject it with a 500 and a Retry-After granularity of seconds. There are concerns that this was not fast enough with proposals to make faster.
• Is this even a problem? Is the SDP a one-sided view or a two-sided view? Are there are other state items in the re-INVITE that cause this to be a problem?
• SDP negotiation may be a future problem.
• This item is still open.

Pre-loaded Route headers

• Clearly recognized as a need. There are good reasons for it.
• A request that already has a route in it, still needs to be record-routed.
• Are there potential security threats to this? These considerations need to be added. Using pre-loaded headers and modified Route headers in general should be discussed explicitly. Also modified and pre-loaded Via headers.
• It is up to the policy of the proxy server to know whether or not to accept Route headers.
• This should be clarified in the spec (new RR text) to indicate that pre-loaded headers might exist.
• Partial Route processing should already be covered in the text.
• Issue closed.

409 and the Action Parameter

• If A sends Registrar with an action parameter of “proxy” and B sends same To field with an action parameter of “redirect”.
• Conservative solution: keep action parameter as is, since we don’t know what this means, we reject the conflicting request
• Liberal solution: there are cases where you can reasonably determine what happens, such as method dependent. Allow different actions to be submitted.
• Third solution: recognize a mistake; Action parameter was prior to CPL and better mechanisms are now available. This parameter should not be used any longer in new implementations. Thus, the registrar could “ignore” this or provide the 409 for a conflict.
• HS – Current model using 409 is confusing because two user agents could be conflicting and could have registration problems. You have to look really hard to notice that UA is not registered.
• Is this action parameter useful for new applications? Is it realistic for new/small implementations to support CPL? Is there even a reasonable expectation of the registrar currently implementing the hint for behavior? What happens if there is a conflict between the action parameter and the CPL?
• Application policy is really what should determine this. We don’t need to have text indicating when the application should respond with an explicit error code.
• Action parameter is deprecated. Reg. MAY send a 409.
• Is this parameter useful or not?
• Simplest proposal is to change MUST send 409 to a MAY send 409.
• Action is useful as a hint. There is some language to use it so people want to.
• There is a comparison with unknown parameters that implies we don’t need to have it standardized.
• HS and JR do not want to have a specified item whose meaning is not identifiable.
• Rough consensus to remove action from the spec with a reference that it has historic reference in the RFC.
• Issue closed.

Request-URI Parameters

• Whatever was in the URI to begin with, stays there in the message. Nothing gets stripped out or added.
• Issue closed.

Unknown URI Parameters

• These are allowed, in particular for record-route headers
• Text to be added to the spec for this
• RR text should be clear that these unknown parameters are reflected in the Request-URI
• A proxy that receives unknown parameters in Request-URI just ignores them.
• Issue closed.

Precedence of Route and Request-URI

• What if the domain is mine, but parts of the header are not?
• If we are an outbound proxy, do we take the Request-URI or the Route header to route the call. Does this imply that all outgoing proxies need to record-route?
• Relates to outbound proxies, record routing of outbound proxies.
• This issue discussion fell apart requiring pictures and more thinking.

Attendees

1. Rohan Mahy

2. Robert Sparks

3. Steve Donovan

4. Ben Campbell

5. Alan Johnston

6. James Undery

7. Neal Deeason

8. Dean Willis

9. Itamar

10. Bill Marshall

11. Don Stanwyck

12. Jonathan Lennox

13. Jayshree Bharatia

14. Mary Barnes

15. James Yu

16. Orit Levin

17. Francois Audet

18. Dan Petrie

19. Tom Taylor

20. Robert Freillich

21. Sean Olsen

22. Adam Roach

23. Gonzalo Caramillo

24. Bob Penfield

25. Joerg Ott

26. Brian Rosen

27. Jonathan Rosenberg

28. Jon Peterson

29. David Shrader

30. Henning Schulzrinne

31. Keith Drage