[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
Dan, Hadriel,
I don't think that having a proxy insert the session-id would be
workable.
Take the following example.
UA-A does not support the session-id so it is not included in the
original request.
UA-A Proxy1 Proxy2 Proxy3 UA-B
| | | | |
| INV B (F1) | | | |
|----------->| INVITE B (F2) | |
| |------------>+----------->+------------>|
| | | | |
| | 200 OK (F3) | |
| 200 OK |<------------+<-----------+<------------|
|<-----------| | | |
F1 INVITE B at home.com
Call-id: 123456789
From: <a at example.com>;tag=98765
To: <b at home.com>
Contact: <A at 192.164.1.1>
F2 INVITE B at home.com
Call-id: 123456789
From: <a at example.com>;tag=98765
To: <b at home.com>
Contact: <A at 192.164.1.1>
Session-id: abcd1234
F3 200 OK
Call-id: 123456789
From: <a at example.com>;tag=98765
To: <b at home.com>;tag=56789
Contact: <B at 164.192.23.35>
Note that as UA-A here does not support the session-id that this has
been inserted by Proxy1.
What happens however if UA-B now tries to SUBSCRIBE to UA-A using the
dialog event.
Assuming the dialog event has been modified to allow the session-id.
UA-A Proxy1 Proxy2 Proxy3 UA-B
| | | | |
| | SUBSCRIBE (F4) | |
| |<------------+<-----------+<------------|
| | | | |
The problem here is how the SUBSCRIBE containing the dialog event
containing a session-id ensures that the new Request on a new dialog is
handled by Proxy1 to map the session-id to the call-id, to-tag, from-tag
format of the dialog event as handled by UA-A.
[If I may be flippant?]. It looks like there is a requirement for a new
header: "Pass-to-this-proxy-at-some-time" to ensure that the correct
proxy is included in the messaging sequence.
You could possibly use a ROUTE header but as UA-B does not know which if
any of the proxies inserted the session-id it would be necessary to
insert all the proxies which inserted themselves in the Record-Route of
F2 as Route headers in F4. This could however result in a lot of proxies
which would not normally want to see the SUBSCRIBE being involved in the
message sequence.
The issue is not as complex for a B2BUA as UA-B could use the Contact
received in F2 as the R-URI in the SUBSCRIBE (F4) which if the B2BUA
mapped the Contact would ensure that the B2BUA which inserted the
session-id would receive the new request.
Ian Elz
System Manager
DUCI LDC UK
(Lucid Duck)
Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz at ericsson.com
-----Original Message-----
From: Dan Wing [mailto:dwing at cisco.com]
Sent: 19 November 2008 19:52
To: 'James M. Polk'; Ian Elz; 'Hadriel Kaplan'
Cc: 'SIP List'
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk at cisco.com]
> Sent: Wednesday, November 19, 2008 1:39 PM
> To: Dan Wing; 'Ian Elz'; 'Hadriel Kaplan'
> Cc: 'SIP List'
> Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
>
> At 08:33 AM 11/19/2008, Dan Wing wrote:
> >
> >
> > > -----Original Message-----
> > > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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.
>
> from that pov, why not have the first SIP server insert the header
> (whether or not it's a B2BUA)?
Absolutely.
-d
> >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
> > > ian.elz at ericsson.com
> > >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing at cisco.com]
> > > 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 sip-implementors at cs.columbia.edu for questions on current sip
> > > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> >Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip