> -----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
