Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 13 Dec 2011 12:44:16 +0000

Paul/Hadriel,

I understand that most of the folks are interested in session-id for
Troubleshooting and logging purposes as per the earlier discussions.
I agree with Paul that we will define the rules for session-id and it 
may not possible to restrict the usage of the session-id to 
troubleshooting only.  But it is important for IETF to make sure that the
proposed session-id mechanism does not leads to any new security issues 
or SIP architectural issues and I'm interested in hearing those caveats 
in the session-id.

In case of SBC kind of devices, it may violates even basic RFC 3261 and so, 
IETF may not be enforce any rule to it. On the other hand, SBC is
flexible to pass across if "clever mechanism" is proposed by the customer.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Paul E. Jones
>Sent: Wednesday, November 16, 2011 11:10 PM
>To: 'Hadriel Kaplan'
>Cc: [email-masked]
>Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to
>two endpoints
>
>Hadriel,
>
>> > I do not propose that the WG do anything with the Session-ID.  I
>> > only want us to define one where all devices have a common
>> > understanding of what the value is.  Once we do that, then we can
>> > actually rely on it for something else meaningful.  But, that will
>> > be another WG and another charter ;-)
>>
>> The big concern I have with anyone using the Session-ID for anything
>> other than troubleshooting/logging, is that SBCs will invariably end
>> up having to go change the Session-ID in certain call scenarios to
>> purposefully be something that does not match both sides, simply to
>> counter-act whatever clever mechanism someone's decided to use
>> Session- ID for.  There are lots of reasons that could happen, from
>> fixing bugs to fixing scenarios their clever scheme didn't take into
>> account and breaks stuff for, to just plain not wanting the clever
>> mechanism to happen due to some policy reasons.  If that happens, we
>> lose the ability to use Session-ID for troubleshooting.
>
>I would hope people do not introduce "clever" mechanisms.  I'd very much
>like the rules to be well-defined.  Once the rules are defined, then we
>could use Session-ID for other things, but I would not expect there to
>be changes to SIP as a result.  For SIP, there should one and only one
>way of signaling the Session-ID.  With those well-defined rules, then we
>should be able to rely on it for other things, but I don't want to
>define those other things yet.  If all we get is logging, then it's
>still worth the effort.  I just hope we can use it more broadly.
>
>> We've gone over examples of cases where that could happen in email
>> threads of my earlier Session-ID drafts, which is why I ended up
>> changing the drafts to *only* make it used for
>logging/troubleshooting.
>
>If we work through use cases and hit a wall, that would be reason for
>concern.  I do think we can make it work, though.  It would require
>functionality on the B2BUA that decides to re-route calls, etc., but
>that will happen with time.
>
>> I know some people in the IETF don't care much about having a header
>> value purely for troubleshooting correlation, but we hear this desire
>> time and time again from the people who run/manage SIP networks. (I'm
>> not saying you don't want that too - I'm just saying a header for
>> troubleshooting alone is worth having)
>
>So, aim high... :)
>
>Paul
>
>
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Dec 2011 16:26:35 -0500

Partha,

No matter what the purpose is for a Session-ID, whether it is logging,
associating two endpoints in a call, associating media flows with a call,
etc., we have the same challenges in trying to define an identifier that is
appropriate.  What we propose in the Session-ID draft, we believe, meets the
requirements and addresses shortcomings in current SIP and H.323 identifiers
that were intended to serve the purpose of identifying calls end-to-end.

That said, I'm happy to debate the technical aspects of our or other
proposals.  However, we can't seem to get to a point where we can agree on a
charter where we can actually do the work.  I understand we don't want a
working group that just flounders, but I do not believe that will be the
case.  I very much want to get the working group started so we can progress
the work.

Paul

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2011 7:44 AM
> To: Paul E. Jones; 'Hadriel Kaplan'
> Cc: [email-masked]
> Subject: RE: [dispatch] Session-Id: Problem 3: A session is limited to
> two endpoints
> 
> Paul/Hadriel,
> 
> troubleshooting only.  But it is important for IETF to make sure that
> the proposed session-id mechanism does not leads to any new security
> issues or SIP architectural issues and I'm interested in hearing those
> caveats in the session-id.
> 
> In case of SBC kind of devices, it may violates even basic RFC 3261 and
> so, IETF may not be enforce any rule to it. On the other hand, SBC is
> >I would hope people do not introduce "clever" mechanisms.  I'd very
> >much like the rules to be well-defined.  Once the rules are defined,
> >then we could use Session-ID for other things, but I would not expect
> >there to be changes to SIP as a result.  For SIP, there should one and
> >only one way of signaling the Session-ID.  With those well-defined
> >rules, then we should be able to rely on it for other things, but I
> >don't want to define those other things yet.  If all we get is logging,
> >then it's still worth the effort.  I just hope we can use it more
> broadly.
> >