Subject: RE: [Sip] Path header: Independent operation in each direction, o r common o peration for both directions

From: "George Foti (LMC)" <[email-masked]>
Date: Fri, 1 Mar 2002 12:12:23 -0500

Examples or no examples,  the PATH extenstion should be generic enough to
handle independent PATH in each direction. 3GPP may impose its own
limitations in 24229 & 24228.
Everybody is happy.

Rgds/gf
Ericsson Canada

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, February 25, 2002 5:44 AM
> To: [email-masked]'
> Subject: [Sip] Path header: Independent operation in each 
> direction, or
> common o peration for both directions
> 
> 
> I am breaking out the issues that I think need more 
> discussion relating to
> the proposed Path header. This is the first of those mails.
> 
> Currently the mechanism specified for 3GPP looks very like 
> Record-Route and
> it therefore collects the URLs of the proxies that wish to be 
> on the path
> for future transactions by use of the header within the 
> REGISTER request,
> and the response is merely a transport mechanism of the 
> gathered information
> back to the UA from the registrar.
> 
> This means that proxies so identified are intended to be in 
> the path for
> both incoming and outgoing requests, as there is no means of 
> distinguishing
> the two independently (or at least not with a single header, 
> or separate
> lists within the common header).
> 
> The mechanism proposed in Deans draft allows independent gathering of
> information in each direction; a proxy that wishes to be on 
> the path in both
> incoming and outgoing directions must insert its URL in both 
> the request and
> the response. This loses the commonality of the procedures with
> Record-Route.
> 
> While both mechanisms work, having discussed the requirements 
> with a limited
> set of people, we cannot think of a situation whereby a proxy 
> would want to
> be on the incoming path and not on the outgoing path, and vice-versa.
> Certainly in 3GPP, the requirement needs to apply in both directions.
> Therefore the real question is are we developing a solution 
> that does more
> that the requirements need, and therefore losing the commonality with
> Record-Route as a result.
> 
> [While there may be advantages of code sharing with Record-Route for
> implementations, I am thinking more of the advantages to 
> understanding the
> specification. People are more likely to understand and implement Path
> correctly if it works the same way as something else.]
> 
> So, those who need operations independently in both 
> directions, can you
> shout up and give us some examples.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked]
> 
> _______________________________________________
> 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