Subject: R: [Sipping] Possible Solution to HERFP

From: Cuda Alberto <[email-masked]>
Date: Wed, 20 Jul 2005 12:45:28 +0200

I definitely agree. I think that keeping the approach as general
as possible is the best guarantee we are on the right track. 
Probably a new method can remove many of the interactions with exising
or evolving mechanisms. Another possibility (to save some bandwidth)
can be to piggyback this info into the PRACK request -- ugly.

A solution to HERFP could be benficial also in IMS networks where
network elements providing service logics are distinct from 
proxies accessing the location service. It would be very nice
to find a solution that not only works when there are more than
one forking proxy involved in the call, but that even allows
proxies to ask downstream proxies to trigger the 130-mechanism.
That's because sometimes even proxies can "repair" errors,
by opening new branches when some specific error code is detected. 

Just a few commments more, on other aspects:
1. I think that when a response is encapsulated into a 130 response,
   its routing headers (Via, Record-Route and the like) should be 
   stripped: this should simplfy matters when a topology hiding 
   element or anonymizer is in the path. 
2. Probably it would be nice to use the Record-Route/Route mechanism
   when trying to repair the error (as suggested by Jeroen): this
   ensures that the retried request looks as closely as possible
   to the original request (suppose there are intermediate proxies
   that add/remove headers);
3. No matter which solution is chosen, it would be very nice if 
   all the state information associated to single-branch URIs is 
   simple enough to make it possible to encode it into e.g. its
   user part. This allows to behave statelessly, providing many
   benefits;
4. It is not clear to me why you chose Timer C as expiration
   time for SB-URIs. I'm not saying it's wrong, it's just that
   since it is associated to human (callee) intervention I was 
   wondering why... (is that the time to type username & password
   or it's something more subtle?).

	Cheers.
		Alberto.

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto
di Adam Roach
Inviato: Wednesday, July 20, 2005 1:55 AM
A: Jeroen van Bemmel
Cc: Rohan Mahy; Paul Kyzivat; 'sipping' WG
Oggetto: Re: [Sipping] Possible Solution to HERFP

I think it's ridiculous to impose these kinds of artificial restrictions

on the network architecture just for the purpose of re-using the CANCEL 
method to communicate that an already-failed branch is being abandoned. 
I think we have two possible approaches that are slightly less ugly than

ruining perfectly valid use cases:

1) Define a new method that means, "I'm abandoning the branch identified

by a specific URI."
2) Re-use UPDATE in some fashion to indicate that the branch is no 
longer of interest.

/a

Jeroen van Bemmel wrote:

> Right. That would leave us with 2 options:
>
> 1) Only enable HERFP protection on the first proxy, i.e. where the 
> domain in the To header is equal to that of the request URI
> 2) Don't allow such holiday configurations, tell people to have their 
> vacation phones register at home instead...
>
> (2) would save you an intermediary hop which makes it even more 
> promptly! But lacking the authority to enforce that, what about (1)?
>
> Jeroen
>
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> To: "Jeroen van Bemmel" <[email-masked]>
> Cc: "Adam Roach" <[email-masked]>; "Rohan Mahy" <[email-masked]>; 
> "'sipping' WG" <[email-masked]>
> Sent: Wednesday, July 20, 2005 12:21 AM
> Subject: Re: [Sipping] Possible Solution to HERFP
>
>
>>
>>
>> Jeroen van Bemmel wrote:
>>
>>> About the issue with multiple forking proxies:
>>>
>>> A proxy is only allowed to fork if it is responsible for the domain 
>>> specified in the request URI. So unless proxy A in the below case 
>>> forks and modifies the request URI's domain to that of proxy B, the 
>>> multi-proxy case should be rare and perhaps even be considered as a 
>>> case of misconfiguration?
>>
>>
>> The situation you outline is not so unreasonable: Proxy for A forks 
>> to multiple contacts - some local phones plus another AOR B. Proxy 
>> for B forks to some additional phones.
>>
>> This might happen if I have a vacation home with its own AOR and 
>> multiple phones, as well as a primary home with multiple phones. I 
>> might want to configure the proxy for my primary home to also ring 
>> immediately at my vacation home, so I always get calls promptly 
>> regardless of which place I happen to be.
>>
>> Paul
>>
>>> JvB
>>>
>>>
>>> ----- Original Message ----- From: "Adam Roach" <[email-masked]>
>>> To: "Rohan Mahy" <[email-masked]>
>>> Cc: "'sipping' WG" <[email-masked]>
>>> Sent: Wednesday, July 13, 2005 1:12 AM
>>> Subject: Re: [Sipping] Possible Solution to HERFP
>>>
>>>
>>>> Rohan Mahy wrote:
>>>>
>>>>>
>>>>> On Jul 12, 2005, at 8:27, Adam Roach wrote:
>>>>>
>>>>>> Rohan Mahy wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jul 8, 2005, at 22:09, Adam Roach wrote:
>>>>>>>
>>>>>>>> ---
>>>>>>>> The sending of CANCELs to branches which are to be abandoned 
>>>>>>>> seems like it might be problematic. I could just be remembering

>>>>>>>> some subtle protocol issues incorrectly, though.
>>>>>>>>
>>>>>>>> Let's say you have a UAC (supporting herf), which sends a 
>>>>>>>> request to proxy A. Proxy A forks the request to Proxy B and 
>>>>>>>> UAS1. Proxy B forks the request to UAS2 and UAS3. UAS2 responds

>>>>>>>> with a 401. Following the procedure you outline, Proxy B then 
>>>>>>>> sends a 130 to Proxy A. Proxy A then forwards this 130 to the 
>>>>>>>> UAC. The UAC doesn't have credentials for the indicated realm, 
>>>>>>>> so it sends a CANCEL to the URI indicated in the Contact header

>>>>>>>> field of the 130. Proxy A sees this CANCEL, and matches it to 
>>>>>>>> the pending response context (with branches to UAS1 and Proxy 
>>>>>>>> B). Consequently, Proxy A returns a 200 to the CANCEL and 
>>>>>>>> generates its own CANCEL requests for its two client
transactions.
>>>>>>>>
>>>>>>>> Even if Proxy B is able to deduce what is going on here (and I 
>>>>>>>> don't think it can), UAS1 has now become unreachable.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> would you be satisfied if the 130 response was only allowed to 
>>>>>>> be sent for branches that won't fork?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Either I misunderstand what you're suggesting here, or you 
>>>>>> misunderstood the use case I tried to describe.
>>>>>>
>>>>>> Proxy B has no way whatsoever to know that Proxy A forked the 
>>>>>> request. It can't know about UAS1. I has no way to determine that

>>>>>> sending a 130 (and consequently triggering the UAC to send a 
>>>>>> CANCEL) will ruin the ability to contact UAS1.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You are absolutely right that Proxy B doesn't know that Proxy A 
>>>>> forked the request, but Proxy A knows that it sent the request to 
>>>>> a SIP node with which it does not have a directly registered 
>>>>> association.
>>>>>
>>>>> We have several choices here:
>>>>> 1) Proxy A can redirect the UAC to Proxy B by sending a 130 with 
>>>>> an embedded 300.
>>>>> 2) Proxy A just doesn't send a 130 for branches that are directly 
>>>>> registered.
>>>>
>>>>
>>>>
>>>>
>>>> Consider the case in which Proxy A does not know about the herf 
>>>> extension.
>>>>
>>>> /a
>>>>
>>>> _______________________________________________
>>>> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use [email-masked] for questions on current sip
>>>> Use [email-masked] for new developments of core SIP
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [email-masked] for questions on current sip
>>> Use [email-masked] for new developments of core SIP
>>>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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