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

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