Re: [sipcore] draft-roach-sipcore-rfc3265bis-00

[Adam Roach <[e-mail]>]

Christer Holmberg wrote:
> Has it been considered that a forking proxy would forward multiple
> SUBSCRIBE 200 responses instead?
>   

That ship sailed over a decade ago, when we published RFC 2543. We 
really can't require proxies to treat extension methods as special 
cases: proxies treating SUBSCRIBE as an arbitrary non-INVITE message 
must do the right thing.


> Also, I know that 3261 says that only one final response is forwarded
> for non-INVITE requests. I just wonder whether it means non-dialog
> initiation requests.

Because method names are one SIP's extension points, proxies don't 
inherently know which requests can form dialogs. For example, if a proxy 
forks a XYZZY request, how would it know whether to return a single 200 
response or all of them? It has know way of knowing whether XYZZY is a 
dialog-forming request.

>  Because, what does a proxy do if it receives
> additional 200 responses? I can't find any text about that in 3261.
>   


It's going to drop them. See RFC 3261, section 16.7, step 5.

> I guess the UAS could simply copy the Record-Route into the NOTIFY, as
> it does in the 200 response. That way the proxies would not need to add
> it.
>   

That would make a mess -- currently deployed proxies that are aware of 
3265 would add themselves a second time, resulting in a route set that 
passes through each proxy twice. That's really not what we want to happen.


>>
>> As I mention above: In a compliant system, they can't differ. 
>> However, as we all know, systems don't always do the right 
>> thing. SBCs can tinker with Route/Record-Route in ways that 
>> create asymmetric route sets, even for normal INVITE/200/ACK 
>> transactions.
>>     
>
> I am not really sure what is meant by "compliant system". A system may
> be RFC3261 compliant, which means they may add Record-Route the
> SUBSCRIBE request, but they will not Record-Route the NOTIFY.
>   

See RFC 3265, section 3.1.5.


>> That's certainly the intention of 4.3. It's a bit tortured to 
>> imagine that a proxy might be on the path of the NOTIFY 
>> without having Record-Routing the SUBSCRIBE. Nonetheless, I'm 
>> okay with prohibiting Record-Routing a NOTIFY unless you've 
>> also Record-Routed the associated SUBSCRIBE; I'll add:
>>
>>   Proxies that did not add a Record-Route header field to the
>>   initial SUBSCRIBE request MUST NOT add a Record-Route header
>>   field to any of the associated NOTIFY requests.
>>     
>
> Don't you need a Proxy-Require option tag for that? 
>
> Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, but that
> doesn't mean it will Record-Route the NOTIFY. It may simply be
> configured to Record-Route all dialog initiation requests.
>   

For a proxy to have the first clue that SUBSCRIBE is a dialog initiation 
request, it has to be aware of the semantics of SUBSCRIBE. Otherwise, it 
doesn't know SUBSCRIBE from XYZZY.

And if a proxy is blindly Record-Routing unknown methods, it will 
Record-Route the NOTIFY also. Either way, everything works.

I've worked with enough implementors to know that there's never enough 
accounting for crazy, but the failure you're describing would require a 
certain amount of malice: enough understanding to know what SUBSCRIBE 
means, but a bewildering level of willful ignorance to then pretend not 
to understand NOTIFY.

/a