At 12:49 AM 11/19/2008, Hadriel Kaplan wrote:
Yeah I was going to mention that but I thought it would seem almost
hypocritical. :)
But it's true really - the draft is about B2BUA's not changing a
Session-ID they received.
maybe its also about the first B2BUA inserting one where there isn't
(on the UAS back side), and not changing it on the UAC back side -
then just in general about not having any subsequent SIP
server/B2BUA/SBC changing a received session-id, maybe
It doesn't say they can't mint a new one if one was NOT received,
and indeed I would expect that's exactly what they'd do if the UAC
didn't do it itself. It would make it less useful for some of the
use-cases, but it's better than nothing, and hopefully the header is
such a trivial concept that UA's would implement it.
-hadriel
> -----Original Message-----
> From: Dan Wing [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 19, 2008 1:24 AM
> 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
