Subject: RE: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt

From: "Christian Stredicke" <[email-masked]>
Date: Wed, 18 May 2005 21:09:22 +0200

I hope we are almost there, comments inline.

CS 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, May 18, 2005 3:46 PM
> To: Christian Stredicke
> Cc: [email-masked]; Johnston, Alan; [email-masked]
> Subject: Re: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt
> 
> Christian,
> 
> I think I am almost finished here. I've trimmed the 
> conversation a lot 
> in hopes of making it readable and to focus on remaining points.
> 
> 	Paul
> 
> Christian Stredicke wrote:
> 
> >>Just a requirement for a *single* configurable pattern that can:
> >>- insert an arbitrary scheme at the front,
> >>- parameters after the number and before the "@",
> >>- a domain name that might be different from the outbound proxy,
> >>- and parameters after the domain name
> >>
> >>Would be a huge improvement over a device that always just slapps
> >> "sip:" at the front and "@"+proxy-name at the back.
> > 
> > Okay. What about the following wording?
> > 
> > "Req-17: SIP telephony devices MAY support a local dial plan.  If a
> > dial plan is supported, it MUST be able to match the user input to
> > one of multiple pattern strings and transform the input to a URI,
> > including an arbitrary scheme and URI parameters."
> 
> I think that is close. I'm struggling with whether or not to 
> complicate 
> it to cover all the issues. Perhaps this is close enough. I 
> presume the 
> next step is to use these requirements to drive a common schema for 
> configuration. At that point these things can be dealt with in detail.
> 
> (The thing I am thinking the above may technically miss is 
> that in a URI 
> like <sip:4321;phone-context=[email-masked];user=phone>, 
> "user=phone" 
> is a URI parameter, but "phone-context=foo.com" is not.)

This is just a requirement, there will be of course a lot of detail work
about how to do it. We used the NAPTR scheme to do this, but every
vendor can do it in a different way. I would propose that we keep this
requirement in this generic way.

> 
> > Req-17 states that the phone will generate anything that is
> > configured in the dial plan, including a URI according to RFC
> > 3966.
> > 
> > Now Req-18 deals with the semantics of one specific URI type. It
> > is clear that a phone must be able to receive RFC 3966 URI. But it
> > must also be able to send a request with that URI set, what else
> > should it do when a user enters such a URI (possibly through the
> > dial plan)?
> > 
> > Lets say "Req-18: SIP telephony devices MUST support URIs for
> > Telephone numbers as per RFC 3966 [9]. This includes the
> > receiption as well as the sending of requests. It is a reasonable
> > behavior to send a request to a preconfigured outbound proxy."
> 
> OK. I think that is better.
> 
> >>>>>Req-19: SIP telephony devices MUST support REFER and NOTIFY as 
> >>>>>        required to support call transfer [45], [46]. SIP 
> >>>>>        telephony devices MUST support escaped headers in the
> >>>>>        Refer-To header.  
> >>>>
> >>>>Need to be clearer what is meant by "support escaped headers".
> 
> >>>>RFC 3261 section 19.5.1 specifies what is to be done with header
> >>>>parameters. Putting them into the message is SHOULD strength for
> >>>>some, SHOULD NOT for some others. But the ones that are SHOULD
> >>>>strength is not precisely specified. I think its important to
> >>>>specify which must also be placed into a message.
> >>>
> >>>Of course we are talking about the 
> bla?Replaces=123%3Abla.com stuff.
> >>
> >>Are you *only* concerned with the Replaces header? Probably 
> there are 
> >>others that are important.
> >
> > Well, I don't want to repeat the discussion of the algorithm
> > described in RFC 3261.
> 
> Agree - the point is not to repeat that. I think the point is to go 
> beyond that with additional requirements where that is necessary to 
> achieve the desired functionality.
> 
> > Lets put it that way, I would leave the
> > treatment of Route, Max-Forwards etc. open.
> 
> Yes.
> 
> >>My intent was to strengthen the requirement, not weaken it.
> >>As 3261 is worded, it appears to be up to the UA to decide if a 
> >>particular header is safe enough to honor, so it would be 
> free to say 
> >>"yes, I support header parameters, but I just don't 
> consider Replaces 
> >>safe, so I don't honor it."
> >>
> >>So I think you probably need to list the particular headers 
> that must
> >> be honored so that important call flows work.
> > 
> > We don't want to open a beauty contest of what header could
> > possible be useful in this context.  I would say lets make the
> > Replaces a MUST and anything else according to RFC3261.
> 
> It seems like there are two choices of approach here:
> - open the beauty contest. List exactly those headers that
>    are needed to make important call flows work.
>    (The standard of beauty is determined by the call
>    flows that are selected and the header parameters they
>    require.)
> 
> - establish independent criteria for determining if headers
>    are "safe". Then require devices to honor the safe ones.
> 
> The second approach might be better in the long run, but I 
> don't think 
> it is the place of a document like this to do that. The 
> beauty contest 
> approach at least has clear criteria, so is probably the pragmatic 
> choice here. I haven't checked - is "Replaces" the only one that is 
> needed to make the important call flows work? If so then your 
> proposal 
> seems right.

At the moment I only see the need for the Replaces header. Then lets
nail down the Replaces header and leave the rest optional.

> 	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2005 15:44:49 -0400

I'm fine with this.

	Paul