Subject: [dispatch] (no subject)

From: Sohel Khan <[email-masked]>
Date: Wed, 25 Jan 2012 14:25:10 -0800 (PST)

Thanks Paul and Dale.
I think the provider interal rule may vary.
Depending upon a provider internal rule, a provider may or may not take action based upon the information in the SPID sequence. Even inside a provider, there can be two different types of SIP agents. One may choose to take particular action based on the information on the SPID and the other session agent may not take any action based on the information on the SPID. 
Please let me know if I still missing something.
For the call forwarding loops, the operatioonal engineers prefer to use Diversion counter to break loops. 
I will read the RFC that Dale suggested and will get back to you on this further.
 
Sohel
 
Message: 3
Date: Tue, 24 Jan 2012 22:21:00 -0500
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
Subject: Re: [dispatch] SPID Sequence and Loop Detection
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 1/24/12 4:59 PM, Sohel Khan wrote:
> We are not discussing routing loop due to call forwarding.
> Various loop mitigation mechanism may be applicable to mitigate
> different types of routing loops.

You may not be discussing/considering those things, but you should be, 
because (as Dale explained) the mechanism you are proposing would 
*break* non-loop calls that revisit the same provider.

    Thanks,
    Paul

Regards, Sohel Khan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2012 22:17:31 -0500

On 1/25/12 5:25 PM, Sohel Khan wrote:
> Depending upon a provider internal rule, a provider may or may not take
> action based upon the information in the SPID sequence. Even inside a
> provider, there can be two different types of SIP agents. One may choose
> to take particular action based on the information on the SPID and the
> other session agent may not take any action based on the information on
> the SPID.

But in some cases it may decide there is an error based on the message 
revisiting a particular provider??? (After all, that is what your 
original message asserted.)

That policy could break some *valid* non-looping situations that revisit 
a provider based on call forwarding or other actions.

> Diversion counter to break loops.

Where do you get the diversion counter? From the Diversion header? Or 
from H-I?

This *might* work in a closed garden if all messages are policed to 
adhere to some proprietary constraints. But it won't work in general.

And I don't think you can fall back on SBCs to "make this right" for 
you. They can't necessarily identify and tunnel sufficient information.

	Thanks,
	Paul

> From: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Message-ID: <[email-masked]
> <mailto:[email-masked]>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch