Subject: RE: [Sip] CallId question

From: "Eric Burger" <[email-masked]>
Date: Wed, 18 Feb 2004 16:13:17 -0500

I concur (make it token).

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, February 18, 2004 3:28 PM
> To: Eric Burger
> Cc: Paul Kyzivat; Anil Bollineni; [email-masked]
> Subject: RE: [Sip] CallId question
> 
> 
> I would like to see us revisit the BNF for Call-ID at
> some point and explicitly make its value a single bundle
> of opaque bits.
> 
> It almost is already - it is defined as word @ word
> (NOT word @ host). 
> 
> There are implementations that have been mislead by
> the recommendation to use a host for the second
> word (as a source of probably-unique bits) into
> _parsing_ that field from received messages as 
> a host (as defined in the BNF in 3261), and 
> rejecting messages (or breaking) when the bits
> they found didn't line up.
> 
> I'm willing to bet that a very large subset of
> the existing implementations in the world would
> not deal with two "@" signs show up gracefully.
> (Something to add to the torture tests maybe).
> 
> We can make this less likely to occur in the future.
> 
> RjS
> 
> On Wed, 2004-02-18 at 10:09, Eric Burger wrote:
> > Good point -- if you are going to be a B2BUA, you have to 
> follow the *UA* rules, e.g., generate new, unique Call-Id's.
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:[email-masked]]
> > > Sent: Wednesday, February 18, 2004 10:59 AM
> > > To: Eric Burger
> > > Cc: Anil Bollineni; [email-masked]; Cullen Jennings
> > > Subject: Re: [Sip] CallId question
> > > 
> > > 
> > > I agree that you shouldn't muck with the call-id, but for 
> different 
> > > reasons. From 3261:
> > > 
> > >     In a new request created by a UAC outside of any dialog, 
> > > the Call-ID
> > >     header field MUST be selected by the UAC as a globally unique
> > >     identifier over space and time unless overridden by 
> > > method-specific
> > >     behavior.  All SIP UAs must have a means to guarantee 
> > > that the Call-
> > >     ID header fields they produce will not be inadvertently 
> > > generated by
> > >     any other UA.
> > > 
> > > A UA behind a NAT can't use its IP address in its call-id 
> > > because that 
> > > won't be guaranteed to be unique. It might be able to use its 
> > > DNS name. 
> > > If it doesn't have one, then it is still obligated to 
> come up with 
> > > something unique. Otherwise it is just broken.
> > > 
> > > 	Paul
> > > 
> > > Eric Burger wrote:
> > > > Upon reflection, this is an interesting theoretical problem 
> > > that statistically is not a problem.
> > > > 
> > > > What is a Call-Id?  It is an opaque, globally unique string 
> > > generated by the UAC.  To promote uniqueness, 3261 requires a 
> > > string identifying the UAC, either IP address or hostname.  
> > > Note that NOTHING in SIP places semantics on the host part of 
> > > the Call-Id.
> > > > 
> > > > So, in reality, don't bother to mung the Call-Id.  What is 
> > > the likelihood of two UAC's having the following properties 
> > > AT THE SAME TIME:
> > > > 	same randomly generated LHS (unlikely, but possible)
> > > > 	same IP address (possible)
> > > > 	same destination (very unlikely)
> > > > 
> > > > IIF all of these conditions are SIMULTANEOUSLY true, then 
> > > there is a problem, in that there will be two dialogs with 
> > > the same dialog identifier.  You've got bigger problems then 
> > > what to change an IP address to :-)
> > > > 
> > > > 
> > > > That said, if the reason you are munging the Call-Id host 
> > > part is for network hiding, then you really, really, really 
> > > should be hacking the user part, as well.  I'll leave the 
> > > security considerations section as an exercise for the reader.
> > > > 
> > > > P.S., this whole thing breaks lots of stuff.  I'm sure 
> > > Henry will revoke my License to SIP for even explaining 
> some of it :-)
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Cullen Jennings [mailto:[email-masked]]
> > > > Sent: Tuesday, February 10, 2004 6:34 PM
> > > > To: Anil Bollineni; [email-masked]
> > > > Subject: Re: [Sip] CallId question
> > > > 
> > > > 
> > > > 
> > > > The NAT/FW must not go changing this stuff. If it does, a 
> > > S/MIME signed sipfrag will fail. There is no need for the NAT 
> > > to go change call IDs
> > > > 
> > > > 
> > > > 
> > > > On 2/10/04 12:27 PM, "Anil Bollineni" 
> > > <[email-masked]> wrote:
> > > > 
> > > > 
> > > > Hello,
> > > >  
> > > >             I have a question about CallId. Suppose two 
> > > UA's generate callid's putting theire hostnames and send to 
> > > firewall/NAT.
> > > >             UA1:INVITE
> > > >                  CallID: [email-masked]
> > > >             UA2: INVITE
> > > >                     CallId: [email-masked]
> > > >             
> > > >             Because those callid information contain IP 
> > > addresses, the firewall/NAT should translate these IP 
> > > addresses by putting it's own IP in callId. The callId's are 
> > > changed to call1@firewall_ip, call1@firewall_ip. When 
> > > responses come back from their respective UAS's the 
> > > firewall/NAT translates the it's IP address in callId's to 
> > > their original IP's. My question is should I change the 
> > > string "call1" to something generated by firewall or Is it OK 
> > > to leave like that. Even though they have same CallId, the 
> > > proxy should discriminate the calls by from-tag, callid, 
> and to-tag.
> > > > According to Spec, any UA should have a different means of 
> > > generating callid's with those of other UA's. 
> > > >  
> > > > Anything to do correctly to the above procedure?
> > > >  
> > > > Thanks in advance,
> > > > Anil
> > > > This email contains material that is confidential. The 
> > > content of this email is for the sole use of the intended 
> > > recipient(s). Any review or distribution by persons other 
> > > than the intended recipient(s) without the express permission 
> > > of NetScreen Technologies, Inc. is strictly prohibited. If 
> > > you are not the intended recipient, please contact the sender 
> > > and delete/destroy all copies of this email and any related 
> > > attachments. NetScreen does not guarantee the accuracy or 
> > > completeness of third party materials or information.
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol
> > > > Use [email-masked] for questions on 
> current sip
> > > > Use [email-masked] for new developments on the 
> application of sip
> > > > 
> > > 
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Feb 2004 16:49:14 -0500

Eric,

You can't make it a token an remain backward compatible with 3261.

I support tightening up the semantics. But you can't just say it must be 
  a globally unique value in space and time without giving some guidance 
on how to partition the namespace so that developers don't pick 
conflicting techniques.

Even changing to word@host would be slightly incompatible. But perhaps 
it could be specified that the form word@host should not be used unless 
the application generating the callid can assure that no other entity is 
using the same value of host to generate callids.

	Paul