B2BUAs being able to generate a new header which contains a string
correlated somehow (e.g. a hash) with the call-ID of the initial dialog
would be, I think, a good idea. There are also two other drafts dealing
with dialog correlation:
http://www.ietf.org/internet-drafts/draft-worley-references-00.txt which
proposes the References-header, containing the Call-ID of the initial dialog
and
http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt
, discussing the requirements for dialog correlation. Both drafts have a
quite different focus but I do not see why we could not use/extend them to
cover the B2BUA scenario. The last draft is on the sipping agenda on
Friday.
Regards
Laura
----- Original Message -----
From: "Dan Wing" <[EMAIL PROTECTED]>
To: "'Ian Elz'" <[EMAIL PROTECTED]>; "'Hadriel Kaplan'"
<[EMAIL PROTECTED]>
Cc: "'SIP List'" <[email protected]>
Sent: Wednesday, November 19, 2008 3:33 PM
Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
-----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. 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
