Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

At 08:33 AM 11/19/2008, Dan Wing wrote:
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of Ian Elz
> > Sent: Wednesday, November 19, 2008 5:40 AM
> > To: Dan Wing; Hadriel Kaplan
> > Cc: SIP List
> > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> >
> > Dan, Hadriel,
> >
> > I don't think that having the first B2BUA synthesize the session-id
> > would work. The idea is to have it end-to-end to solve the problem so
> > having it put in by a B2BUA would not solve the problems.
>
>Yes.  But until UAs generate the header, the best you can do is have
>the first B2BUA insert the header for the benefit of the rest of the
>SIP network.

from that pov, why not have the first SIP server insert the header 
(whether or not it's a B2BUA)?

>This is akin to the 'authentication proxy' described
>in RFC4474, where the proxy inserts the authentication headers if
>the UA hasn't done so.
>
> > The bigger issue is what is to stop a B2BUA either removing the
> > session-id or generating one of its own.
>
>Nothing stops the B2BUA from doing anything it wants.
>
> > While this draft proposes B2BUA
> > actions the defined actions will only occur if the B2BUA fully
> > implements this draft.
>
>That is correct.
>
>Is the draft complex to implement?
>
> > RFC 3261 defines a B2BUA as a concatenation of a UAS and a UAC. What
> > happens between the UAS and UAC parts is undefined and there is no
> > specification as to what actions the B2BUA should take when passing a
> > request from the UAS to the UAC. There was a draft presented to the
> > sipping wg to try an define actions of B2BUAs but this was
> > rejected by a
> > hum as dangerous. I guess that the consensus was that the B2BUA should
> > remain totally undefined so that it could perform any action that was
> > required. [Declaration of interest: I was a contributor to this now
> > expired draft.]
>
>Hadriel's draft attempts to do the opposite:  instead of defining
>"these are the things a B2BUA is allowed to do", it is saying "a
>B2BUA, compliant with this specification, will pass the session-id
>header".
>
>-d
>
>
> > Hadriel,
> >
> > A couple of additional items which may need to be considered in the
> > draft.
> >
> > Is it possible to include a list of headers which currently use the
> > existing dialog identifiers? Others which you have not
> > mentioned include
> > Target-dialog, Join and In-reply-to.
> >
> > Is it proposed to propose modifications to the RFCs for the existing
> > headers which use dialog ids to use the session-id?
> >
> > It is probably necessary to specify B2BUA actions in cases of 3PCC and
> > what happens to the session-id in these cases.
> >
> >
> > Ian Elz
> >
> > System Manager
> > DUCI LDC UK
> > (Lucid Duck)
> >
> > Office: + 44 24 764 35256
> > gsm: +44 7801723668
> > [email protected]
> >
> > -----Original Message-----
> > From: Dan Wing [mailto:[email protected]]
> > Sent: 19 November 2008 06:24
> > To: 'Laura Liess'; 'Hadriel Kaplan'; 'SIP List'
> > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> >
> > > The problem which I  have with this particular solution
> > > is that it requires changes in existing user devices.
> >
> > For UAs that don't generate session-id the first B2BUA
> > could synthesize a session-id.
> >
> > -d
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email protected] for questions on current sip
> > Use [email protected] for new developments on the application of sip
>
>_______________________________________________
>Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email protected] for questions on current sip
>Use [email protected] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip