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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

The idea (and it may well be a half-baked idea) was to add the Session-ID value into the dialog-event package body (the dialog-info XML doc schema in urn:ietf:params:xml:ns:dialog-info namespace) as another XML element.  In other words, to add a "session-id" element wherever a "call-id" element can also be, such that a consumer of that received XML doc, if it understands that element, could try to match its value to one of its known session-id values for its known dialogs, if and only if the "call-id" one failed to match a call-id.  Likewise for other package XML docs that have "call-id".

For the Replaces/Target-Dialog/etc. SIP headers, one idea would be to add another param similar to the call-id param, for session-id.  But that's just one option.  Option 2 was to in fact keep the Session-ID header itself the same for that out-of-dialog INVITE created by a Refer-To, by embedding the Session-ID header in Refer-To.  There's pro's/con's to either approach, and I don't have an opinion on which is right/wrong/better/worse.

-hadriel


> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Dale
> Worley
> Sent: Wednesday, December 03, 2008 12:40 PM
>
>         From: Hadriel Kaplan <HKaplan at acmepacket.com>
>         Note the "adversary" so to speak is just that a downstream node
>         can get a Call-ID and must not be able to tell from the Call-ID
>         it got, what the Session-ID should be, so they can't tell the
>         Call-ID was changed by a b2bua.  Of course an upstream node
>         would be able to tell - for example the UAC would if it received
>         a subscribe for the dialog-event that had a session-id it
>         created, with a call-id+tags it didn't.  But then one of the
>         main points of this exercise is to make those cases work.  I
>         can't guarantee that all operators would want it to work in such
>         cases, but for those that don't want it to, nothing will help us
>         make it work.
>
> There's something I don't understand here.  You mention "received a
> SUBSCRIBE for the dialog-event that had a session-id it created, etc."
> What does that mean?  I assume you mean that the UAS of the original
> call (or something in its near network vicinity) wanted to subscribe to
> the dialog events of the UAC, filtering for the one dialog it knows of.
> That would be:
>
>         SUBSCRIBE [contact taken from INVITE seen at UAS] SIP/2.0
>         Call-Id: [something new]
>         Session-Id: [something new]
>         Event: dialog;session-id=[session-id of INVITE]
>
> That would go back through the B2BUA (or one of its brethren) because
> the Contact as seen at the UAS was munged as necessary by the B2BUA to
> ensure that that would happen.  The B2BUA would change the Call-ID, but
> it would leave the Session-Id and the Event session-id parameter
> unchanged.
>
> But there would be nothing to compare the Event session-id parameter
> *to*.  And the Session-Id would have no apparent relationship to the
> Call-Id or tags of the SUBSCRIBE as seen at the original UAC (the UAS of
> the SUBSCRIBE).
>
> Dale
>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip