RE: [SIP] Open Issues BOF Meeting is in Duluth

[Rohan Mahy <[e-mail]>]

FYI: Notes reposted in text if anyone cares....

thx,
-r

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
o       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
Rohan Mahy
Robert Sparks
Steve Donovan
Ben Campbell
Alan Johnston
James Undery
Neal Deeason
Dean Willis
Itamar
Bill Marshall
Don Stanwyck
Jonathan Lennox
Jayshree Bharatia
Mary Barnes
James Yu
Orit Levin
Francois Audet
Dan Petrie
Tom Taylor
Robert Freillich
Sean Olsen
Adam Roach
Gonzalo Caramillo
Bob Penfield
Joerg Ott
Brian Rosen
Jonathan Rosenberg
Jon Peterson
David Shrader
Henning Schulzrinne
Keith Drage


At 09:37 PM 3/20/01 , David Shrader wrote:
>Meeting notes for the issues meeting are attached. Apologies for any 
>editing errors. I wanted to get them out as soon as possible.
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]]On Behalf Of Rosen, Brian
>>Sent: Tuesday, March 20, 2001 11:04 PM
>>To: [e-mail]
>>Subject: [SIP] Open Issues BOF Meeting is in Duluth
>>
>>SIP meeting going on now in Duluth, 3rd floor, Hilton, back corner near 
>>escalator
>>
>>Brian
>>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[e-mail] with "subscribe" in the body.