Re: 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 [email protected]
   Call-id: 123456789
   From: <[email protected]>;tag=98765
   To: <[email protected]>
   Contact: <[email protected]>
   
F2 INVITE [email protected]
   Call-id: 123456789
   From: <[email protected]>;tag=98765
   To: <[email protected]>
   Contact: <[email protected]>
   Session-id: abcd1234

F3  200 OK
   Call-id: 123456789
   From: <[email protected]>;tag=98765
   To: <[email protected]>;tag=56789
   Contact: <[email protected]>


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
[email protected]


-----Original Message-----
From: Dan Wing [mailto:[email protected]] 
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:[email protected]] 
> 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: [email protected] [mailto:[email protected]] 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
> > > [email protected]
> > >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:[email protected]]
> > > 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 [email protected] for questions on current sip
> > > Use [email protected] 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 [email protected] for questions on current sip
> >Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip