Subject: [sipcore] Reuse of Sip Call-Id question..

From: "Cahall, Glenn" <[email-masked]>
Date: Thu, 4 Jun 2009 14:50:24 -0600

Folks,

I work for a VoIP company, Level3 Communications, and have been doing some research on the internet about
a specific condition that has arisen here dealing with the Sip protocol.  Your names came up during my research.
Was hoping I could get some feedback about the reuse of Sip Call-Id.

We have customer UAs that are reusing the same Sip Call-Id for multiple call attempts into our network.

After reviewing the Sip RFC 3261, both myself and my team concluded that this was a clear violation of the spec.  based
on the following verbiage...

8.1.1.4 Call-ID

   The Call-ID header field acts as a unique identifier to group
   together a series of messages.  It MUST be the same for all requests
   and responses sent by either UA in a dialog.  It SHOULD be the same
   in each registration from a UA.

   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.  Note that when requests are retried after certain

However, some voice engineers are stating that the definition of "globally unique over time and space"  means only during the
context of a given call.  Therefore, once this context is over....Sip Call-Id can in fact be reused in the very next context.

What is your take on this?

Thanks,
Glenn E. Cahall
Sr. Architect
Level3 Communications

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Jun 2009 20:13:13 -0400

Cahall, Glenn wrote:

> After reviewing the Sip RFC 3261, both myself and my team concluded that 
> this was a clear violation of the spec.  based
...
> However, some voice engineers are stating that the definition of 
> “globally unique over time and space”  means only during the
> context of a given call.  Therefore, once this context is over....Sip 
> Call-Id can in fact be reused in the very next context.

:-)

I would have thought that “globally unique over time and space” was 
pretty clear. I don't know how you can get from there to: "only during 
the context of a given call".

In fact, "only during the context of a given call" is the *exception*, 
during which the same callid *may* be reused. Specifically, if you make 
several different INVITE attempts in pursuit of the same "call" then 
they may have the same callid, but must be distinguished by different 
from-tags. (This would typically come up if an initial request resulted 
in a 3xx response, and the UAC is recursing on the Contacts in the 3xx 
in an attempt to complete the call.)

These guys have no legs to stand on, if you are accurately describing 
the situation.

	Thanks,
	Paul

---

From: "Cahall, Glenn" <[email-masked]>
Date: Fri, 5 Jun 2009 09:18:02 -0600

Paul,

Thanks for the response.

Once I read your response, I felt that I needed to explain the situation in more detail.

Customer is sending us an INVITE, our response is a 486 BUSY.  This exact scenario (all with same TNs) repeats itself 100+ times over the next 90 seconds or so.  All 100+ INVITEs contain the same Call-Id.  However, tag value in the From field is different.

So....now that you know more about the situation....is this in violation of the RFC?

Also, during our discussions on the topic, we argued whether or not Call-Id could be reused.  In short, as stated before, even if the initial call was successful, they believed that as soon as that call was completed, they were free to use the exact same Call-Id on the very next call.

Thanks for your input,
Glenn

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, June 04, 2009 6:13 PM
To: Cahall, Glenn
Cc: [email-masked]
Subject: Re: [sipcore] Reuse of Sip Call-Id question..

...
> "globally unique over time and space"  means only during the

:-)

I would have thought that "globally unique over time and space" was 
pretty clear. I don't know how you can get from there to: "only during 
the context of a given call".

	Thanks,
	Paul

---

From: Byron Campen <[email-masked]>
Date: Fri, 5 Jun 2009 10:26:39 -0500

Yeah, they are completely wrong on this one. My first thought when I  
saw your email was that you were pulling our leg (or that these  
engineers were pulling yours). But, upon reflection, I have seen  
things just about as broken at SIPit.

Best regards,
Byron Campen

> Customer is sending us an INVITE, our response is a 486 BUSY.  This  
> exact scenario (all with same TNs) repeats itself 100+ times over  
> the next 90 seconds or so.  All 100+ INVITEs contain the same Call- 
> Id.  However, tag value in the From field is different.
>
> Also, during our discussions on the topic, we argued whether or not  
> Call-Id could be reused.  In short, as stated before, even if the  
> initial call was successful, they believed that as soon as that call  
> was completed, they were free to use the exact same Call-Id on the  
> very next call.
>
> Thanks for your input,
> Glenn
>
>
>> We have customer UAs that are reusing the same Sip Call-Id for  
>> multiple
>> call attempts into our network.
>>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jun 2009 11:30:24 -0400

> So....now that you know more about the situation....is this in violation of the RFC?

Well...

That case is arguable. I think it can be viewed as retried attempts to 
establish the same call. And on that basis, as long as they change the 
from-tag, I don't think I would call this use a violation.
But its a gray area - you may get other opinions.
(Lets wait and see. Surely Dale will have an opinion!)

> Also, during our discussions on the topic, we argued whether or not Call-Id could be reused.  In short, as stated before, even if the initial call was successful, they believed that as soon as that…

On that point I don't think they have a leg to stand on.

	Thanks,
	Paul

---

From: Byron Campen <[email-masked]>
Date: Fri, 5 Jun 2009 10:43:08 -0500

On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote:

> That case is arguable. I think it can be viewed as retried attempts  
> to establish the same call. And on that basis, as long as they  
> change the from-tag, I don't think I would call this use a violation.

	Erm, I think that _not_ reusing the tags would make this a violation.  
If the Call-Id and tags were the same, this would appear identical to  
a proxy forking sequentially (unless something was peeking into the  
Via stack), so forbidding a UA to do it doesn't make a whole lot of  
sense.

>> initial call was successful, they believed that as soon as that  
>> call was completed, they were free to use the exact same Call-Id on  
>> the very next call.
>

	Agreed.

Best regards,
Byron Campen

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jun 2009 12:30:01 -0400

Byron Campen wrote:
>>> exact scenario (all with same TNs) repeats itself 100+ times over the 
>>> next 90 seconds or so.  All 100+ INVITEs contain the same Call-Id.  
>>> However, tag value in the From field is different.
>>
>     Erm, I think that _not_ reusing the tags would make this a 
> violation. If the Call-Id and tags were the same, this would appear 
> identical to a proxy forking sequentially (unless something was peeking 
> into the Via stack), so forbidding a UA to do it doesn't make a whole 
> lot of sense.

Hmm. Perhaps you are right about the tags.

But going down that path then leads me to believe that this isn't valid 
either.

When a proxy forks a request it is not allowed to send it to the same 
destination a 2nd time. And if trying a different target eventually 
loops back to the same destination, isn't it the callid + from-tag that 
results in the request being rejected rather than considered again?

That tells me that its invalid regardless of the tag.

So I take back my tentative approval in the 486 case.

	Paul

---

From: Byron Campen <[email-masked]>
Date: Fri, 5 Jun 2009 11:35:33 -0500

>>>> Customer is sending us an INVITE, our response is a 486 BUSY.   
>>>> This exact scenario (all with same TNs) repeats itself 100+ times  
>>>> over the next 90 seconds or so.  All 100+ INVITEs contain the  
>>>> same Call-Id.  However, tag value in the From field is different.
>>>
>>> That case is arguable. I think it can be viewed as retried  
>>> attempts to establish the same call. And on that basis, as long as  
>>> they change the from-tag, I don't think I would call this use a  
>>> violation.
>> identical to a proxy forking sequentially (unless something was  
>> peeking into the Via stack), so forbidding a UA to do it doesn't  
>> make a whole lot of sense.
>
> But going down that path then leads me to believe that this isn't  
> valid either.
>
> When a proxy forks a request it is not allowed to send it to the  
> same destination a 2nd time. And if trying a different target  
> eventually loops back to the same destination, isn't it the callid +  
> from-tag that results in the request being rejected rather than  
> considered again?
>

	Depends on the destination, really. Proxies are supposed to only send  
to a given destination with the same routing information once though.

Best regards,
Byron Campen

---

From: "Cahall, Glenn" <[email-masked]>
Date: Fri, 5 Jun 2009 10:37:32 -0600

Just so I got it straight....so, are you now saying that repeated INVITEs with 486 responses using same Call-Id is ok...or a violation?

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 10:30 AM
To: Byron Campen
Cc: Cahall, Glenn; [email-masked]
Subject: Re: [sipcore] Reuse of Sip Call-Id question..

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 05 Jun 2009 12:59:33 -0400

> (Lets wait and see. Surely Dale will have an opinion!)

Of course!

To confirm what everyone else is saying:  A UA may "retry" an INVITE
that received a failure response by incrementing the CSeq, but keeping
the Call-Id and from-tag.  But if an INVITE is for a logically different
call, it must have a different Call-Id, and the phone must have a method
for constructing Call-Id's that makes it statistically impossible to
duplicate the Call-Id's generated by any other element.

It is clearly understood that if a call is *successful* its Call-Id may
not be reused.

> However, tag value in the From field is different.

In regard to the from-tag in retried requests, I'm not sure if there is
an explicit statement that the from-tag must be the same, but that is
the universal understanding.

None of this discussion addresses the oddest aspect of your scenario:
Having gotten a "Busy Here" response, why is the UA automatically
retrying the request in less than 1 second?  Does the UA think that the
callee is likely to have hung up in the last 0.9 second?  I suspect the
UA is retrying when it sees any 4xx response, and is not restricting
itself to responses that it can remedy.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jun 2009 13:00:27 -0400

violation

---

From: Bob Penfield <[email-masked]>
Date: Fri, 5 Jun 2009 13:05:03 -0400

Section 8.1.3.5 talks about retrying requests that get certain 4xx responses. For 401, 413, 415, 416, and 420, it says:

   In all of the above cases, the request is retried by creating a new
   request with the appropriate modifications.  This new request
   constitutes a new transaction and SHOULD have the same value of the
   Call-ID, To, and From of the previous request, but the CSeq should
   contain a new sequence number that is one higher than the previous.

Then it goes on to say:

   With other 4xx responses, including those yet to be defined, a retry
   may or may not be possible depending on the method and the use case.

I would say that retrying a request that got a 486 with the same Call-ID, From & To would only be appropriate if a different Request-URI was used to attempt to contact the same user. It is not appropriate to use the same Call-ID/From/To for a "redial" function that simply retries the same request without any modification (other than CSeq).

cheers,
(-:bob

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, June 05, 2009 10:30 AM
To: Byron Campen
Cc: Cahall, Glenn; [email-masked]
Subject: Re: [sipcore] Reuse of Sip Call-Id question..

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jun 2009 13:05:55 -0400

> itself to responses that it can remedy.

In the absence of a call queuing mechanism, this is the way you get 
through to an address that is constantly busy with a series of calls.

Maybe they are trying to get in to vote on American Idol. :-)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Jun 2009 19:13:26 -0500

> was completed, they were free to use the exact same Call-Id on the  

The From: tag SHOULD be invariant if the Call-ID is re-used in  
response to a 4xx, else the transaction won't match. And the CSeq  
SHOULD increase, since it is a new INVITE. This is specified in  
paragraph 6 of section 8.1.4.5 in RFC 3261. In practice, state  
matching fails if this isn't honored, so it really could have been  
specified as a MUST; that is, we should probably rewrite RFC 3261 to  
say something like:

"The UAC MAY retry a transaction following certain 400-class  
responses, If the UAC retries such a transaction, it MUST retain the  
To, From, Call-ID and Request-URI of the original transaction, and  
MUST increment the CSeq. Failure to observe these two operational  
requirements is likely to result in proxies or the UAS not matching  
the retried transaction to any retained state from previous  
transactions, which could result in errors ranging from erroneous log  
entries to denial-of-service scenarios, and it is in extremely poor  
taste too."

In other words, the tag should be the same, the CSeq should increment,  
and you spank the customer  for being annoying.

Failing that, how's the Retry-After: header field on your 486  
populated? Perhaps you could crank it up to about 60 seconds, THEN  
spank them for being annoying it if they ignore it.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Jun 2009 19:16:30 -0500

On Jun 5, 2009, at 7:13 PM, Dean Willis wrote:
> paragraph 6 of section 8.1.4.5

I meant 8.1.3.5, dangit!

> in RFC 3261. In practice, state matching fails if this isn't  
> honored, so it really could have been specified as a MUST; that is,  
> we should probably rewrite RFC 3261 to

So, we know HOW to retry a transaction.

Now, the other question: Should the transaction be retried at all? The  
general consensus seems to be no, not unless a Retry-After was  
specified in the 4xx response and the request time period has elapsed.

--
Dean

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 05 Jun 2009 21:29:26 -0400

> entries to denial-of-service scenarios, and it is in extremely poor  

I think one can safely change the request-URI when retrying, and in some
cases, one may need to to fix the problem.  As far as I know, nobody
uses the request-URI for any kind of transaction or dialog matching (and
they surely should not).

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 6 Jun 2009 13:33:18 -0500

> uses the request-URI for any kind of transaction or dialog matching  

I'd argue it's a new transaction, not a retry, if the R-URI changes.

--
Dean

---

From: Bob Penfield <[email-masked]>
Date: Sat, 6 Jun 2009 15:19:53 -0400

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
>Sent: Saturday, June 06, 2009 2:33 PM
>To: Dale Worley

In section 8.1.3.5 of 3261 it does give one case where the Request-URI would change:

   If a 416 (Unsupported URI Scheme) response is received (Section
   21.4.14), the Request-URI used a URI scheme not supported by the
   server.  The client SHOULD retry the request, this time, using a SIP
   URI.

And just to be picky, I think you meant "new session" rather than "new transaction". A retry is a new transaction :)

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 08 Jun 2009 16:39:34 -0400

> I'd argue it's a new transaction, not a retry, if the R-URI changes.

I would argue that it depends on the semantics of the situation.

But more importantly, a downstream element can't tell whether the UAC
changed its request-URI, since the request-URI may have been changed by
an intermediate proxy.  But a downstream element can tell if the
from-tag was changed by the UAC, since proxies don't change the
from-tag.

Dale

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 9 Jun 2009 10:05:00 +1000

The via branch is used to match transactions. The state machine doesnt
care about call-id or tags when matching transactions (if it is
RFC3261 compliant that is). So a question to Glenn. Is the branch also
the same?

The transaction layer will pass the request to the UAS Core if there
is no match in the transaction (branch in top via header). In that
case, the core will not find a dialog match (since it rejected the
original request) and will process the new request as a new request.

Hisham

2009/6/6 Dean Willis <[email-masked]>:
>> Customer is sending us an INVITE, our response is a 486 BUSY.  This exact
>> scenario (all with same TNs) repeats itself 100+ times over the next 90
>> seconds or so.  All 100+ INVITEs contain the same Call-Id.  However, tag
>> value in the From field is different.
>>
>> Call-Id could be reused.  In short, as stated before, even if the initial
>> call was successful, they believed that as soon as that call was completed,
>> they were free to use the exact same Call-Id on the very next call.
>
>
>
> The From: tag SHOULD be invariant if the Call-ID is re-used in response to a
> 4xx, else the transaction won't match. And the CSeq SHOULD increase, since
> it is a new INVITE. This is specified in paragraph 6 of section 8.1.4.5 in
> RFC 3261. In practice, state matching fails if this isn't honored, so it
> really could have been specified as a MUST; that is, we should probably
> rewrite RFC 3261 to say something like:
>
> "The UAC MAY retry a transaction following certain 400-class responses, If
> the UAC retries such a transaction, it MUST retain the To, From, Call-ID and
> Request-URI of the original transaction, and MUST increment the CSeq.
> Failure to observe these two operational requirements is likely to result in
> proxies or the UAS not matching the retried transaction to any retained
> state from previous transactions, which could result in errors ranging from
> erroneous log entries to denial-of-service scenarios, and it is in extremely
> poor taste too."
>
> In other words, the tag should be the same, the CSeq should increment, and
> you spank the customer  for being annoying.
>
> Failing that, how's the Retry-After: header field on your 486 populated?
> Perhaps you could crank it up to about 60 seconds, THEN spank them for being
> annoying it if they ignore it.
>
> --
> Dean
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Jun 2009 23:32:49 -0500

[as an individual]

This is an excellent example of where Postel's Maxim would address the 
problem. (For the unaware, Postel's Maxim is "be conservative in what 
you do, be liberal in what you accept from others"). For the failure 
Glenn is describing, it takes the efforts of two misbehaving systems to 
cause a failure.

There is nothing in RFC3261 that normatively assigns semantics to a 
Call-ID by itself. It is meaningful only when combined with other 
identifiers, such as To: and From: tags. If you have software that is 
failing when it sees duplicate Call-IDs, then that is a bug that should 
be resolved.

However, this misbehavior wouldn't happen if the sending party were a 
bit more conservative in what it sent -- if it were more vigorous in 
generating new Call-IDs for new attempts.

If we're seeing real-life failures due to this behavior, I'd say both 
sides are at fault. It takes two to dance this "Failure Tango".

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 09 Jun 2009 03:18:21 -0500

> And just to be picky, I think you meant "new session" rather than "new transaction". A retry is a new transaction :)

You are most pickily correct.

I'm not sure I believe that the 8.1.3.5 you quote above is right, or at 
least it isn't cocnsistent with what I think by "retry". It seems likely 
that something along the line might get weird if we re-use the call-ID 
with the new request-URI. I'm pretty sure call-ID based CDR aggregation 
systems that I remember speccing at a carrier or two would melt-down.

--
Dean

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jun 2009 09:08:53 -0400

Adam,

I will agree with you on this one.

Yet I want to emphasize the need for conservatism on the originating 
side. I have repeatedly seen cases where somebody says on of:
- I can reuse the same callid because the from and to tags will
   make the dialog id unique
- I can reuse the same from tag because the callid and to tag will
   make the dialog id unique
- I can reuse the same to tag because the callid and from tag will
   make the dialog id unique

Of course nobody agrees on which ones really must be unique.

When you reason this way you are betting that everybody else involved 
has made compatible assumptions to the one you are making.

	Thanks,
	Paul

Adam Roach wrote:
>>>> Once I read your response, I felt that I needed to explain the 
>>>> situation
>>>> in more detail.
>>>>
>>>> exact
>>>> So....now that you know more about the situation....is this in 
>>>> violation
>>>> of the RFC?
>>>>
>>>> initial
>>> response to a
>>> responses, If

---

From: Dean Willis <[email-masked]>
Date: Tue, 09 Jun 2009 12:33:32 -0500

> sides are at fault. It takes two to dance this "Failure Tango".

Although the real "dance beat" of the failure tango in Glenn's case is
the rhythm of the UAS resending the failed request 100 times in rapid
succession. All questions of protocol specification aside, that's just
plain rude.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jun 2009 14:05:19 -0400

Depends on your perspective. It might be the UAS that is rude by 
continuing to be busy. :-)

	Paul