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

Hadriel,

Lets get the discussion back to your draft. While we could debate the
merits of B2BUAs for a long time they exist and do some 'interesting'
things.

My main comment on your draft at present is the proposal to allow a
proxy to insert the session-id header if it has not been inserted by the
UA. I think that this introduces additional problems of how to ensure
that the proxy in included in the message path of a new request that
uses the session-id that it inserted as a reference to the original
dialog.

I have included a few comments below.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email protected]

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

Hi Ian,
Comments inline...

> -----Original Message-----
> From: Ian Elz [mailto:[email protected]]
> Sent: Monday, December 01, 2008 4:35 AM
>
> I know that we have to work with B2BUAs, and I understand the
sentiment
> behind getting rid of them all together. The ietf work tends to
preclude
> handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as
a
> concatenation of the UAC and UAS then all the ietf specifications have
> to ensure is that each Request can be routed to the correct B2BUA and
> then it is up to the B2BUA to ensure that it performs the correct
> actions for the end-to-end service.

This requires 2 things:
(1) that every B2BUA constantly be upgraded to handle whatever new
mechanism's syntax is for the identifiers, every time a new one is
defined. (e.g., new XML schema or new header)  I realize that's the
nature of "you break it, you fix it", but if people want to have their
new thing work without needing B2BUA's to be upgraded or re-configured,
then there needs to be some generic way of handling this.
(2) that the mechanism using the call-id+tags gets sent to the B2BUA
that changed them.  Often it will.  Sometimes it can't.  For example,
the mediactrl-framework model.  Stick a b2bua between the UA and the
Media-Control-Client, and the application doesn't work - or wouldn't
have, except they changed it to use a new identifier different from
call-id to avoid this problem.

[Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an
attempt to give some guidance on how B2BUAs should behave to make them
as proxy like as possible. (2) I am not familiar with the
mediactrl-framework issues when using the call-id. I will look into this
further.


> Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
> globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
> the B2BUA are different dialogs and must have different Call-ids.

Actually that's debatable.  I don't think we'd want to say B2BUA's MUST
change the Call-ID.  3261 did say a B2BUA is the logical concatenation
of a UAS and UAC, but clearly not much text in 3261 was given to how a
B2BUA should operate.

[Ian Elz ] It is debatable but section 8.1.1.4 of RFC 3261 does specify:

"   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA."

Thus as the B2BUA is a concatenation of a UAS and a UAC the UAC when it
creates the ongoing out-of-dialog request must create a call-id which is
globally unique which precludes using the call-id which was received by
the UAS part of the B2BUA.

This is pedantic view of the RFC but those are the words which are
included, agreed and published.

> The major issue which currently occurs is that a PUI is used to try
and
> route a request which should be directed to specific UA, e.g. when
> referencing an extant dialog. To reach the specific UA the Contact
> should be used and if a B2BUA maps the Contact as well as the Call-id
> then the new Request should route to the B2BUA which can perform its
> 'magic' to provide the end-to-end service.

Some folks (from 3gpp) have asked that B2BAU's not change the
contact-uri if it's a GRUU, though I'm not exactly sure why.  There are
also some cases in which having a B2BUA change the contact to be its
specific instance doesn't work, because that address is not globally
reachable; so leaving it as a GRUU (or something like a GRUU), is
necessary but means out-of-dialog requests don't always reach the same
B2BUA instance.  This has been found in REFER transfer cases, where the
referred party can't reach the same B2BUA as the referrer can.

[Ian Elz ] I have seen some of the 3gpp CRs which have suggested making
this change. My present view is that this should not be changed. The
solution may be that a B2BUA inserted contact should always be globally
routable or if the received Contact is a gruu then the inserted Contact
should also be a gruu. There is work to be done in this area.

-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