Subject: Re: [Sipping] Comments on draft-marjou-sipping-b2bua-00.txt

From: "Ian Elz (CV/ETL)" <[email-masked]>
Date: Mon, 16 Jul 2007 16:13:23 +0200

Prince,

Further to the questions you raised (below).

The new version of the b2bua draft is now available and can be obtained
from http://www.who-elz.com/drafts/draft-marjou-sipping-b2bua-01.txt.

You will see that there are now new sections covering handling of the
dialog reference headers (Replaces, Target-Dialog, Join and
in-Reply-To). The first 3 of these headers are similar in that all
require that the referenced dialog exists at the time the new Request is
handled. In-Reply-To is different in that there is no requirement for
the referenced dialog to exist at the same time as the referencing
dialog.

The requirements of RFCs 3891 (replaces), 3911 (Join) and 4538
(Target-Dialog) that the referenced dialog must be matched in the
receiving UAS or the request containing the dialog reference header may
be rejected. [Target-Dialog does allow for the header to be ignored but
authorisation may be obtained by other means (?).] These requirements
require that the dialog reference header must be mapped through a b2bua
so that the correct dialog values are presented to the UAS. 

To perform this mapping it is necessary to ensure that the Request is
presented to the correct b2bua. This may be achieved by using the
Contact obtained from the referenced dialog as the Request URI in the
new dialog. This is explicitly stated in RFC 4538 Section 2 but must be
assumed for the other headers (Replaces, Join) as it is necessary to
send the Request to the same UA as is handling the referenced dialog.
Sending the new Request to the AOR may result in the Request being
forwarded to another UA. To ensure that the b2bua is addressed the b2bua
MUST map the Contact in the initial request. Thus when a new Request is
sent to the Contact with a dialog reference header it will initially be
directed to the b2bua as it is the contact  used as the Request URI. The
b2bua must then map the Request URI to the Contact it has obtained from
the referenced dialog. This will either be the final UA or possibly
another b2bua Contact.

This is shown in the examples in sections 5.2 and 5.3 of
draft-marjou-sipping-b2bua-01. 

You will note that these examples also show differing methods of
handling the Replaces header parameter in a Refer-To header. There are
two options shown:
*	Map the Replaces value when possible when the REFER is handled
and ignore it when mapping is not possible
*	Ignore this parameter when handling the REFER and leave the
mapping until the subsequent Request is handled.

With regard to your question relating to Route headers.

The normal situation would be that Route headers only apply for each
dialog and hence there would be a separate set of Route headers in each
separate dialog, i.e. each side of a b2bua. This is the normal case as
the Route headers are derived from the Record-Route headers received and
these are not passed across the b2bua.

The exception with the Route header is when pre-loaded Route headers are
used. The main example of this is in the IMS where the S-CSCF includes
Route headers in the initial request to the AS. The S-CSCF included 2
Route headers. One is for the AS, which the AS removes, with the second
being for the S-CSCF itself. This ensures that the Request is routed
back to the S-CSCF so that any additional AS can be invoked via the IFC
(filtering criteria). This is discussed in section 4.1.3 of the draft.

Ian Elz

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

Message: 2
Date: Tue, 12 Jun 2007 09:59:01 +0530
From: [email-masked]
Subject: [Sipping] Comments on draft-marjou-sipping-b2bua-00.txt
To: [email-masked]
Cc: [email-masked]
Message-ID:
	
<OF6AF8DC9D.84C0B5BB-ON652572F8.00188906-652572F8.0018ED14@flextronicsso
ftware.com>
	
Content-Type: text/plain; charset="us-ascii"

Hi  Marjou,

Here is few enhancements required on this draft.

1) The behavior of the Transparent B2BUA is not defined when any dialog
info carrying SIP header is received in a Request.
        What should be the behavior of this B2BUA when an INVITE with
Replaces(3891) is received? what about 
        Traget-Dialog?
        Currently this draft just tells that "The UAC SHOULD copy other
header fields and body from
        the upstream request into this downstream request before sending
it"

2) Is it correct to copy the Route headers from upstream to downstream?
        a) What about if the B2BUA has a configured pre-loaded route
set?
        c) It is acting as a pure UA (B2BUA) w.r.t Record-Route header.
        b) From section 3 of this draft :  Hide topology information,
for example in the Call-ID,
        Via, Route, Record-Route, Contact header fields.
        So copying Route headers is not so correct w.r.t Topology
hiding.

Thanks & Regards,

Prince Arimboor
Senior Technical Leader
 
A R I C E N T
 
#7, 4th Floor, Sigma Softtech Park
Whitefield main Road,
Bangalore 560066, India
Main     +91 80.4106.9010
Fax      +91 80.4106.9500

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 10:43:21 -0400

Note that there is considerable overlap between this draft and 
http://www.ietf.org/internet-drafts/draft-munakata-sip-privacy-guideline-00.txt. 
It would be good to ensure that these align.

More inline.

	Paul

Ian Elz (CV/ETL) wrote:
> from _http://www.who-elz.com/drafts/draft-marjou-sipping-b2bua-01.txt_.
> 
> the referenced dialog to exist at the same time as the referencing dialog.
> 
> forwarded to another UA.

This is well trodden ground for Replaces, ignoring the issues added by 
B2BUAs.

While Replaces only works when received by the UA containing the 
referenced dialog, it can work, with some limitations, when sent to the 
AOR. In that case hopefully the request will be forked. Targets lacking 
the dialog will immediately fail, while the one with the correct dialog 
will be able to succeed.

While there are limitations in this approach, I have the impression that 
it is used in the wild. Its part of the general fallback when you don't 
believe that contacts are globally routable.

If your B2BUA *depends* on the other UAs always sending this sort of 
request to the Contact from the original dialog then you had better be 
very careful to document the limitations this implies.

> To ensure that the b2bua is addressed the b2bua 
> MUST map the Contact in the initial request.

IMO if you have a server that *doesn't* substitute its own contact 
address in dialog forming requests then it isn't an B2BUA. If it *does* 
substitute its own then of course it must map that address in subsequent 
requests.

> Thus when a new Request is 
>           o Map the Replaces value when possible when the REFER is
>             handled and ignore it when mapping is not possible
>           o Ignore this parameter when handling the REFER and leave the
> /Ian Elz/
> /Office: + 44 24 764 35256/
> /gsm: +44 7801723668/
> /[email-masked]/
> 
> Message: 2
> <[email-masked]> 
> 
>        
>         a) What about if the B2BUA has a configured pre-loaded route set?
>         So copying Route headers is not so correct w.r.t Topology hiding.
> 
> 
> Thanks & Regards,
> 
> Prince Arimboor
> Senior Technical Leader
>  
> A R I C E N T
>  
> ------------------------------------------------------------------------
>

---

From: "Ian Elz (CV/ETL)" <[email-masked]>
Date: Tue, 17 Jul 2007 10:08:10 +0200

Paul,

Comments inline.

Ian Elz

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 16 July 2007 15:43
> To: Ian Elz (CV/ETL)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Comments on draft-marjou-sipping-b2bua-00.txt
> 

[Ian Elz] We will examine this draft to look at the overlaps and see
what can be done to align them.

> > The new version of the b2bua draft is now available and can be 
> > obtained from 
> _http://www.who-elz.com/drafts/draft-marjou-sipping-b2bua-01.txt_.
> > 
> > require that the referenced dialog exists at the time the 
> new Request 
> > is handled. In-Reply-To is different in that there is no 
> requirement 
> > for the referenced dialog to exist at the same time as the 
> referencing dialog.
> > 
> > receiving UAS or the request containing the dialog reference header 
> > may be rejected. [Target-Dialog does allow for the header to be 
> > ignored but authorisation may be obtained by other means 
> (?).] These 
> > requirements require that the dialog reference header must 
> be mapped 
> > through a b2bua so that the correct dialog values are 
> presented to the UAS.
> > 
> > new dialog. This is explicitly stated in RFC 4538 Section 2 
> but must 
> > be assumed for the other headers (Replaces, Join) as it is 
> necessary 
> > to send the Request to the same UA as is handling the 
> referenced dialog.
> This is well trodden ground for Replaces, ignoring the issues 
> added by B2BUAs.
> 
> While Replaces only works when received by the UA containing 
> the referenced dialog, it can work, with some limitations, 
> when sent to the AOR. In that case hopefully the request will 
> be forked. Targets lacking the dialog will immediately fail, 
> while the one with the correct dialog will be able to succeed.

[Ian Elz] This situation will probably not work in a network where
B2BUAs are deployed. If the B2BUA has mapped one of the parameters which
makes up the Replaces (Call-Id, To- Tag, From-Tag) then the subsequent
Request;Replaces would have to be passed to the same B2BUA using the AOR
to allow for the Replaces header to be mapped correctly. This may work
in a relatively simple network where only a single B2BUA is deployed but
in a more complex network with multiple B2BUA, e.g. SBC's and AS's then
the probability that the AOR would be routed to the correct B2BUAs in
the correct order would be most unlikely. Thus the probability is that
the Request will be rejected.

> 
> While there are limitations in this approach, I have the 
> impression that it is used in the wild. Its part of the 
> general fallback when you don't believe that contacts are 
> globally routable.

[Ian Elz] You must assume that the Contact provided by a B2BUA is
globally routable. This may cause issues if the B2BUA is behind a NAT
but the same applies to a Contact provided by a UA where the UA is
behind a NAT. if the B2BUA is behind a NAT then it should provide a
GRUU. There are issues relating to GRUU and B2BUAs which are still to be
examined. This ensures that when the Contact is used in the Request
which references an existing dialog the Request will be passed to the
correct B2BUA.

> 
> If your B2BUA *depends* on the other UAs always sending this 
> sort of request to the Contact from the original dialog then 
> you had better be very careful to document the limitations 
> this implies.

[Ian Elz] This is more a question of B2BUA implementation. If the B2BUA
performs its logic based upon the presence of the dialog reference
headers rather than the content of the Request URI then there should not
be an issue. If there are B2BUAs in the message path then to allow the
dialog reference header to be mapped then the new Request must be passed
via the B2BUAs in the correct order to allow the dialog reference header
to be mapped correctly.

> 
> > To ensure that the b2bua is addressed the b2bua MUST map 
> the Contact 
> > in the initial request.
> 
> IMO if you have a server that *doesn't* substitute its own 
> contact address in dialog forming requests then it isn't an 
> B2BUA. If it *does* substitute its own then of course it must 
> map that address in subsequent requests.

[Ian Elz] I think that we are in agreement on this. There may be B2BUAs
which do not insert their own Contact in the Request and Response. This
type of B2BUA is not covered by the draft as handling of the dialog
reference headers requires that the Contact be inserted by the B2BUA to
enable the correct mapping of the of the dialog reference headers.

> > sent to the Contact with a dialog reference header it will 
> initially 
> > be directed to the b2bua as it is the contact  used as the Request 
> > URI. The b2bua must then map the Request URI to the Contact it has 
> > obtained from the referenced dialog. This will either be 
> the final UA 
> > or possibly another b2bua Contact.
> > 
> > dialog and hence there would be a separate set of Route headers in 
> > each separate dialog, i.e. each side of a b2bua. This is the normal 
> > case as the Route headers are derived from the Record-Route headers 
> > received and these are not passed across the b2bua.
> > 
> > The exception with the Route header is when pre-loaded 
> Route headers 
> > are used. The main example of this is in the IMS where the S-CSCF 
> > includes Route headers in the initial request to the AS. The S-CSCF 
> > included 2 Route headers. One is for the AS, which the AS removes, 
> > with the second being for the S-CSCF itself. This ensures that the 
> > Request is routed back to the S-CSCF so that any additional 
> AS can be 
> > invoked via the IFC (filtering criteria). This is discussed 
> in section 4.1.3 of the draft.
> > 
> > 
> > 
> > /Ian Elz/
> > 
> > 1) The behavior of the Transparent B2BUA is not defined when any 
> > dialog info carrying SIP header is received in a Request.
> > 
> >         Currently this draft just tells that "The UAC SHOULD copy 
> > other header fields and body from
> >         the upstream request into this downstream request before 
> > sending it"
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
>