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

["Ian Elz" <[e-mail]>]

Hadriel,

May I take issue with your final statement "It won't solve all
scenarios, but that's ok - it's making it better than nothing."

Having something incomplete may be worse than nothing. We may have a
scenario where the partial solution gets implemented and then it will be
impossible to implement a final solution as you are required to be
backward compatible to the partial solution.

Let's try and get all the known problems out of this before it is
published. If as a result it only specifies the originating UAC
including the session-id then so be it. I don't want to get to a point
where middle node insert of modify the session-id and then have to
continue to support that scenario into the future.

That is not to say that all the problems will be identified. That only
happens when someone else tries to do something else in the future.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: [phone]
[e-mail]


-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: 28 November 2008 03:07
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,
Thanks for your comments.  I should publish the update to this draft,
because it now covers the middlebox-insertion-case in text, whereas
before it was implicit.  And it adds text for UAC generation that was
incomplete, because I forgot to put a critical aspect to this in the
original draft about matching.

The basic concept is that if we want it to be usable as an alternative
dialog-matching mechanism for out-of-dialog requests, then whomever
generates a session-id has to have a local session-id lookup table, as
does any device needing to perform matching.  That table would simply be
a session-id value to dialog table, used for matching the value to a
dialog.

If a device doesn't do this, then we get the troubleshooting properties
but not the dialog-matching one, if a request gets to that specific node
and the real dialog+tags don't match.

But it's true this would mean a Proxy that generates it *and* wanting to
provide the matching property would need to be record-routing and have
such a table, making it more stateful.

With regard to the issue not being as complex for B2BUA's because UA-B
would send it to the B2BUA's contact:
Just being a B2BUA doesn't solve the problem without the match table
being done somewhere.  The problem with dialog-event and such in
out-of-dialog requests is not that B2BUA's can't "fix" it and set the
contact to themselves to make sure they get the request - they do that
already.  The problem is some of the requests aren't sent to their
contact-URI to begin with.

For example, in the Derive case it's sending it to the From-URI, which
B2BUA's sometimes do also change (ugh), but normally/hopefully to their
domain not their hostname/IP; or better yet they leave it alone.  [I
think that Derive is actually incorrect in sending it to the From-URI
AoR, because it means the Derive message can end up at any contact for
the AoR]

But the bigger issue is even if such things get sent to Contact-URIs and
the Contact-URI's are GRUU's, in theory the GRUU does not specify a
specific B2BUA instance, but instead the whole domain and thus can hit
any number of B2BUA's getting into that domain.  We have been asked by
some people in the IETF to leave contact GRUU's alone, and not replace
them with the B2BUA's contact.  We'd be happy to do that if we can make
requests going to the GRUU work, which without this type of matching
mechanism they won't.

Ultimately the matching and troubleshooting properties work best if UA's
generate the session-id themselves, and I hope it's simple enough that
they do - but in the meantime B2BUA's or stateful proxies can do it for
them to get it off the ground.  It won't solve all scenarios, but that's
ok - it's making it better than nothing.

-hadriel

> -----Original Message-----
> From: Ian Elz [mailto:[e-mail]]
> Sent: Thursday, November 27, 2008 11:31 AM
> To: Dan Wing; James M. Polk; 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 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 [e-mail]
>    Call-id: 123456789
>    From: <[e-mail]>;tag=98765
>    To: <[e-mail]>
>    Contact: <A@192.164.1.1>
>
> F2 INVITE [e-mail]
>    Call-id: 123456789
>    From: <[e-mail]>;tag=98765
>    To: <[e-mail]>
>    Contact: <A@192.164.1.1>
>    Session-id: abcd1234
>
> F3  200 OK
>    Call-id: 123456789
>    From: <[e-mail]>;tag=98765
>    To: <[e-mail]>;tag=56789
>    Contact: <B@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
>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip