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

> -----Original Message-----
> From: Ian Elz [mailto:[email protected]]
> Sent: Wednesday, November 19, 2008 11:03 AM
>
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email protected]]
> Sent: 19 November 2008 15:19
>
> Can you describe why having a B2BUA generate a Session-ID, if and only
> if one was not in the message already, would be worse than not
> generating one at all?
>
> [Ian Elz ] I don't think that it will be worse but it won't solve the
> problem. The biggest problem with the existing mechanism is that B2BUAs
> map the call-id and tags (if they didn't then they would probably be
> called proxies). The key issue when using the headers and event packages
> which use dialog identities is that you need to route the new request
> through the correct B2BUAs in the correct order to map the dialog
> identity in the header or event correctly. If the session-id is inserted
> by a B2BUA then the issue of routing a new request to this B2BUA still
> exists.

Ahh, but it will solve the problem far more often than not doing anything.  It will work for no matter how many hops after the first one - it just won't work if the new request gets routed *past* the first b2bua that created it.

So, for example:
Let's say your access SBC inserts it (or P-CSCF in IMS terminology).  It always works, because all requests going to the UA endpoint have to get through that node to get to the UA.

Let's say the proxy-registrar does it (the S-CSCF).  It always works, assuming you route requests to such a device before they get to the endpoint/UA.

Let's say the peering SBC does it (the I-BCF), or the app server, feature server, PSTN-gateway, whatever - it only works if the new request which needed the match is routed through that first Session-ID-inserting B2BUA; and that is *still* better than what we have now, which as you said is the new request has to flow back through the whole path.

-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