Subject: RE: [Sip] CallId question

From: "Eric Burger" <[email-masked]>
Date: Wed, 18 Feb 2004 11:09:59 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 18 Feb 2004 14:27:45 -0600

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