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

-----Original Message-----
From: Hadriel Kaplan [mailto:[email protected]] 
Sent: 19 November 2008 15:19
To: Ian Elz; Dan Wing
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt



> -----Original Message-----
> From: Ian Elz [mailto:[email protected]]
> Sent: Wednesday, November 19, 2008 6:40 AM
>
> 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.

Can you describe why having a B2BUA generate a Session-ID, if and only
if one was not in the message already, would be worse than not
generating one at all?

[Ian Elz ] I don't think that it will be worse but it won't solve the
problem. The biggest problem with the existing mechanism is that B2BUAs
map the call-id and tags (if they didn't then they would probably be
called proxies). The key issue when using the headers and event packages
which use dialog identities is that you need to route the new request
through the correct B2BUAs in the correct order to map the dialog
identity in the header or event correctly. If the session-id is inserted
by a B2BUA then the issue of routing a new request to this B2BUA still
exists.

> While this draft proposes B2BUA
> actions the defined actions will only occur if the B2BUA fully
> implements this draft.

The draft doesn't say what a B2BUA should do if no header exists.  It
does not say the B2BUA can not generate one in such a case.  I
consciously left that as a possibility, knowing it would be a while
before UAC's would generate one.

[Ian Elz ] Except that we are having a discussion about having a B2BUA
inserting a session-id.


> The bigger issue is what is to stop a B2BUA either removing the
> session-id or generating one of its own.
> 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.]

I'll tackle those in a separate email.

[Ian Elz ] OK. This isn't an issue with the draft just an observation as
to what has happened in the past.


> 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.

Funny you mention it - I was tempted to go do it in the draft, but I
thought it wasn't really the place to do it because the list could
change, and there're a bunch of proprietary ones too, and the goal of
the draft isn't to change them.  So I figured it was better to just give
a couple examples.  But I can certainly do it if you think it would be
useful.

[Ian Elz ] Personally I think that this would be useful (I keep finding
new ones hidden away). It would only be informative at the date of the
draft. I don't think that any proprietary ones should be mentioned, only
those in RFCs.

> Is it proposed to propose modifications to the RFCs for the existing
> headers which use dialog ids to use the session-id?

Nope.  If someone wants to propose that in the future that's up to them,
but I'm not suggesting that for this draft.  I *do* think some of the
XML packages that include them should consider the Session-ID as an
alternative (not a replacement - just an alternative).  But only for the
ones in draft status or proprietary ones, not published RFCs.

[Ian Elz ] OK. This is a problem for the future then. The existing
problems based upon the existing header definitions will and mapping of
the dialog identities will remain for the present. Until these changes
are done however the usage of the session-id will be limited.


> It is probably necessary to specify B2BUA actions in cases of 3PCC and
> what happens to the session-id in these cases.

Would it be any different?

[Ian Elz ] Possibly. In simple 2 party 3PCC then probably not. The B2BUA
can simply generate a session-id and pass it to the parties at both
ends. If you have a more complicated cases involving more than 2 parties
then there may be issues. I will look at these separately.

Thanks for reviewing!

[Ian Elz ] That's fine. I am looking at how the dialog mapping can be
solved in IMS and an end-to-end identifier was one option to be
considered. This gives me the opportunity to examine this option and to
have other people involved.

-hadriel
_______________________________________________
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